Info IT

PCI DSS and Red Hat Enterprise Linux Part 6

PCI DSS and Red Hat Enterprise Linux Part 6

Requirement 7. Limit access to system components and cardholder data to only those individuals whose job requires such access

7.2.1 Examine system settings and vendor documentation to confirm that access control systems are in place on all system components

The previous item was about data access control, and this one concerns user access isolation? Let us consider all widespread mechanisms of user privilege restriction. In examples, there will appear listings of commands executed with the root privileges, a user user for whom various permissions will be set, and a user superadmin who will not have the mentioned permissions in spite of the big name.

I. First of all, it is necessary to ensure that no outdated authentication mechanisms, e.g. rhosts in PAM (CIS 8.1) and .netrc (CIS 9.8), are used.

II. All system access mechanisms should be constantly controlled.

For example, you shouldn’t give a real login shell (bash, sh, etc.) to strictly mail users. If an FTP daemon is installed in the system, then it is necessary to check its settings both for anonymous and local users.

III. If a non-trusted user can obtain physical access to the local console of critical servers and/or workstations, one should not only use a BIOS password and disable the system ability to boot off external media in BIOS, but also set a password to enter the GRUB menu (or the single-user mode at least).

Why is it necessary?

It is necessary to use a GRUB password, because GRUB allows one to read files from a disc partition on conditions that GRUP can work with the FS of this partition (is executed at least on ext2/ext3). Thus, a user who has physical access to the host will be able to enter the boot menu during the host booting and read an arbitrary file from the disc. At that, GRUB will obviously not be able to read a file from an encrypted FS or from an FS created on a logical volume.

[root@rf12 etc]# grub --no-floppy
… [greeting is skipped] …
grub> cat (hd0,0)/grub/grub.conf
cat (hd0,0)/grub/grub.conf
# grub.conf generated by anaconda
… [a part of file is spipped] …
initrd /initramfs-2.6.31.5-127.fc12.i686.PAE.img
[Hit return to continue]
grub> quit
quit

Moreover, if a user will enter the GRUB menu, he/she will be able to set the boot level (including the single-user mode, when bash is launched by default on tty1 with the root privileges without asking a password). In case of a malicious user, the course of event may be extremely negative (at best, an urgent check of backup recovery regulation will be required).

To protect the local console, perform the following actions.
1. Execute the command
grub-md5-crypt
When prompted, enter the necessary password twice and save the obtained hash.
2. In the file /boot/grub/grub.conf, add the following string BEFORE every “title” command:
password --md5 saved_hash
3. Thereafter, the user will be able to choose any system from those listed in title to boot, but it will be impossible to change the booting settings (e.g. edit runlevel) without entering the GRUB password.
4. To disable the single-user mode, which doesn’t require password input, in modern distribution kits based on event loading, it is necessary to add the following string to the block “script… end script” in the file /etc/event.d/rcS-sulogin:
exec /sbin/sulogin
At that, the string “exec /bin/bash” must be deleted or commented out.
ATTENTION! After the described settings are applied to Fedora Core 12, an error in sulogin makes it impossible to input commands in single-user mode; moreover, even bash doesn’t display the input symbols from time to time in single-user mode.
5. For distribution kits with loading based on /etc/inittab, it is necessary to add the following string to /etc/inittab:
~~:S:respawn:/sbin/sulogin
In the third field of this string, one can specify both respawn or wait depending on the expected system behavior in single-user mode. In the former case, OS will stay at the run level 1 even after exiting the shell. In the latter case, the default level will be loaded after exiting bash. It should be noted that the first field may be represented with any string not longer than 4 symbols (not only “~~”) that doesn’t conflict with other entries in /etc/inittab.

IV. Further, one should configure su.

It is necessary to ensure that only the members of the wheel group can execute su; for this purpose, check the settings of the file /etc/pam.d/su, which must contain the following strings (the option use_uid is used to apply an effective UID instead of the initial one):

auth sufficient pam_rootok.so
auth required pam_wheel.so use_uid

At that, the file should not contain a string that allows the wheel members to input the target user password (including the root one) when executing su (otherwise, this string should be commented out):
auth sufficient pam_wheel.so trust use_uid
After that, add all users who should be allowed to execute the command su to the group wheel:
usermod -G wheel $username

V. It is necessary to check the sudo settings.

Let us concentrate on the main options of the configuration file /etc/sudoers. This file can be edited either directly or by using the command visudo (the latter method is preferable). The format of this file is common for all UNIX systems (Linux, Solaris, AIX, etc.). Additionally, it is recommended to look through the reference manual (man sudoers).

