linux-audit / audit-userspace Goto Github PK

I was using the audispd tool (in previous version 2.8.3) to get the auditd output directly from a socket. It was configured using the default plugin configuration set in af_unix.conf:

active = yes
direction = out
path = builtin_af_unix
type = builtin
args = 0640 /var/run/audispd_events
format = string

Now I've upgraded to Audit 3.0 in Fedora 29 and I realized that audispd was merged into auditd. So I enabled the plugin again in the new location /etc/audit/plugins.d/af_unix.conf, but now I cannot read from the socket using the same configuration.
I'm able to read the log directly from audit.log, so auditd is working as expected.

The installed audit version is: audit-3.0-0.4.20180831git0047a6c.fc29.x86_64

audit.rules:

## This set of rules is to suppress the performance effects of the
## audit system. The result is that you only get hardwired events.
-D

## This suppresses syscall auditing for all tasks started
## with this rule in effect.  Remove it if you need syscall
## auditing.
#-a task,never
-w /etc/shadow -p w

Is there any new configuration that I should apply to activate the socket?

Thanks in advance.

Please apply these patches:
#1
https://www.redhat.com/archives/linux-audit/2016-August/msg00045.html
Kernel part:
linux-audit/audit-kernel#5
upstreamed 2016-06-27 86b2efb:
https://www.redhat.com/archives/linux-audit/2016-June/msg00064.html
with an addition to add feature bitmap support posted 2016-08-18:
https://www.redhat.com/archives/linux-audit/2016-August/msg00037.html
Test upstreamed:
linux-audit/audit-testsuite@447acf7
Please re-open the following issue when this issue is resolved:
linux-audit/audit-testsuite#23 (comment)

Hi,

Can libaudit supports custom user types for messages? (e.g. I want to register my audit type message for some service).

In recent testing of events for ghak90 and ghak110 it has been noticed that ausearch isn't grouping all the records of one event together even though the date/time/serial stamps are identical. It may be related to the fact that both records are in the 1000 block.

ghak90:

type=CONTAINER_OP msg=audit(2019-03-19 15:40:06.141:235) : op=set opid=698 old-contid=18446744073709551615 contid=123455 pid=698 uid=root auid=root tty=ttyS0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=test.sh exe=/usr/bin/bash res=yes 
----
type=CONTAINER_ID msg=audit(2019-03-19 15:40:06.141:235) : contid=123455 
type=PROCTITLE msg=audit(2019-03-19 15:40:06.141:235) : proctitle=/bin/sh ./test.sh 
type=SYSCALL msg=audit(2019-03-19 15:40:06.141:235) : arch=x86_64 syscall=write success=yes exit=7 a0=0x1 a1=0x55e34362ceb0 a2=0x7 a3=0xa items=0 ppid=676 pid=698 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1 comm=test.sh exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) 
----

ghak110:

time->Tue Mar 19 12:23:15 2019
type=LOGIN msg=audit(1553012595.401:219): pid=647 uid=0 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 old-auid=4294967295 auid=0 tty=ttyS0 old-ses=4294967295 ses=1 res=1
----
time->Tue Mar 19 12:23:15 2019
type=PROCTITLE msg=audit(1553012595.401:219): proctitle=2F62696E2F6C6F67696E002D70002D2D0020202020
type=SYSCALL msg=audit(1553012595.401:219): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fff3fb13380 a2=1 a3=0 items=0 ppid=1 pid=647 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=1 comm="login" exe="/usr/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
----

A number of error message descriptions have drifted from the conditions that
caused them in audit_rule_fieldpair_data() including expansion of fields to be used by the user filter list, restriction to the exit list only and changing an
operator to "equals" only. Correct these, using the new errormsg macros.

Several return codes were overloaded and no longer giving helpful error
return messages from the field and comparison functions audit_rule_fieldpair_data() and audit_rule_interfield_comp_data().

Introduce 3 new macros with more helpful error descriptions for data
missing, incompatible fields and incompatible values.

Hi,

According to RedHat's documentation (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-understanding_audit_log_files), PROCTITLE "Gives the full command-line that triggered this Audit event, triggered by a system call to the kernel"

I noticed that when you go over a certain length limit, PROCTITLE truncates the command (it seems to have an upper limit of 256 hex characters).

Here is an example:

type=SYSCALL msg=audit(1535520071.657:16616): arch=c000003e syscall=59 success=yes exit=0 a0=23bcf90 a1=23b9a30 a2=23b8c50 a3=7ffd8636df60 items=2 ppid=20822 pid=20825 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="awk" exe="/usr/bin/gawk" subj=system_u:system_r:unconfined_service_t:s0 key="useract"
type=EXECVE msg=audit(1535520071.657:16616): argc=2 a0="awk" a1=5C0A424547494E2020207B0A20202020202020206D696E75735F65203D2022223B0A20202020202020206D696E75735F44203D2022223B0A20202020202020206D696E75735F66203D2022223B0A20202020202020206D696E75735F62203D2022223B0A202020202020202072657374203D20303B0A7D207B0A2020202020202020696620286C656E67746828243029203C203129207B206E6578743B207D0A2020202020202020696620286D617463682824302C20225E5C5C732A23222929207B206E6578743B207D0A2020202020202020696620286D617463682824302C20225E5C5C732A2D65222929207B206D696E75735F65203D2024303B206E6578743B207D0A2020202020202020696620286D617463682824302C20225E5C5C732A2D445C5C732A24222929207B206D696E75735F44203D2024303B206E6578743B207D0A2020202020202020696620286D617463682824302C20225E5C5C732A2D66222929207B206D696E75735F66203D2024303B206E6578743B207D0A2020202020202020696620286D617463682824302C20225E5C5C732A2D62222929207B206D696E75735F62203D2024303B206E6578743B207D0A202020202020202072756C65735B726573742B2B5D203D2024303B0A7D0A454E4420202020207B0A20202020202020207072696E7466202225735C6E25735C6E25735C6E222C206D696E75735F442C206D696E75735F622C206D696E75735F663B0A2020202020202020666F72202869203D20303B2069203C20726573743B20692B2B29207B207072696E7466202225735C6E222C2072756C65735B695D3B207D0A20202020202020207072696E7466202225735C6E222C206D696E75735F653B0A7D
type=CWD msg=audit(1535520071.657:16616):  cwd="/"
type=PATH msg=audit(1535520071.657:16616): item=0 name="/usr/bin/awk" inode=50333027 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 objtype=NORMAL
type=PATH msg=audit(1535520071.657:16616): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=32642 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 objtype=NORMAL
type=PROCTITLE msg=audit(1535520071.657:16616): proctitle=61776B005C0A424547494E2020207B0A20202020202020206D696E75735F65203D2022223B0A20202020202020206D696E75735F44203D2022223B0A20202020202020206D696E75735F66203D2022223B0A20202020202020206D696E75735F62203D2022223B0A202020202020202072657374203D20303B0A7D207B0A2020

This means that even ausearch will not give you the full command you basically have to fill in the gaps using EXECVE.

Is there a way to get around this limitation so that proctitle holds the entire command?

Thanks

Records that are triggered by an AUDIT_SIGNAL_INFO message including AUDIT_DAEMON_CONFIG (HUP), AUDIT_DAEMON_ROTATE (USR1), AUDIT_DAEMON_RESUME (USR2) and AUDIT_DAEMON_END (TERM) have inconsistent reporting of signal info and swinging field "state".

They also assume that an empty security context implies there is no other useful information in the AUDIT_SIGNAL_INFO message so don't use the information that is there.

AUDIT_DAEMON_CONFIG swinging field "state":

• op=reconfigure state=changed auid...
• op=reconfigure state=no-change auid...
• op=hup-info auid...

AUDIT_DAEMON_RECONFIG (stale?):

• op=reconfigure state=no-change auid...

AUDIT_DAEMON_ROTATE and AUDIT_DAEMON_RESUME don't list valid auid and pid values even when sent valid AUDIT_SIGNAL_INFO messages:

• killall -USR2 auditd:
• type=DAEMON_ROTATE msg=audit(2019-04-09 11:44:07.746:5708) : op=rotate-logs auid=unset pid=-1 subj=?
• killall -USR1 auditd:
• type=DAEMON_RESUME msg=audit(2019-04-09 11:44:01.034:5707) : op=resume-logging auid=unset pid=-1 subj=? res=success

This is a proposal, not a bug report.

There is only one way to pass audit messages to remote side in a secure way. It's Kerberos 5.
But it would be handy if auditd and audisp-remote had more secure ways. For example, via TLS/SSL.

It seems to generate a surplus 'file' rule from the first line of the filecap output when run as a script.
Not difficult to delete the spurious rule but perhaps helpful to observe.

$ filecap /usr/bin
file                 capabilities
/usr/bin/gnome-keyring-daemon.disabled     ipc_lock
/usr/bin/iputils-ping6     net_raw
/usr/bin/iputils-ping     net_raw
/usr/bin/nanoklogd     syslog


-a always,exit -F path=file -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged
-a always,exit -F path=/usr/bin/gnome-keyring-daemon.disabled -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged
-a always,exit -F path=/usr/bin/iputils-ping6 -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged
-a always,exit -F path=/usr/bin/iputils-ping -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged
-a always,exit -F path=/usr/bin/nanoklogd -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged

