# Auditbeat triggers seccomp violations?
**URL:** https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700
**Category:** Beats
**Tags:** auditbeat
**Created:** [June 13, 2019, 4:41pm UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700 "2019-06-13T16:41:05Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@arlen](https://discuss.elastic.co/u/arlen)
#### Post date: [June 13, 2019, 4:41pm UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700/1 "2019-06-13T16:41:05Z")
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?
---
### Author:  [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)
#### Post date: [June 13, 2019, 5:12pm UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700/2 "2019-06-13T17:12:25Z")
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.
---
### Author:  [@arlen](https://discuss.elastic.co/u/arlen)
#### Post date: [June 13, 2019, 8:08pm UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700/3 "2019-06-13T20:08:07Z")
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
---
### Author:  [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)
#### Post date: [June 14, 2019, 12:56am UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700/4 "2019-06-14T00:56:20Z")
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](https://www.elastic.co/guide/en/beats/auditbeat/current/linux-seccomp.html)
BTW the whitelist policy that is uses by default is [here](https://github.com/elastic/beats/blob/master/libbeat/common/seccomp/policy_linux_amd64.go).
---
### Author:  [@arlen](https://discuss.elastic.co/u/arlen)
#### Post date: [June 17, 2019, 2:19pm UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700/5 "2019-06-17T14:19:45Z")
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.
---
### Author:  [@arlen](https://discuss.elastic.co/u/arlen)
#### Post date: [June 17, 2019, 7:10pm UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700/6 "2019-06-17T19:10:03Z")
>
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 8, 2019, 7:10pm UTC](https://discuss.elastic.co/t/auditbeat-triggers-seccomp-violations/185700/7 "2019-07-08T19:10:08Z")
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.