1. Settings for users and groups are put down in the following form:
username hostname = [([user][:group])] [modifier:] cmd1[, cmd2]…] [,[modifier:] …]
Here:
• […] – signifies that the parameter is optional;
• [,[modifier:] …] – signifies that one string can contain several rules for the same user. At that, the rule structure will stay invariable;
• username – the user or group name (with the “%” symbol at the beginning of the string, e.g. %wheel);
• hostname – the name of the host for which this rule is valid (usually ALL);
• ([user][:group]) – with privileges of what users (of members of what group) commands can be executed. The syntax:
• (user),
• (:group),
• (user:group) – commands can be executed with the privileges of this user or members of this group,
• (ALL) – commands can be executed with the privileges of any user (including root),
• so-called aliases (lists of users or groups) are also permissible.
If this parameter is not defined, then the command can be executed with the privileges of any user.
IT IS IMPORTANT. The syntax (:group) is applicable not for all sudo versions. For example, the version 1.7.1 (FC12) supports this option, but the versions 1.6.8 (RHEL5) and 1.6.9 (SLES11) don’t;
• modifier – a key word, for example:
• NOPASSWD – allow the user to execute these commands without entering his/her password,
• PASSWD – request user password for command execution (default behavior),
• NOEXEC – deny application of the tactics known as “escape to shell,” e.g. when a user who was allowed to execute vi can pass from vi to the shell using the UID that vi is running under (default behavior),
• EXEC – allow programs to apply the “escape to shell” mechanism;
• cmd – the command path and command arguments if necessary (the parameter can be specified in the form of a regular expression). The following entry types are possible:
• cmd1, cmd2, … – a list of commands (possibly with arguments),
• cmd1, !cmd2, … – cmd1 is allowed to be executed and cmd2 is not,
• command aliases can be used (for more details, see item 3).

2. Thus, possible entries in /etc/sudoers can look as follows:
• user ALL=(ALL) NOPASSWD: ALL – allow user to execute all commands with the privileges of all users without entering his/her password;
• user ALL=(root) /bin/kill [[:print:]]* – allow user to execute command kill with any arguments (denied without arguments) as a root;
• superadmin ALL=(:wheel) /bin/date, /bin/su [[:print:]]*, /sbin/shutdown -r, /usr/bin/id [[:print:]]*, (root) /bin/kill [[:print:]]* – the user superadmin can execute commands date and su (with arguments only, denied without them), restart computer, execute id (with arguments only) with the privileges of the group wheel, as well as execute kill with arguments as a root.
IT IS IMPORTANT. If such settings are applied, the user will be able to execute su without entering the password of the target user (including root), because he/she will be prompted once, not twice.

3. It is recommended to check the Defaults. For example, it is interesting to consider the option
Defaults targetpw
If it is enabled, then a user trying to execute a command as another user will have to enter the target user password, not his/her own (default behavior). For example, this option is set by default in SLES 11. In this case the sudo behavior will be similar to that of su, but the sudo mechanism is more flexible than su.
Note. In the described case, if a user will execute some command with the privileges of a group (new sudo versions), he/she will have to enter the root password (not his/her own) using the command
sudo –g groupname cmd
IT IS IMPORTANT! Wrong password input (if the option Defaults targetpw is not specified) or forced break of password input (Ctrl+C) is equated to incorrect input of accounting data; therefore, the failed login counter (pam_tally and pam_tally2; for more details, see section 8) is incremented in these cases, which can result in user to be locked. If the option targetpw is specified, then the counter related to the target, not to the current user is incremented; it can lead to extremely negative results. Thereby, it is recommended not to presume on the option targetpw.

4. It is recommended to specify the period during which commands can be executed without password input. By default, 5 minutes pass between two successive password inputs; during this period, a user can execute commands via sudo without entering a password. Duration of this interval is specified with the option
Defaults:username timestamp_timeout=N
Here, username can be set to ALL, N is the number of minutes (0 – an empty period, users will have to enter password every time; negative value – an infinitely long period).
IT IS IMPORTANT. The mentioned time interval starts at the moment of execution of the last sudo command. Thus, if time-out is 1 minute and user enters a command every 55 seconds, then he/she will not have to enter password every time. However, if a sudo command is executed after the previous one after a period of time that is longer than the interval, then the user will have to enter password. If the user logs out during the timestamp_timeout period and logs in again after that, then he/she will be able to execute sudo commands without password input.

5. Let us mention that a user must be not locked to be able to execute sudo. For example, if user was locked because of a series of failed logins and his session is open, then he/she will not be able to execute sudo from this session in spite of the fact that /etc/sudoers may contain a corresponding rule. However, if the sudoers rule allows user to execute commands without password input (NOPASSWD:), then an attempt will be successful.