Turns out audisp-remote plugin does never close connection even on stop/restart/etc.
If central receiving auditd has the following configuration

tcp_client_max_idle = 0
tcp_max_per_addr = 1

and sending host is restarted you'll loose audit messages for a long time (perhaps for tcp timeout?).
On the receiving side you'll get

type=DAEMON_ACCEPT msg=audit(1512058612.591:6605): op=dup addr=${client-ip} port=36242 res=no

and it will refuse any connection from client until previous one considered inactive.

I know a WA - set tcp_client_max_idle to relatively small value or increase tcp_max_per_addr.
But in general I think described behavior is not great.

Hi,

Can I send any events via API to audit log under user without rights (e. g. I'm not root)? I change log group in auditd.conf, but it does not work. Thanks!

Hi,

can I write arbitrary message via libaudit API like this:

attr="test test test"

or any value must be only string without spaces? Thanks.

The exclude rules did not permit a filterkey to be added. This isn't as
important for the exclude filter compared to the others since no records are generated with that key, but still helps identify rules in the rules list
configuration.

Allow filterkeys to be used with the exclude filter.

Hello,

I was parsing auditd log entries with logstash's grok, which uses the oniguruma regex library, and noticed that auditd inserts an INFORMATION SEPARATOR THREE (1D) character between the regular log entries and the ones belonging in the ENRICHED category.

An example:
type=SYSCALL msg=audit(1471629018.000:37047): arch=c000003e syscall=2 success=yes exit=9 a0=7ffd2bf00d70 a1=42 a2=180 a3=8 items=2 ppid=23314 pid=30073 auid=1004 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=57 comm="sshd" exe="/usr/sbin/sshd" key="login_session"^]ARCH=x86_64 SYSCALL=open AUID="someone" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"

^] - denotes where the 1D character is, as seen by grep in a standard terminal.

I was not understanding how a regular expression was intermittently failing to parse the same log entry, fired an hex viewer and found that character there, which was stripped by the online debugger I was using for logstash.

checking whether to create python bindings... testing
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.7/site-packages
configure: error: Python explicitly requested and python headers were not found
make: *** [Makefile:428: config.status] Error 1

Working around this by not building python2 bindings. Not sure if anyone will notice they are gone.

Errors incurred upon parsing filterkeys give no useful information. Provide useful text when errors occur.

Hi,

I use auditd 2.8.3 on Debian. I add those rules:

-w /sbin/insmod -p x -k kernel_modules
-w /sbin/rmmod -p x -k kernel_modules
-w /sbin/modprobe -p x -k kernel_modules
-w /etc/modprobe.conf -p wa -k kernel_modules

So, I want control any executions of running kernel-change utilities (see above).

If I change configuration in modprobe.conf, auditd add events with key kernel_modules.
But, unfortunately, If I exec insmod, rmmod or modprobe utility no any events will be added in audit.log.

I try those rules on Fedora & Centos Linux, behavior is the same as on Debian.
Can auditd log execution of those utilities? Thanks.

Add userspace audit tool support for audit daemon message routing based on kernel audit container ID.

• setting/deleting/listing routing policy

See: linux-audit/audit-kernel#75

Hello.

