PCI DSS Linux: Creation and deletion of system-level objects

Some areas are within the PCI DSS standard are definitely not directly clear when reading the description. Section 10.2.7 is one of them. It talks about the creation and deletion of system-level objects and specifically the ability to log them.

System-level objects?

The guidance in 10.2.7 speaks about malware and mentions database related items. That does not make auditing very obvious, as malware usually targets binaries. Therefore we have to look first what a system-level object is.

Let’s start with a possible definition:

System-level object:

Anything on a system which is required for its operation, including the kernel, executables/binaries, configuration files, libraries, drivers and software applications.

For Linux and Unix based systems this equals to directories like /bin, /sbin, /etc/, /var/lib etc. In this article we will set-up auditing on the most important system objects of Linux system.

Monitoring system-level objects

To protect important areas of the Linux system, proper file permissions will help to safeguard it against unauthorized change or deletion. Defending is for PCI not enough, as we also need proof that accounting is in place. For that we can use the Linux audit framework.

All rules shared in this article can be easily tested by adding them with auditctl, followed by the rule itself. Rules start with -a, to indicate they should be added to the existing rule base. By defining a -d as first parameter, we can delete the related rule again.

Auditing Linux kernel

First area to audit is the Linux kernel itself. Every alteration, including upgrades, should be properly prepared, installed and finally be logged. With the audit daemon we can monitor any changes to the kernel files itself. As we want to keep an eye on the boot configuration as well, monitoring /boot is a great start.

-a always,exit -S all -F dir=/boot -F perm=aw -k system-objects

Auditing system binaries

Next area is auditing the system binaries. There are divided over several directories. You have to look at your system where binaries are listed. Usually displaying the $PATH variable will give a good indication.

-a always,exit -S all -F dir=/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/sbin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/local/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/local/sbin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/sbin -F perm=aw -k system-objects

Note: Check your system if there are any other directories containing binaries and not being a subdirectory of any of these entries above.

Auditing system libraries

Last are the system libraries. They contain system calls and supporting functionality for most of the system binaries.

-a always,exit -S all -F dir=/lib -F perm=aw -k system-objects


-a always,exit -S all -F dir=/lib64 -F perm=aw -k system-objects


-a always,exit -S all -F dir=/usr/lib -F perm=aw -k system-objects

Some distributions mights use /usr/lib/. As we already have a watch on the /usr/lib, these should be included (because of the usage of dir).

Auditing configuration files

Most of the configuration files are stored in /etc. If you have other locations, add them as well.

-a always,exit -S all -F dir=/etc -F perm=aw -k system-objects

Auditing systemd

If your system is using systemd, don’t forget to audit the related directories as well.

-a always,exit -S all -F dir=/usr/lib/systemd/ -F perm=aw -k system-objects

Note: If you are already auditing /usr/lib with the -F dir=, the systemd directory will be included.

Monitoring databases

As the guidance provides hints to databases, we suggest to monitor the related database directories as well. The creation of deletion of a database might be useful to log. However, keep in mind on what is actually being logged and not to have too much accounting data, as database can be change very regularly.

Another useful thing is to consult the documentation of the database software, to ensure stored procedures and changes to tables are logged.


The defined rules with permission “aw” will be triggered when an item is created, updated or deleted from the specified directories. The “a” permission is responsible for monitoring the creation and deletion, as these involve the change of the attributes of the file. While writing, the attributes (e.g. mtime) will change as well. The writing to the file is monitored with the “w” permission definition.

Search events

After an event is logged, it can be discovered with the ausearch utility. Simply provide the -k parameter, followed by the earlier defined name “system-objects”.

Automatic auditing with Lynis

To ensure your systems are PCI compliant, use supporting tools like Lynis, to check your PCI compliance on a regular basis. This way changes can be discovered quickly, avoiding a failure at the next audit.

Happy auditing!


Small picture of Michael Boelen

This article has been written by our Linux security expert Michael Boelen. With focus on creating high-quality articles and relevant examples, he wants to improve the field of Linux security. No more web full of copy-pasted blog posts.

Discovered outdated information or have a question? Share your thoughts. Thanks for your contribution!

Mastodon icon