PCI DSS and Red Hat Enterprise Linux (Part #5)

Requirement 7. Limit access to system components and cardholder data to only those individuals whose job requires such access
The both requirements given in this section are rather complex; many sub-systems are involved in configuration of OS in compliance with these requirements. CIS RHEL analogs of the requirement 7.2.1 are contained in items 8.1, 8.2, 8.5, 8.8, 9.2, 9.8, 9.11, SN.7, and SN.11, but these analogs don’t cover all access isolation mechanisms available in the system. Partial CIS analogs of the requirement 7.1.1 are presented in items 7.2 and 7.6.

7.1.1 Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities.

This requirement is too fuzzy. Generally speaking, it can be applied to any access settings from group membership to SELinux policies. Let us consider the most popular system tools of access control.
I. An important side of privilege isolation consists in control of access to file system objects (e.g. to database files, if the base is stored in the FS, not on a raw device). To grant access, the rwx method (which is traditional for UNIX systems) or system-level ACLs (Access Control Lists) can be used.
The most convenient way to reveal illegal access permissions (wrong rwx flags, incorrect owners and groups) is to apply the standard command find (with options –perm, –user, and -group), but this command doesn’t support ACL search.
The ACL mechanism is used to implement flexible access permission isolation in situations when the standard method “owner : group : others” is insufficient. This mechanism considerably expands features of files and directories access control, but it has a number of weaknesses (which will be described below). The ext3/ext4 file system must be mounted with the option “acl” to be able to apply ACLs; XFS doesn’t require this option.
IT IS IMPORTANT. RHEL5 doesn’t support XFS creation and management; the OS is able to work with pre-created XFSs only [1]. Nevertheless, you can receive the necessary utilities by addressing a manager [1] or by installing them without assistance [2 and 3] (at that, it remains unclear in what way the technical support conditions will change). The RHEL6 distribution kit is expected to contain full XFS support (along with ext4) [4].
To set extended access rights, the command setfacl is applied; to view access rights, the command getfacl is used.
For example, the following command
setfacl –m u:user1:rwx /path/to/file

will add a user “user1” with rwx permissions to the access list of the file /path/to/file.

You can recursively browse ACLs of files and directories by applying the following command:
getfacl –sR /path/to
Here, the “–s” option suppresses output of information about files and directories that have no ACLs.
In a listing, the objects that have ACLs are distinguished with the symbol “+” in the access right field (set off in yellow):
[root@rf12 ~]# ls -lF m*
-rw-r–r–. 1 root root 91620 Jun 10 15:48 mkinitrd-6.0.93-1.fc12.i686.rpm
-rwxrwx—+ 1 root root 7 Jun 30 15:46 my.sh*
At that, display of traditional access rights contains an error (not only for the command ls, but also for find, stat, etc.). As one can see, ls doesn’t properly display the access rights of a group: actually, the my.sh file has permissions 700; even find “believes” that the given file has permissions 770 (stat makes the same mistake):
[root@rf12 ~]# find ./ -type f -perm 770 -print
Meanwhile, the my.sh file has permissions 700 indeed (the contents of the field “group::—”):
[root@rf12 ~]# getfacl my.sh
# file: my.sh
# owner: root
# group: root
One can easily check it by an example. According to ls/find/stat, a user from the users group has a right to run this script, but the fact is that he/she will not be able to run it:
[root@rf12 ~]# cp -p my.sh /home/superadmin/
[root@rf12 ~]# chown root:users /home/superadmin/my.sh
[root@rf12 ~]# su – superadmin
[superadmin@rf12 ~]$ id -Gn
users wheel
[superadmin@rf12 ~]$ ll
total 8
-rwxrwx—+ 1 root users 7 Jul 1 17:58 my.sh
[superadmin@rf12 ~]$ ./my.sh
-bash: ./my.sh: Permission denied
Note. To save an ACL, commands of file operations require additional options (set off in yellow):

cp –p file-with-acl new-file-with-acl
tar –acls /path/to/archive.tar files-with-acl
rsync -auvA my.sh /home/user/
It also should be mentioned that ACLs will be stored only in FSs that support this option.
Moreover, the ACL of a program that was already installed will be lost after update of this program (set off in yellow):

[root@rf12 security]# setfacl -m u:user:rw /sbin/rdisc
[root@rf12 security]# getfacl -s /sbin/rdisc
getfacl: Removing leading \’/\’ from absolute path names
# file: sbin/rdisc
# owner: root
# group: root
[root@rf12 security]# rpm –quiet -U –force /mnt/cdrom/Packages/iputils-20071127-9.fc12.i686.rpm
[root@rf12 security]# getfacl /sbin/rdisc
getfacl: Removing leading \’/\’ from absolute path names
# file: sbin/rdisc
# owner: root
# group: root

Let us resume the discussion of ACLs and mention the following weaknesses of this mechanism:
1. Standard utilities don’t support ACLs; ACLs and rwx permissions are mixed up (the commands find, ls, and stat). The command find doesn’t work with ACLs; if it is necessary to control access permissions of files and directories considering ACLs, then one has to use recursive directory traversal with suppression of output of standard rwx permissions (getfacl –sR), as well as an in-house script (awk, perl, python, etc.).
2. It is necessary to apply additional command options or include aliases into /etc/bashrc:
alias cp=’cp –preserve=all’
alias rsync=’rsync –X’
alias tar=’tar –xattrs’
However, in this case (if default settings are used), user aliases (from $HOME/.bashrc) are zapped; e.g. for root, the value cp=’cp –i’ will be replaced with cp=’cp –preserve=all’. To correct this situation, one will have to edit the file /etc/bashrc additionally.

3. Improper or malicious setting of an ACL will endanger the whole system. If it is enough to use the standard rwx mechanism to restrict access, then it is recommended to disable ACLs forcibly by setting the option noacl in /etc/fstab for ext2/ ext3/ ext4 file systems.
4. It is impossible to disable this mechanism for XFS; hence, one should give special attention to XFS partitions.

II. The list of SUID/SGID applications should be continually controlled. This problem can be solved using rather simple methods, for example:
find / \\( -path /proc -o -path /sys -o -path /srv -o -path /dev -o -path /selinux \\) -prune -o -type f \\( -perm -4000 -fprintf /root/suid.log \”%p\\n\” -o -perm -2000 -fprintf /root/sgid.log \”%p\\n\” \\)
In this example, all detected SUID applications are listed in the file /root/suid.log and all SGID programs are listed in /root/sgid.log. Directories that don’t contain real files (/proc, /sys, /srv, /dev, and /selinux) are excluded from the search.
It is also recommended to configure control of integrity of detected executable files or at least ensure that users cannot change the contents of these files.
Additionally, all exterior file systems (CIFS, NFS, and external media) should be mounted with the option “nosuid” to avoid execution of unsafe programs from uncontrolled sources.
Analogs of these requirements are given in CIS RHEL v.1.1.2 in items 7.2 and 7.6.

III. We should also pay attention to the system SELinux. In spite of complicated configuration and application, it provides flexible data access settings for separate users and applications. Furthermore, the system supports data categorization, i.e. it allows one to classify data not only according to the privacy level, but also according to the knowledge domain (MLS mode). A separate voluminous paper can be devoted to SELinux configuration; moreover, RedHat has already developed full documentation on this problem [5, 6, and 7].

One thought on “PCI DSS and Red Hat Enterprise Linux (Part #5)

Leave a Reply

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