I want to record SSH login attempts with Auditd service. It works just fine but I don't understand one thing: I haven't defined any rule in /etc/audit/rules.d/*.rules file (that's is, auditctl -l shows nothing) but anyway Auditd is able to record these events (and more that I'm not interested). Why? Why auditd is able to get login attempts if I haven't any defined rule in *.rules file?

I though (surely wrongly) that rule files were the place to specify which kind of events you wanted to record, so not writing any rule should become in not recording any event, but they are. So there must be another place where Auditd has the list of "available to record" events. Where can I see what Auditd is able to record into audit.log and what not? I haven't found any beginner-friendly documentation explaining this.

Thanks a lot.

Add userspace audit tool support for the features introduced by kernel audit container ID support.

• filtering on container ID
• ausearch support

See: linux-audit/audit-kernel#91
See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID

Attempting to use the PCI DSS rules on ubuntu 16.04, I get an error when loading the 10.2.5.b rules:

auditctl -a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/bin/su -F key=10.2.5.b-elevated-privs-session -F unknown field: exe

Not sure why this rule does not work and large amounts of googling have not resulted in any clues.

In EXECVE records, sometimes argc is larger than the number of arg fields in the record.
Here is an example from ausearch --raw: argc=4, but only a0-a2 are present.

type=EXECVE msg=audit(1532044288.686:77750693): argc=4 a0="/bin/bash" a1="/opt/ibm/lsfsuite/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/../../lsfbeats/energy/scripts/getEnergy.sh" a2="/usr/bin/ipmitool"

This record was emitted with the following audit rules in place:

-a always,exit -F arch=b32 -S exit,fork,execve,setpgid,clone,exit_group -F key=XXX
-a always,exit -F arch=b64 -S clone,fork,execve,exit,setpgid,exit_group -F key=XXX

Hello,

For some reasons, the TODO file is not shipped in the 2.8.4 released tarball anymore

Maybe the file should be added explicitly to the EXTRA_DIST variable?

Provide a method to filter on network address family.

Existing SOCKADDR records are listed for any network activity. It would be helpful to be able to classify or limit records to specific network address families, such as AF_INET or AF_INET6.

An example of a network record that is unlikely to be useful and flood the logs:

type=SOCKADDR msg=audit(07/27/2017 12:18:27.019:845) : saddr={ fam=local path=/var/run/nscd/socket }
type=SYSCALL msg=audit(07/27/2017 12:18:27.019:845) : arch=x86_64 syscall=connect success=no exit=ENOENT(No such file or directory) a0=0x3 a1=0x7fff229c4980 a2=0x6e a3=0x6 items=1 ppid=3301 pid=6145 auid=sgrubb uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb sgid=sgrubb fsgid=sgrubb tty=pts3 ses=4 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=network-test

Propose the filter field selector "AUDIT_SADDR_FAM" and command line parameter name "saddr_fam".

See kernel support: linux-audit/audit-kernel#64

Looking through the userspace audit code when trying to debug a new feature, I came across a compiler directive that was used a number of times and I don't understand why.

In particular, in lib/libaudit.c, lib/netlink.c, src/auditctl-listing.c, src/auditctl.c, I see:
#if defined(HAVE_DECL_AUDIT_FEATURE_VERSION) &&
defined(HAVE_STRUCT_AUDIT_STATUS_FEATURE_BITMAP)
used together which does not make sense since they are unrelated.

The AUDIT_FEATURE_BITMAP has nothing to do with AUDIT_FEATURE_VERSION.

This naming was short-sighted in retrospect.

AUDIT_SET_FEATURE (audit_set_feature()), AUDIT_GET_FEATURE (audit_request_features()) and AUDIT_FEATURE_LOGINID_IMMUTABLE (and unused AUDIT_FEATURE_ONLY_UNSET_LOGINUID) are related and present when AUDIT_FEATURE_VERSION is present and positive. They allow a kernel feature named in audit_feature_names[] to be turned off or oon and unlocked or locked.

AUDIT_VERSION_* (deprecated), AUDIT_FEATURE_BITMAP_* along with the struct audit_status.feature_bitmap (STRUCT_AUDIT_STATUS_FEATURE_BITMAP) are used to simply determine if the kernel supports such a feature, extracted by audit_get_features() via load_feature_bitmap() and stored in features_bitmap (AUDIT_FEATURES_UNSET, AUDIT_FEATURES_UNSUPPORTED).

Most (if not all) of the uses of the compiler directive above should be just the first half, HAVE_DECL_AUDIT_FEATURE_VERSION.

The use in lib/libaudit.h of AUDIT_FEATURE_BITMAP_ALL in struct audit_reply->features should instead be HAVE_DECL_AUDIT_FEATURE_VERSION.

I suffer a strange issue.

Reproduce steps

1. install centos7.3 with minimal install.
2. update selinux to disabled and reboot system.
3. yum intall audit to update audit lib.
4. update selinux to enable selinux to enforcing and reboot

Issue: console display libaudit.so.1 permission denied and could not login again.
I need to use rescue mode to login and disabled selinux again.

libaudit version after update: 2.8.1-3.el7_5.1

I have no idea about this issue and guess that's because update audit with selinux disabled,
after enforcing, libaudit without, I don't know, but some types of selinux, makes other service like
login, ..., etc could not refer to libaudit shared lib. ?

So do I need to update to newer version like 3.0 or ...?

Another discovery is /etc/audit/rules.d.
If I install with selinux disabled, some file under this folder will lack of selinux context.
I think whether the selinux on of off, the audit rules under /etc/audit must be with selinux context ?

The another problem is, since auditd should limited by selinux, and selinux need to send log to auditd,
this seems like a ref. loop and auditd need to have permission prior to selinux !?

Is there any tips about this situation?

ausearch's checkpoint feature should create an empty checkpoint file with the current date/time stamp when no events are found so that future invocations can start from that time.

ausearch --checkpoint <filename>

doesn't create a checkpoint file, even empty, when no events are found. This is surprising, since future invocations of ausearch with the checkpoint option should simply start at that previous checkpointed point in time. The file timestamp would be useful for subsequent --checkpoint operations.

As per RFC3164 for syslog describing facilities, I wondered if the "log audit" facility can be used.

13 log audit (note 1)

One might think, after reading specs, facility 13 would be a good choice for where to send audit events. However, as per

There are a limited number of facilities one can parse as arguments, and 13 is not catered for.

I appreciate the complexity arose given older unix platforms syslog.h files and glibc didn't take the time to define all the facilities (possibly syslog.h was written before RFC3164 was authored as a retrospective standard) , e.g. syslog.3. Out of interest freebsd has LOG_SECURITY defined for facility 13. So it seems the Linux community and libc devs opted to never use 13 for audit security events, which is a pity, because things like local6 can sometimes conflict with other programs also using local facilities.

Might it not be a good idea to align to the RFC and default to facility 13, which as far as I can tell, most other linux processes don't use. But is the complication that one can't actually use 13 because it's not defined properly in glibc?

Originally entered as linux-audit/audit-kernel#83 for more information, the problem report is copied below:

Hi folks, maybe it's just me or there's something wrong with the way I search through events, but the >following command returned no matches:

[root@MasterServer audit]# ausearch -i -ts '18/05/18' -hn Client-Machine | more
However, if I search the logs for that date and grep "Client-Machine", this time I get (quite a lot of) results.

[root@MasterServer audit]# ausearch -i -ts '18/05/18' | grep Client-Machine | more
node=Client-Machine type=LOGIN msg=audit(18/05/18 00:00:01.364:894794) : pid=101815 uid=root subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=unset auid=root tty=(none) old-ses=4294967295 >ses=72579 res=yes
node=Client-Machine type=PROCTITLE msg=audit(18/05/18 00:00:01.362:894792) : proctitle=/usr/sbin/unix_chkpwd root chkexpiry
node=Client-Machine type=PATH msg=audit(18/05/18 00:00:01.362:894792) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=8067 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 objtype=NORMAL
node=Client-Machine type=PATH msg=audit(18/05/18 00:00:01.362:894792) : item=0 name=/usr/sbin/unix_chkpwd inode=116424 dev=fd:00 mode=file,suid,755 ouid=root ogid=root rdev=00:00 >obj=system_u:object_r:chkpwd_exec_t:s0 objtype=NORMAL
node=Client-Machine type=EXECVE msg=audit(18/05/18 00:00:01.362:894792) : argc=3 a0=/usr/sbin/unix_chkpwd a1=root a2=chkexpiry
node=Client-Machine type=SYSCALL msg=audit(18/05/18 00:00:01.362:894792) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x7ff7e82df3cd a1=0x7ffc385aced0 a2=0x7ff7e84e2388 a3=0x2 items=2 >ppid=101815 pid=101816 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=unix_chkpwd exe=/usr/sbin/unix_chkpwd subj=system_u:system_r:chkpwd_t:s0->s0:c0.c1023 key=rootcmd
node=Client-Machine type=PROCTITLE msg=audit(18/05/18 00:00:01.364:894793) : proctitle=/usr/sbin/unix_chkpwd root chkexpiry
node=Client-Machine type=PATH msg=audit(18/05/18 00:00:01.364:894793) : item=0 name=/etc/shadow inode=8388687 dev=fd:00 mode=file,000 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shadow_t:s0 >objtype=NORMAL
node=Client-Machine type=SYSCALL msg=audit(18/05/18 00:00:01.364:894793) : arch=x86_64 syscall=open success=yes exit=3 a0=0x7fc932407453 a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=1 >ppid=101815 pid=101816 aui
--More--

A couple of things that come to mind:

1 - Perhaps the date format I use is incorrect? The ausearch manual does not give any clear examples.
2 - The node I am targeting has an hyphenated name, "Client-Machine"..perhaps that is a misleading name for a node?

Thanks,

The file effective capability is a boolean. It is being interpreted as the capability "chown" by auparse. Just print its raw value.

ausearch's -ts boot option doesn't seem to reach back far enough in the audit log history to catch all audit log messages since boot.

'ausearch -ts boot -i` reports first item:

type=SERVICE_START msg=audit(2018-08-09 12:18:07.374:188) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='unit=ntpdate comm=systemd exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success' 

while journalctl -b reports a boot time of:

Aug 09 12:14:24 f27.madcap2.tricolour.ca kernel: Linux version 4.18.0-rc1-ghak32-audit-containerID.v5.0-nsID+ ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)) #3 SMP Thu Aug 2 15:51:46 EDT 2018

and ausearch -ts today -i reports the first item after the journalct -b first item of:

type=DAEMON_START msg=audit(2018-08-09 12:14:32.479:588) : op=start ver=3.0 format=raw kernel=4.18.0-rc1-ghak32-audit-containerID.v5.0-nsID+ auid=unset pid=367 uid=root ses=unset subj=system_u:system_r:auditd_t:s0 res=success 

So we're missing about 3m45 and a quick diff of the output (deleting pre-boot messages from today) says 192 messages.

Add support for namespace identifier record types. There will need to be new auxiliary record types for namespace identifiers for existence, add, delete and set/change events.

Currently the set appears to be:
AUDIT_NS_{INFO,{INIT,DEL,SET}_{MNT,UTS,IPC,USER,PID,NET,CGRP}}

See: linux-audit/audit-kernel#32

In commit 183775f ("Do capabilities
check rather than uid") a switch was made from checking "getuid() != 0"
to checking CAP_AUDIT_CONTROL and CAP_AUDIT_READ via audit_can_control()
and audit_can_read().

auditd does not use the multicast socket, so there is no need for it
to check or have CAP_AUDIT_READ.

Having audit_can_read() available in lib/libaudit.c is certainly useful
regardless for other potential libaudit users like systemd.

Please see discussion at https://www.redhat.com/archives/linux-audit/2018-November/msg00069.html

Hi：
I am a new commer.
Relating of the below description: "
audispd is an audit event multiplexor. It has to be started by the audit daemon in order
to get events. It takes audit events and distributes them to child programs that want to
analyze events in realtime. When the audit daemon receives a SIGTERM or SIGHUP, it passes
that signal to the dispatcher, too. The dispatcher in turn passes those signals to its
child processes."
I have some questions for it:

1. My understanding is -- audip-remote as a child of audispd, I wanna know what's the IPC of audisp-remote and audipd, that's to say: how the audip-remote get the audit log(just as /var/log/audit/audit.log info) from the audispd?
2. Just as studying, If I I want write a another binary file(with help of C & gcc) for a plugin usage, How do I get this done?

Thanks a lot.

Hi, I use libaudit library 2.6.7 on Debian Stretch.

I have a question for using Python binding (2.7). I want to search events via API search_add_expression() function based on exe path.

So, I wrote:

parser.search_add_expression('exe i= /usr/sbin/cupsd', AUSEARCH_RULE_AND)

but I have exception

EnvironmentError: Value expected, got `/usr/'

I change this to:

parser.search_add_expression('exe i= "/usr/sbin/cupsd"', AUSEARCH_RULE_AND)

and my program crash with errcode 245 (echo $?)

What's wrong? Thank you!

As of linux-audit/audit-kernel@fa516b6 support was added in the kernel for the AUDIT_INTEGRITY_EVM_XATTR record with the EVM_ADD_XATTRS config option. Its record number is 1806. It has a field "xattr=" with result field "res=".

Add userspace audit tool support for the features introduced by kernel audit container ID support.

• AUDIT_CONTAINER_OP records
• AUDIT_CONTAINER_ID records

See: linux-audit/audit-kernel#90
See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID

Enabling the option of Python3 bindings in Void Linux I got an error, although the build completed.
It seemed to originate from the audit Python src.

/audit-2.7.3$ ag "def set_aumessage_mode"
bindings/swig/python/audit.py
1782:def set_aumessage_mode(mode, debug):

bindings/swig/python3/audit.py
1626:def set_aumessage_mode(mode: 'message_t', debug: 'debug_message_t') -> "void":



 Warning in make output:
libtool: warning: remember to run 'libtool --finish /usr/lib/python3.5/site-packages'
 /usr/bin/mkdir -p '/destdir//audit-2.7.3/usr/lib/python3.5/site-packages'
 /builddir/.xbps-audit/wrappers/install -c -m 644 audit.py '/destdir//audit-2.7.3/usr/lib/python3.5/site-packages'
Byte-compiling python modules...
audit.py  File "/usr/lib/python3.5/site-packages/audit.py", line 719
    def set_aumessage_mode(mode: 'message_t', debug: 'debug_message_t') -> "void":
                               ^
SyntaxError: invalid syntax


Byte-compiling python modules (optimized versions) ...
audit.py
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/builddir/audit-2.7.3/bindings/swig/python3'

audit273andpython3op.txt

When checkpointing a single file, a'la

ausearch --input /tmp/auditlogfile.txt --checkpoint /tmp/somefile.txt

the resultant checkpoint file does not record the input file's device or inode information in the checkpoint file.

Hello,

The last version of audit (2.8.4) FTBFS on several debian architectures withe the following error:

/usr/bin/ld: lookup_test.o: file not recognized: file truncated

I believe this is an issue because the tests are run in parallel and that doesn't cope well with AUTOMAKE_OPTIONS = no-dependencies? Must the test be run with -j1? Shouldn't the Makefile declare .NOTPARALLEL or MAKEFLAGS += -j1?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907538
https://buildd.debian.org/status/logs.php?pkg=audit&ver=1%3A2.8.4-1

Adding the time keywords "this-boot" to --start and "last-boot" to --end could be very useful to avoid having to figure these values out and parse them.

Audit supports filtering events by executable name - auditctl option '-F' can be given field "exe". However, this new functionality is not documented in man page yet.

Linux kernel capabilities were augmented to include ambient capabilities in
v4.3 commit 58319057b784 ("capabilities: ambient capabilities").

Add interpretation types for cap_pa, old_pa, pa.

The record contains fields "old_pp", "old_pi", "old_pe", "new_pp", "new_pi", "new_pe" so in keeping with the previous record normalizations, change the "new_p*" variants to simply drop the "new_" prefix.

A sample of the replaced BPRM_FCAPS record:
RAW: type=BPRM_FCAPS msg=audit(1491468034.252:237): fver=2 fp=0000000000200000 fi=0000000000000000 fe=1 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 old_pa=0000000000000000 pp=0000000000200000 pi=0000000000000000 pe=0000000000200000 pa=0000000000000000

INTERPRET: type=BPRM_FCAPS msg=audit(04/06/2017 04:40:34.252:237) : fver=2 fp=sys_admin fi=none fe=chown old_pp=none old_pi=none old_pe=none old_pa=none pp=sys_admin pi=none pe=sys_admin pa=none

A sample of the replaced CAPSET record:
RAW: type=CAPSET msg=audit(1491469502.371:242): pid=833 cap_pi=0000003fffffffff cap_pp=0000003fffffffff cap_pe=0000003fffffffff cap_pa=0000000000000000

INTERPRET: type=CAPSET msg=audit(04/06/2017 05:05:02.371:242) : pid=833 cap_pi=chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_pacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,audit_read cap_pp=chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_pacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,audit_read cap_pe=chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_pacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,audit_read cap_pa=none

Hi,

Information about my system

• Kernel:

Linux thinkpad 4.19.12-arch1-1-ARCH #1 SMP PREEMPT Fri Dec 21 13:56:54 UTC 2018 x86_64 GNU/Linux

• Distribution: Archlinux
• audit package version: 2.8.4

Issue

Summary: In some messages, there's a null byte appended to the rule messages, which I think should not be there.

More detailed informations

I'm playing with the following:

strace -X verbose -s 2000 auditctl -w /etc/passwd -p rwxa
strace -X verbose -s 2000 auditctl -l

Here is what auditctl sends when I create the rule:

sendto(4, {{len=1068, type=0x3f3 /* AUDIT_ADD_RULE */, flags=0x5 /* NLM_F_REQUEST|NLM_F_ACK */, seq=2, pid=0}, "\x04\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x69\x00\x00\x00\x6a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x0f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x00"}, 1068, 0, {sa_family=0x10 /* AF_NETLINK */, nl_pid=0, nl_groups=00000000}, 12) = 1068

