2.11. Security and Access Control

Read this section for a summary of changes to security, access control, and relevant configuration tools between Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7.

2.11.1. New firewall (firewalld)

In Red Hat Enterprise Linux 6, firewall capabilities were provided by the iptables utility, and configured either at the command line or through the graphical configuration tool, system-config-firewall. In Red Hat Enterprise Linux 7, firewall capabilities are still provided by iptables. However, administrators now interact with iptables through the dynamic firewall daemon, firewalld, and its configuration tools: firewall-config, firewall-cmd, and firewall-applet, which is not included in the default installation of Red Hat Enterprise Linux 7.
Because firewalld is dynamic, changes to its configuration can be made at any time, and are implemented immediately. No part of the firewall needs to be reloaded, so there is no unintentional disruption of existing network connections.
The primary differences between the firewall in Red Hat Enterprise Linux 6 and 7 are:
  • Firewalld configuration details are not stored in /etc/sysconfig/iptables. Instead, configuration details are stored in various files in the /usr/lib/firewalld and /etc/firewalld directories.
  • Where the firewall system in Red Hat Enterprise Linux 6 removed and re-applied all rules every time a configuration change was made, firewalld only applies the configuration differences. As a result, firewalld can change settings during runtime without losing existing connections.
For additional information and assistance configuring the firewall in Red Hat Enterprise Linux 7, see the Red Hat Enterprise Linux 7 Security Guide, available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.

2.11.1.1. Migrating rules to firewalld

Important

If you are using Red Hat Enterprise Linux 7 with another Red Hat product, such as Red Hat Enterprise Linux OpenStack Platform, it may be more appropriate to keep using iptables or ip6tables instead of moving to firewalld.
If you are uncertain which firewall utility to use, check your product documentation or contact Red Hat Support.
Instructions on how to disable firewalld and continue using iptables or ip6tables are available here: https://access.redhat.com/articles/1229233.
Red Hat Enterprise Linux 6 provided two methods of firewall configuration:
  • Use the graphical system-config-firewall tool to configure rules. This tool stored its configuration details in the /etc/sysconfig/system-config-firewall file, and created configuration for the iptables and ip6tables services in the /etc/sysconfig/iptables and /etc/sysconfig/ip6tables files.
  • Manually edit the /etc/sysconfig/iptables and /etc/sysconfig/ip6tables files (either from scratch, or editing an initial configuration created by system-config-firewall).
If you configured your Red Hat Enterprise Linux 6 firewall with system-config-firewall, after you upgrade your system and install firewalld, you can use the firewall-offline-cmd tool to migrate the configuration in /etc/sysconfig/system-config-firewall into the default zone of firewalld. 
$ firewall-offline-cmd
However, if you manually created or edited /etc/sysconfig/iptables or /etc/sysconfig/ip6tables, after you install firewalld, you must either create a new configuration with firewall-cmd or firewall-config, or disable firewalld and continue to use the old iptables and ip6tables services. For details about creating new configurations or disabling firewalld, see the Red Hat Enterprise Linux 7 Security Guide, available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.

2.11.2. Changes to PolicyKit

Previously, PolicyKit used key value pairs in .pkla files to define additional local authorizations. Red Hat Enterprise Linux 7 introduces the ability to define local authorizations with JavaScript, allowing you to script authorizations if necessary.
polkitd reads .rules files in lexicographic order from the /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d directories. If two files share the same name, files in /etc are processed before files in /usr. When the old .pkla files were processed, the last rule processed took precedence. With the new .rules files, the first matching rule takes precedence.
After migration, your existing rules are applied by the /etc/polkit-1/rules.d/49-polkit-pkla-compat.rules file. They can therefore be overridden by .rules files in either /usr or /etc with a name that comes before 49-polkit-pkla-compat in lexicographic order. The simplest way to ensure that your old rules are not overridden is to begin the name of all other .rules files with a number greater than 49.
For further information about this, see the Red Hat Enterprise Linux 7 Desktop Migration and Administration Guide, available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.

2.11.3. Changes to user identifiers

In Red Hat Enterprise Linux 6, the base user identifier was 500. In Red Hat Enterprise Linux 7, the base user identifier is now 1000. This change involves replacing the /etc/login.defs file during the upgrade process.
If you have not modified the default /etc/login.defs file, the file is replaced during upgrade. The base user identifier number is changed to 1000, and new users will be allocated user identifiers at and above 1000. User accounts created before this change retain their current user identifiers and continue to work as expected.
If you have modified the default /etc/login.defs file, the file is not replaced during upgrade, and the base user identifier number remains at 500.

2.11.4. Changes to libuser

As of Red Hat Enterprise Linux 7, the libuser library no longer supports configurations that contain both the ldap and files modules, or both the ldap and shadow modules. Combining these modules results in ambiguity in password handling, and such configurations are now rejected during the initialization process.
If you use libuser to manage users or groups in LDAP, you must remove the files and shadow modules from the modules and create_modules directives in your configuration file (/etc/libuser.conf by default).

2.11.5. Changes to opencryptoki key store

Previous versions of Red Hat Enterprise Linux used the opencryptoki key store version 2, which encrypted private token objects with a secure key in hardware. Red Hat Enterprise Linux 7 uses version 3, which encrypts private token objects with a clear key in software. This means that private token objects created by version 2 must be migrated before they can be used with version 3.
To migrate private token objects, perform the following procedure:

  1. Update software

    Ensure your version of opencryptoki is up to date. 
    # yum update -y opencryptoki

  2. Verify the slot number of your token

    Use pkcsconf to determine the slot number of the token. Run the following commands as root: 
    # pkcsconf -s
# pkcsconf -t
    Note the slot number of your token. The slot description will end with (CCA). The information field will identify the token as the IBM CCA Token.

  3. Stop interface access

    Stop the pkcsslotd service and any opencryptoki processes. 
    # systemctl stop pkcsslotd.service
    Use the following command to identify processes to stop with the kill utility, and then terminate the appropriate processes. 
    # ps ax | grep pkcsslotd

  4. Back up the data store

    Before you migrate, back up the CCA data store (the directory in which your tokens are stored, normally /var/lib/opencryptoki/ccatok). For example, make a copy of the directory. 
    # cp -r /var/lib/opencryptoki/ccatok /var/lib/opencryptoki/ccatok.backup

  5. Run the migration utility

    Change to the /var/lib/opencryptoki/ccatok directory and run the migration utility. 
    # cd /var/lib/opencryptoki/ccatok
# pkcscca -m v2objectsv3 -v
    When prompted, provide your Security Officer (SO) PIN and User PIN.

  6. Remove outdated shared memory file

    Remove the /dev/shm/var.lib.opencryptoki.ccatok file manually, or reboot the system. 
    # rm /dev/shm/var.lib.opencryptoki.ccatok

  7. Go back to an operational interface access

    Start the pkcsslotd service again. 
    # systemctl start pkcsslotd.service
If you encounter problems with the migration, check the following:
  • Ensure you are running the commands as root, and that root is a member of the pkcs11 group.
  • Ensure that the pkcsconf utility is in either the /usr/lib/pkcs11/methods/ directory or the /usr/sbin/ directory.
  • Ensure that the token data store is in the /var/lib/opencryptoki/ccatok/ directory.
  • Ensure that you have supplied a slot number and that the slot number is correct.
  • Ensure that your Security Officer (SO) PIN and User PIN are correct.
  • Ensure that you have write access to the current directory.