PCI DSS and Red Hat Enterprise Linux (Final part #9)

Requirement A.1: Shared hosting providers must protect the cardholder data environment


The most obvious method to fulfill the requirements given in section А.1 is to assign a virtual server (or a set of servers) that meets the requirements from the chapters described above to every client .
There are no analogous requirements in the CIS standards

A.1.1 If a shared hosting provider allows entities (for example, merchants or service providers) to run their own applications, verify these application processes run using the unique ID of the entity. For example:
No entity on the system can use a shared web server user ID.
All CGI scripts used by an entity must be created and run as the entity’s unique user ID.

Distribution of user privileges is described in the item 7.2.1 in details. Here, most settings can be applied and checked in a similar way (for example, by using su/sudo and group membership). The second recommendation given in this item should be considered separately – if there are different users and one web server, one can find it reasonable to set SUID flag for CGI scripts.

A.1.2.a Verify the user ID of any application process is not a privileged user (root/admin).

Here, recommendations similar to those given in the item 7.2.1 are applied.

A.1.2.b Verify each entity has read, write, or execute permissions only for files and directories it owns or for necessary system files (restricted via file system permissions, access control lists, chroot, jailshell, etc.). IMPORTANT: An entity’s files may not be shared by group.

The basic recommendations are given in the item 7.1.1.

For convenience of user management, user data is often placed within one upper-level directory (/home by default), which allows one to check access permissions of home directories easily. In the simplest case, it is enough to set access permissions 700 and verify that there is no ACL for each home directory.

To provide additional access restriction, it is necessary to specify umask 0077 in the configuration file of a corresponding applied service (/etc/bashrc, /etc/vsftpd/vsftpd.conf, etc.). If the structure of user directories is more complex, then it is possible to apply custom scripts based on the command find and developed to solve a concrete problem.

A.1.2.c Verify an entity’s users do not have write access to shared system binaries.

The problem stated in this item can be solved by applying a script that uses the list of users and the find command and recursively scans the directories defined with the following regular expression

The specified path may be supplemented depending on the software installed in the system (commercial software is often installed to /opt) and the value of the $PATH variable for each user.

A.1.2.d Verify that viewing of log entries is restricted to the owning entity.

Check is trivial and includes access permissions and ACLs; all other aspects (including settings of users and administrative privileges) have been already considered in corresponding sections.

A.1.2.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities, verify restrictions are in place for the use of these system resources:
Disk space

To restrict resource usage, both OS instruments (if user applications run in one OS) and virtualization tools (KVM, Xen, OpenVZ/Virtuozzo, VMWare ESX, VMWare Server, Microsoft Hyper-V, etc.) can be applied. Let us consider standard Linux tools, since every virtualization machine implements its own internal mechanisms of resource usage restriction and description of these mechanisms goes beyond the scope of this article.

I. To restrict client usage of the disc space, perform the actions described below.

Firstly, it is necessary to verify that all user-writable directories (these are, at least, /home and /tmp) are located in separate disc partitions. Furthermore, it is necessary to assign separate partitions for /var/log and/var/log/audit (advisable).

Secondly, it is necessary to set user quotas. If an EXT3/EXT4 file system (XFS is not considered because this file system is not completely supported by RHEL) is used, then it is necessary to perform the following actions:

1. For user-writable partitions, specify the following settings in the /etc/fstab mounting options:
After that, rename the corresponding file system (FS):
mount $FS -o remount

2. In each partition root (let it be /tmp and /home), create two binary quota files:
for fs in /tmp /home; do
cd \”$fs\”
touch aquota.user aquota.group
chmod 600 aquota.user aquota.group
cd –

3. For the mounted FS, quotas are activated by execution of the following commands:
quotacheck -aRvugm
quotaon -avug

4. To edit user and group quotas, as well as the “grace period”, the command edquota is used. At that, a separate user or group quota can be defined for each FS.

5. To view data about user and FS quota usage, you can execute the following commands:
quota [-u user] [-g group] – every user can obtain data about his/her quotas and their usage;
repquota [-a] [-v] – outputs data about quota usage for every FS (it is more visual then quota output).

6. Additional information about disc quotas can be found in the following man pages: mount, quotacheck, quotaon, quotaoff, edquota, quota, repquota.

Note. If virtual machines are used for client software, then the disc space is usually limited to the virtual disc size that is assigned to a virtual machine.

II. To restrict the channel usage, network equipment is usually applied.

It is a complicated problem to restrict outgoing and incoming traffic (of all types and protocols) for a certain user by OS means on a shared server providing services to multiple users. Solution of this problem is not described in any vendor documentation (at least, neither RedHat, nor Fedora report about it officially).

The simplest solution is to limit the bandwidth for users who use dedicated virtual servers with own IP addresses for their tasks. In this case, it is possible to set restrictions on server via the utility tc [1] or create rules of traffic restriction based on IP address analysis on network equipment.

III. Restriction of RAM usage

The RAM size of user processes can be restricted in the file /etc/security/limits.conf (which is associated with the module pam_limits). For example, a restriction for the user alex will look as follows:
alex as N

Here, N is the maximal RAM size (in kilobytes) assigned to the processes of this user, “as” (address space) specifies the restriction type, and “-” sets both limitation types at the same time – “soft” and “severe”.

It was experimentally found out that for one bash instance, it is necessary to allocate at least 10 MB; at that, bash session will be initialized with errors and not all standard command string utilities will run (the corresponding messages are set off in bold):

[root@blacknet security]# su – alex
id: cannot find name for user ID 501
-bash: warning: setlocale: LC_CTYPE: cannot change locale (ru_RU.UTF-8): No such file or directory
[ … ]
id: cannot find name for user ID 501
[I have no name!@blacknet ~]$ date
Mon Jul 12 10:55:03 MSD 2010
[I have no name!@blacknet ~]$ dd if=/dev/zero bs=1M count=100 | bzip2 -9c > /dev/null
bzip2: couldn\’t allocate enough memory
Input file = (stdin), output file = (stdout)

Note. There can possibly exist a directory /etc/security/limits.d/ containing files that also define various user restrictions.

The virtualization tools mentioned above allow one to limit the size of RAM assigned to every virtual server.

IV. Restriction of CPU usage

Traditional methods of CPU usage restriction do not allow one to specify limits in percents, although this form is the most convenient one. Third-party developers try to change the situation – for example, there is an utility cpulimit [2], but it operates rather primitively (by sending signals SIGSTOP and SIGCONT to the processes), doesn’t allow one to restrict access for users and groups (only for processes and their children), and has many other weaknesses.

Among open-source virtualization tools, OpenVZ is the most flexible one to set CPU usage restrictions. However, it is recommended to disable SELinux when using this tool according to [3], in contrast to officially-supported KVM and Xen.

A.1.3.a Verify the shared hosting provider has enabled logging as follows, for each merchant and service provider environment:
Logs are enabled for common third-party applications.
Logs are active by default.
Logs are available for review by the owning entity.
Log locations are clearly communicated to the owning entity.

Taking into account that client software can be very different, it is impossible to give general recommendations for logging on a shared server. The only thing that can be advised in this situation is to use virtual servers for every client. A brief review of various platform virtual machines can be found in [4].


3 thoughts on “PCI DSS and Red Hat Enterprise Linux (Final part #9)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.