I'm confused by the trailing \x00, because the value for the AUDIT_WATCH field is \x0b\x00\x00\x00, meaning the string length is 11 but it's actually 12 bytes if we include the last null byte. Moreover, this null byte disappears if I have another field with a string. For instance, with strace -X verbose -s 2000 auditctl -w /etc/passwd -p rwxa -k mykey, I see that the following message is being sent:

sendto(4, {{len=1072, type=0x3f3 /* AUDIT_ADD_RULE */, flags=0x5 /* NLM_F_REQUEST|NLM_F_ACK */, seq=2, pid=0}, "\x04\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x69\x00\x00\x00\x6a\x00\x00\x00\xd2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x0f\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x40\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x6d\x79\x6b\x65\x79"}, 1072, 0, {sa_family=0x10 /* AF_NETLINK */, nl_pid=0, nl_groups=00000000}, 12) = 1072

Finally, even the kernel seems confused by the last byte, because when doing strace -X verbose -s 2000 auditctl -l, the response has an invalid length:

recvfrom(3, {{len=1067, type=0x3f5 /* AUDIT_LIST_RULES */, flags=0x2 /* NLM_F_MULTI */, seq=1, pid=0}, "\x04\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x69\x00\x00\x00\x6a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x0f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64"}, 65536, 0, {sa_family=0x10 /* AF_NETLINK */, nl_pid=0, nl_groups=00000000}, [12]) = 1068

