Hello all, i'm trying to implement hardened installation of auditbeat on host (running not from root, limiting exposed capacities via systemd AmbientCapacities/setcap). Auditbeat version is 8.17
If i use config option socket_type: multicast in config and set the following capacities CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_ADMIN, CAP_NET_RAW (testing the different sets of capacities related to connection to auditd multicast socket) and CAP_AUDIT_READ, CAP_AUDIT_CONTROL (enabling the actual read from auditd socket, AUDIT_CONTROL is needed for obtaining actual auditd state), auditbeat refuses to collect auditd logs with following error:
"message":"Failure receiving audit events","service.name":"auditbeat","error":{"message":"failed to enable auditing in the kernel: failed sending request: operation not permitted"}
But - documentation is clearly states that using socket_type = multicast auditbeat will only read audit events, without trying to write data to auditd socket (like defining own set of rules?)
Moreover, sourcecode of auditbeat regarding binding to multicast socket have comment that states "yes, we got an EPERM at that moment if process does not have CAP_AUDIT_CONTROL capability, but ok we will ignore it" (beats/auditbeat/module/auditd/audit_linux.go at main · elastic/beats · GitHub) - but in fact a) i'm explicitly give necessary cap and b) auditbeat does not ignore "absent" cap, but just refusing to read audit logs
If i read sources correctly, initClient() tries to manually enable audit subsystem (https://github.com/elastic/go-libaudit/blob/main/audit.go#L346), but is this really how it should be?
Perhaps my attempts are useless, and auditbeat must always be run under root 
I am, alas, struggling to reproduce this.
Can you be more specific on how you're setting abilities here? You mentioned AmbientCapabilities, can you post the systemd unit file you're modifying? Also, can you post the output of uname -a?
Yes, sure, as a starting point i use systemd unit from official deb package. Full contents of my unit here:
[Unit]
Description=Minimal unit for auditbeat run
Wants=network-online.target
After=network-online.target
[Service]
UMask=0027
User=auditbeat
Environment="BEAT_CONFIG_OPTS=-c /etc/auditbeat/auditbeat.yml"
Environment="BEAT_PATH_OPTS=--path.home /usr/share/auditbeat --path.config /etc/auditbeat --path.data /var/lib/auditbeat --path.logs /var/log/auditbeat"
ExecStart=/usr/share/auditbeat/bin/auditbeat --environment systemd $BEAT_LOG_OPTS $BEAT_CONFIG_OPTS $BEAT_PATH_OPTS
Restart=always
NoNewPrivileges=false
AmbientCapabilities=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BROADCAST
AmbientCapabilities=CAP_NET_ADMIN
AmbientCapabilities=CAP_NET_RAW
AmbientCapabilities=CAP_AUDIT_READ
AmbientCapabilities=CAP_AUDIT_WRITE
AmbientCapabilities=CAP_AUDIT_CONTROL
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BROADCAST
CapabilityBoundingSet=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_RAW
CapabilityBoundingSet=CAP_AUDIT_READ
CapabilityBoundingSet=CAP_AUDIT_WRITE
CapabilityBoundingSet=CAP_AUDIT_CONTROL
SecureBits=keep-caps
[Install]
WantedBy=multi-user.target
Tested this unit on:
- Stock Debian 10 Linux audbeatst1 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64 GNU/Linux
- Local derivative of Debian 10 with more recent kernel Linux audbeatst2 6.1.90-1-generic #astra3+ci20 SMP PREEMPT_DYNAMIC Mon Jul 22 14:15:46 UTC 2024 x86_64 GNU/Linux
Planning to test this capabilities on more recent systems for comparison
Both stands shows identical results
EDIT: I tested my unit on Ubuntu 24.04 - and auditbeat works as intended
So this issue occurs only on rather outdated distros (which unfortunately i cannot upgrade to something fresh)
So, I'm still tinkering with this in a debian VM, but I'm getting a complete different error: Exiting: 1 error: failed to create audit data client: failed to open audit netlink socket: bind failed: operation not permitted
This appears to be because systemd isn't actually applying cap_audit_read, although I'm not sure why.
It might help to set a PreExec flag value like ExecStartPre=/usr/bin/setpriv -d so we can dump the capabilities that are actually effective for the auditbeat process.
Yes, it's really does not apply this cap
Output of setpriv:
Mar 28 05:11:27 deb-audbeat setpriv[6133]: uid: 1001
Mar 28 05:11:27 deb-audbeat setpriv[6133]: euid: 1001
Mar 28 05:11:27 deb-audbeat setpriv[6133]: gid: 1001
Mar 28 05:11:27 deb-audbeat setpriv[6133]: egid: 1001
Mar 28 05:11:27 deb-audbeat setpriv[6133]: Supplementary groups: 1001
Mar 28 05:11:27 deb-audbeat setpriv[6133]: no_new_privs: 0
Mar 28 05:11:27 deb-audbeat setpriv[6133]: Inheritable capabilities: net_bind_service,net_broadcast,net_admin,net_raw,audit_write,audit_control
Mar 28 05:11:27 deb-audbeat setpriv[6133]: Ambient capabilities: net_bind_service,net_broadcast,net_admin,net_raw,audit_write,audit_control
Mar 28 05:11:27 deb-audbeat setpriv[6133]: Capability bounding set: net_bind_service,net_broadcast,net_admin,net_raw,audit_write,audit_control,audit_read
Mar 28 05:11:27 deb-audbeat setpriv[6133]: Securebits: [none]
Mar 28 05:11:27 deb-audbeat setpriv[6133]: Parent death signal: [none]
Mar 28 05:11:27 deb-audbeat setpriv[6133]: AppArmor profile: unconfined
cap_audit_read is only in BoundingSet, but absent in Inheritable/Ambient... capabilities
My suspicions that this is not the issue with auditbeat, but sort of a bug (or intended behavour) in systemd 241, which is used in Debian 10
If so, i can just workaround this behaviour by explicit run of setcap in systemd unit (already tested this approach, it works flawlessly)
Remark for history: i made an experiment, in which i compiled my own version of auditbeat, but with commented out lines 304-307 in audit_linux.go (where auditbeat tries to enable auditing in multicast mode). And with these "patch" i never have original error on older systems I still test my build on various distros, even older than debian 10, just for verification of some rare use-cases