6. Application of a combination su + sudo gives one fine-grained control over administrative access. For example, if user2 is allowed to execute sudo with his/her own password (or without it), then he/she will have to enter only one password in case of remote logon. Therefore, it is recommended not to allow such users to log in remotely (i.e. these users should not be mentioned in the option AllowUsers of the file /etc/ssh/sshd_config). If su+sudo are used, then user1 will be able to log in remotely, switch to user2 (su – user2), and execute commands via sudo with the privileges of user2; in this case, he/she will have to enter two passwords to execute sudo commands.

VI. It is also necessary to verify UID uniqueness and non-empty passwords.

A script for the first task is rather simple:
awk -F: {print $1, $3} /etc/passwd | sort -k2 -n | uniq -d -f1
The script returns either empty result (which means that the requirement of UID uniqueness is fulfilled), or a list of “user UID” entries for all users who have not unique identifiers.
For the second task, the following script is used:
awk -F: ($2 == "") {print $1;} /etc/shadow
The script returns either empty result (which means that there is no empty-passwords), or a list of users who have empty passwords. Furthermore, it is recommended to remove the argument “nullok” of the module pam_unix.so from PAM configuration files in /etc/pam.d.

VII. It is often necessary to control membership of users in groups.

For example, members of oracle and oinstall system groups in Oracle have more privileges than ordinary users do. Not only /etc/group contents, but also primary user groups should be controlled (using id command or the forth field of /etc/passwd).
Note. One should verify not only primary and secondary groups in /etc/passwd and /etc/group, but also the file /etc/security/group.conf and PAM settings in /etc/pam.d/. When a user logs in, the module pam_group.so temporarily grants him/her membership in the mentioned groups and doesn’t deprive him/her of this membership when the time comes. This problem is similar to that described in the requirement 8.5.6, but it can’t be rectified using a script.

VIII. Starting from the kernel 2.6.24, Linux contains full-fledged support of so-called capabilities – administrative privileges that earlier belonged to root only, and now can be granted to a separate application and/or user.

The mechanism was implemented on the basis of a draft of POSIX1.e standard. Currently, there are 35 administrative privileges (in the man capabilities description). They define various features, e.g. operating with raw sockets, which is necessary for utilities ping and tcpdump (CAP_NET_RAW) (the SUID flag is set for the ping utility so that it could operate with raw sockets without capabilities), arbitrary modification of owners and file groups (CAP_CHOWN), sending arbitrary signals to the processes (CAP_KILL), etc. This mechanism of access right isolation is implemented by rpm packet libcap.

In practice, it allows one to get rid of SUID privileges at launch of utilities passwd, ping, etc. [8, 9, and 10], as well as partly avoid application of sudo. At that, in contrast to traditional SUID/SGID/sudo mechanisms, the process obtains not all administrative privileges, but only those that are necessary for certain actions. For example, let us suppose that user needs to run tcpdump sniffer, which requires CAP_NET_RAW privilege. To implement this feature without setting SUID bit for the application, it is necessary to perform the following actions (the example is given for FC12 as for a distribution kit with kernel version >= 2.6.24).

Note. RHEL5 doesn’t allow one to define privileges for an executable file. Available wrappers (sucap and execcap utilities) don’t solve the main problem: they do not allow a user to execute certain commands with a specified set of privileges. Furthermore, setpcaps doesn’t implement declared functionality and doesn’t allow one to change privileges for an already running process.

1. For the file /usr/sbin/tcpdump, effective and inheritable privileges are set (for more details, see man):
setcap cap_net_raw=ei /usr/sbin/tcpdump
2. The system is configured to grant privileges to users at their login. The file /etc/pam.d/system-auth must contain the following string (set off in bold):

auth required pam_env.so
auth required pam_cap.so

Further, the same actions should be performed for the file /etc/pam.d/sshd if necessary (if “auth include system-auth” is not specified for this file, including the case of FC12); the given string should be included into the same block as other “auth required” (usually, it is not below the third line).
3. After user logged in, he/she obtains privilege CAP_NET_RAW; for this purpose, the file /etc/security/capabilities.conf is necessary:

cap_net_raw user
none *

Here, the first line grants the privilege to user and the second line denies obtaining of this privilege by all other users.
4. After login, user can run sniffer, because he/she has all necessary privileges:

[user@rf12 ~]$ getpcaps $$
Capabilities for `24591: = cap_net_raw+i
[user@rf12 ~]$ getcap `which tcpdump`
/usr/sbin/tcpdump = cap_net_raw+ei
[user@rf12 ~]$ tcpdump -vnni lo
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes

5. All other (non-privileged) users will fail to run sniffer:

[superadmin@rf12 ~]$ tcpdump -vnni lo
tcpdump: lo: You dont have permission to capture on that device
(socket: Operation not permitted)

There are two disadvantages, which are common for this mechanism and ACLs. Standard file utilities need additional keys to save privileges [10]:

cp --preserve=all acl_cap/tcpdump ./
rsync –auX acl_cap/tcpdump ./

The utility tar (at least, versions 1.22-8 in FC12) doesn’t allow one to store POSIX capabilities in archives.
Moreover, applications lose file privileges after software update:

[root@rf12 security]# setcap cap_net_raw=eip /sbin/rdisc
[root@rf12 security]# getcap /sbin/rdisc
/sbin/rdisc = cap_net_raw+eip
[root@rf12 security]# rpm --quiet -U --force /mnt/cdrom/Packages/iputils-20071127-9.fc12.i686.rpm
[root@rf12 security]# getcap /sbin/rdisc
[root@rf12 security]#

Thus, the privilege mechanism has the following drawbacks:
1. It is necessary to specify additional keys for commands or include aliases into /etc/bashrc.
2. File permissions are removed when software is updated.
3. Though the described mechanism is very important, it isn’t sufficiently documented (there are no man pages for command getpcaps and configuration file capability.conf) and is not familiar to all IT specialists. The mechanism settings are rather complex and have many pitfalls [10 ? 11]; thus, application of this mechanism is useful rather for attackers (e.g. for backdoor creation) than for administrators.
4. Incorrect setting of program privileges constitutes a great security threat for the whole system, which is comparable to that for SUID application [11]. At the same time, the SUID is better debugged and documented.
5. It is impossible to set capabilities for a shell script, in contrast to SUID/SGID (however, certain operating systems, e.g. AIX, don’t allow scripts to have SUID/SGID privileges, too).

IX. Method to login presents another mechanism of access control.

The module pam_access.so (configuration file /etc/security/access.conf) allows one to specify what users and groups can access system depending on the origin (terminal name, host address, domain name or network with mask).
For example, if it is necessary that only user was allowed to access the system via ssh (let us temporary forget that we can use the directive AllowUsers from /etc/ssh/sshd_config for the same purpose), and he/she should be able to login only from a certain host, then it is necessary to add the following string to /etc/security/access.conf:

+ : user : 192.168.6.50
# Absolute prohibition by default MUST be in the last string!
- : ALL : ALL

X. Furthermore, it is possible to control the time of login.

For this purpose, there is a PAM module pam_time.so with configuration file /etc/security/time.conf. If you add the following string to this file
sshd;*;user;!Al2000-0830
it will mean that access to the service sshd (the first filed) is denied (the symbol “!”) to user (the third field) from all consoles (the second field) at all days (“Al”) from 20:00 till 08:30. The configuration file contains rather detailed comments.

If you want some service to apply this mechanism, it is necessary to attach pam_time.so to this service in the corresponding configuration file from directory /etc/pam.d. For SSHD, it is the file /etc/pam.d/sshd:

…
account required pam_nologin.so
account required pam_time.so
…

If it is necessary to configure universal access to the whole system, then you should set the service field value to “*” in the file time.conf; if settings are common for all users, then the third field value also should be “*”; after that, add the following string to the file /etc/security/system-auth:

…
account required pam_unix.so
account required pam_time.so
…

ATTENTION! File headers from /etc/pam.d/ give fair warning that automated instruments for PAM configuration can zap modifications made by an administrator.

IT IS IMPORTANT. The forementioned PAM module doesnt support forced session interruption, so if one could login only from 08:30 till 20:00 and he(she) was able to connect at 19:59, the user wouldnt be logoff-ed by pam_time at 20:00 and the session would be active anyway. To eliminate this disadvantage of pam_time, use timeoutd daemon (that will be described in further publications).

References:
1. https://bugzilla.redhat.com/show_bug.cgi?id=521173
2. http://phaq.phunsites.net/2008/02/04/enabling-reiserfs-xfs-jfs-on-redhat-enterprise-linux/
3. http://www.john-isaac.com/2009/01/xfs-support-for-rhel5/
4. http://press.redhat.com/2010/04/21/red-hat-enterprise-linux-6-beta-available-today-for-public-download/
5. http://www.redhat.com/docs/manuals/enterprise
6. http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/
Available link for download

Posted by Unknown at 4:53 AM

Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest

Labels: 6, and, dss, enterprise, hat, linux, part, pci, red