strace indicates that 1068 were read but the header says the message is 1067 bytes long. That does not seem right.

I hope this issue is clear enough, let me know if you need anything else.

The audit_rule_interfield_comp_data() and audit_rule_fieldpair_data() option field parsers use over 30 hard-coded numerical error codes to select an error message when errors are detected. Use meaningfully named macros to make the code easier to understand and verify.

The command:

auditctl --reset-lost

prints a lost value of 2 when the lost value is 0.

This first run is from a fresh boot with a lost value of 10, giving the expected result:

[root@rawhide ~]# auditctl -s
enabled 1
failure 1
pid 337
rate_limit 0
backlog_limit 64
lost 10
backlog 0
backlog_wait_time 60000
loginuid_immutable 0 unlocked
[root@rawhide ~]# auditctl --reset-lost
lost: 10
[root@rawhide ~]# echo $?
0

Userspace and Kernel Versions:

[root@rawhide ~]# rpm -q audit
audit-2.8.1-1.fc28.x86_64
[root@rawhide ~]# uname -r
4.14.0-0.rc6.git0.1.1.secnext.fc28.x86_64

Here's a second run just after it has been reset:

[root@rawhide ~]# auditctl -s
enabled 1
failure 1
pid 337
rate_limit 0
backlog_limit 64
lost 0
backlog 0
backlog_wait_time 60000
loginuid_immutable 0 unlocked
[root@rawhide ~]# auditctl --reset-lost
lost: 2
[root@rawhide ~]# echo $?
0

