PCI DSS (v3) for Linux: Auditing application processes (A.1.2.a)
PCI DSS (v3) Linux: Auditing application processes (A.1.2.a)
A.1.2.a Verify the user ID of any application process is not a
privileged user (root/admin).
For Unix and Linux based systems, processes should run as a non-privileged user where possible. However to be able to start, a process is usually started with root permissions (uid 0). This is required to open the required sockets (e.g. bind to port 80).
After the initial start, the process drops its privileges by switching to another user. In some cases there will maintain one master process, which is started with uid 0 as well. This process is responsible for the creation of child processes, not for handling interactions with users or processes. You can consider this as an administrative process. The child processes do handle
To gather a list of application processes running under the context of root, we can query ps and list all related entries.
ps -ef | grep "^root"
Another way is to combine a few commands and only list the interesting processes, like this:
ps -ef | awk '{ if ($1=="root") { print $8 }}' | grep -v "^\[" | sort | uniq | egrep -v "^(\-su|awk|egrep|grep|ps|sort|uniq|su|sudo)"
With this command we query ps, filter out application processes running under the context of root and hide commands which are not interested.
Usually this will still be a list of several items. Every process which has a master process, which have at least one process running under the root context. This is acceptable behavior as explained before. Other processes have to be analyzed by hand, to see if they are properly configured.
This information is provided as guidance to our PCI plugin for Lynis.
8:29 PM
Great technical article on PCI compliance. As a PCI-QSA, non-MS Windows systems can be a challenge. With that said, don’t forget that depending on which of the PCI DSS Self-Assessment Questionnaires (SAQ) you have to comply with, you may be mandated to undertake vulnerability scanning and even a penetrations test. While scanning can be relatively cost-effective, penetration tests can be expensive, so just keep that in mind. And if you are going through an actual onsite assessment with a PCI-QSA, then often times both scanning and penetration testing is mandated. These are often the “hidden” mandates that many merchants and service providers initially fail to recognize, but they can be incredibly time-consuming and expensive, especially when it comes to remediating any failures associated with vulnerability scans, both internally and externally. PCI compliance is here to stay, so also make sure you’ve got in place all necessary policies and procedures, because that’s a big mandate also.
7:48 PM
Thanks Charles, great input!