Auditbeat triggers seccomp violations?

Elastic Stack Beats
1

So I fired up auditbeat (6.8) as a test on one of my servers to see how it does at collecting audit events. Imagine my surprise when I find over 1/3 of the audit events (runs to about 1400/hour) have auditbeat itself listed as the "how", and they're all violated.seccomp.policy

Is that normal?

2

Can you please share the event containing the syscall causing the violation as well as the OS version you are using. Sometimes glibc changes and new syscalls need to be whitelisted.

3

Hmmm. I can't pull the source from the audit log, as I have to turn that off to get auditbeat to run. Is this what you're after? (redacted a bit, b/c paranoia)

OS CentOS Linux release 7.6.1810 (Core) (system is under construction so it's most recent kernel from the repo).

{
"_index": "auditbeat-6.8.0-2019.05.01-000001",
"_type": "doc",
"_id": "B6RqUmsBpU7bo5LMCy3Q",
"_version": 1,
"_score": null,
"_source": {
"@timestamp": "2019-06-13T19:56:46.740Z",
"process": {
"pid": "28562",
"name": "auditbeat"
},
"auditd": {
"data": {
"ip": "0x7f502a063bc7",
"sig": "0",
"syscall": "95",
"arch": "c000003e",
"code": "0x50000",
"compat": "0"
},
"summary": {
"actor": {
"primary": "unset",
"secondary": "root"
},
"object": {
"type": "process",
"primary": "95"
},
"how": "auditbeat"
},
"sequence": 46792,
"result": "unknown",
"session": "unset"
},
"beat": {
"name": "redacted",
"hostname": "redacted",
"version": "6.8.0"
},
"host": {
"name": "redacted",
"id": "b97ee8e8fbeb4d18bcc27d8f3b95f554",
"containerized": true,
"architecture": "x86_64",
"os": {
"version": "7 (Core)",
"family": "redhat",
"name": "CentOS Linux",
"codename": "Core",
"platform": "centos"
}
},
"event": {
"category": "dac-decision",
"type": "seccomp",
"action": "violated-seccomp-policy",
"module": "auditd"
},
"user": {
"uid": "0",
"selinux": {
"domain": "unconfined_service_t",
"level": "s0",
"role": "system_r",
"user": "system_u"
},
"name_map": {
"gid": "root",
"uid": "root"
},
"gid": "0",
"auid": "unset"
}
},
"fields": {
"@timestamp": [
"2019-06-13T19:56:46.740Z"
]
},
"sort": [
1560455806740
]
}

If I'm understanding that aright, the syscall is umask

4

Yeah, that's right. 95 is umask on x86_64. Can you please on a bug report on github for this issue.

I'm curious what's utilizing umask so I'll have to take a look by setting up a CentOS 7 VM and probably will run auditbeat in strace to try to figure that out.

If you want a work-around you can disable the seccomp filter by adding seccomp.enabled: false to your config file. Or you can set a custom policy via the config file. https://www.elastic.co/guide/en/beats/auditbeat/current/linux-seccomp.html

BTW the whitelist policy that is uses by default is here.

5

Sorry. Was out of office on Friday. I'll open the issue today.

As for what is using umask, the only thing on the system at the moment apart from a generic Centos7 system is vsftpd, so it may be a possible culprit. It has the directive local_umask=022 in it which aligns with other ftp systems, but may have an impact here. I didn't mention it b/c this happens whether there's an ftp upload happening or not, so it doesn't seem likely to be the case. If you have any trouble duplicating it, let me know and we can arrange a way for me to help you set up a close copy of the system config.

6
7

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.