The value is expected to be:

lost: 0

Here are the raw CONFIG_CHANGE records:

type=CONFIG_CHANGE msg=audit(1509727848.777:233): lost=0 old=10 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=1
type=CONFIG_CHANGE msg=audit(1509727912.295:234): lost=0 old=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=1

Interpreted:

type=CONFIG_CHANGE msg=audit(11/03/2017 12:50:48.777:233) : lost=0 old=10 auid=root ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=yes 
----
type=CONFIG_CHANGE msg=audit(11/03/2017 12:51:52.295:234) : lost=0 old=0 auid=root ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=yes

strace of the first run (lost 10), look for "error=":

recvfrom(3, {{len=76, type=NLMSG_ERROR, flags=0, seq=2, pid=2488758578}, {error=10, msg={{len=56, type=AUDIT_SET, flags=NLM_F_REQUEST|NLM_F_ACK, seq=2, pid=0}, "\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"...}}}, 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 76
recvfrom(3, {{len=76, type=NLMSG_ERROR, flags=0, seq=2, pid=2488758578}, {error=10, msg={{len=56, type=AUDIT_SET, flags=NLM_F_REQUEST|NLM_F_ACK, seq=2, pid=0}, "\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"...}}}, 8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 76

strace of the second run (lost 0), look for "error=":

recvfrom(3, {{len=36, type=NLMSG_ERROR, flags=0, seq=2, pid=3432050465}, {error=0, msg={len=56, type=0x3e9 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK, seq=2, pid=0}}}, 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 36
recvfrom(3, {{len=36, type=NLMSG_ERROR, flags=0, seq=2, pid=3432050465}, {error=0, msg={len=56, type=0x3e9 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK, seq=2, pid=0}}}, 8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 36

SessionID support was added in audit-userspace 2.7, commit:
5d89887 2016-10-19 ("In libaudit, add support for rules using sessionid")

The auditctl(8) manpage update was missed at that time. Add it.

Tracefs or debugfs were causing hundreds to thousands of PATH records to
be associated with the init_module and finit_module SYSCALL records on a few modules when the following rule was in place for startup:
-a always,exit -F arch=x86_64 -S init_module -F key=mod-load

Add the new "path" filter list anchored in __audit_inode_child() to
filter out PATH records from uninteresting filesystem types, "fstype",
keying on their kernel hexadecimal 4-octet magic identifier.

An example rule would look like:
-a never,path -F fstype=0x74726163 -F key=ignore_tracefs
-a never,path -F fstype=0x64626720 -F key=ignore_debugfs

See: linux-audit/audit-kernel#8
Test case: linux-audit/audit-testsuite#42

Hi, I asked for escaping non-standart ASCII raws in #56 previously.

Now I wrote messages into auditd daemon and want to decode them out.
Auditd' Python API wrote me unescaped values like this:

event=D09FD0BED0B4D0BAD0BBD18ED187D0B5D0BDD0B8D0B5

how can I decode them?

I find there is no line " _S(xx, "chmod") " in lib/aarch64_table.h.
Is chmod not supported by audit-userspace with aarch64？