pam_apparmor
Introduces basic concepts of system security, covering both local and network security aspects. Shows how to use the product inherent security software like AppArmor or the auditing system that reliably collects information about any security-relevant events.
pam_apparmor
auditctl
ausearch
autrace
aa-notify Message in GNOME
/etc/pam.d/sshd
)auth
Section (common-auth
)account
Section (common-account
)password
Section (common-password
)session
Section (common-session
)nfs
Kernel Module in /etc/modprobe.d/60-nfs.conf
firewalld
RPC Service for NFSaa-unconfined
ls -Z
ps Zaux
/etc/audit/audit.log
auditctl
-s
auditctl
-l
Copyright © 2006– 2018 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see http://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof.
This manual introduces the basic concepts of system security on openSUSE Leap. It covers extensive documentation about the authentication mechanisms available on Linux, such as NIS or LDAP. It deals with aspects of local security like access control lists, encryption and intrusion detection. In the network security part you learn how to secure computers with firewalls and masquerading, and how to set up virtual private networks (VPN). This manual shows how to use security software like AppArmor (which lets you specify per program which files the program may read, write, and execute) or the auditing system that collects information about security-relevant events.
Documentation for our products is available at http://doc.opensuse.org/, where you can also find the latest updates, and browse or download the documentation in various formats.
In addition, the product documentation
is usually available in your installed system under
/usr/share/doc/manual
.
The following documentation is available for this product:
This manual will see you through your initial contact with openSUSE® Leap. Check out the various parts of this manual to learn how to install, use and enjoy your system.
Covers system administration tasks like maintaining, monitoring and customizing an initially installed system.
Describes virtualization technology in general, and introduces libvirt—the unified interface to virtualization—and detailed information on specific hypervisors.
AutoYaST is a system for unattended mass deployment of openSUSE Leap systems using an AutoYaST profile containing installation and configuration data. The manual guides you through the basic steps of auto-installation: preparation, installation, and configuration.
Introduces basic concepts of system security, covering both local and network security aspects. Shows how to use the product inherent security software like AppArmor or the auditing system that reliably collects information about any security-relevant events.
An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to efficiently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources.
Introduces the GNOME desktop of openSUSE Leap. It guides you through using and configuring the desktop and helps you perform key tasks. It is intended mainly for end users who want to make efficient use of GNOME as their default desktop.
Several feedback channels are available:
To report bugs for openSUSE Leap, go to https://bugzilla.opensuse.org/, log in, and click .
For feedback on the documentation of this product, you can also send a
mail to doc-team@suse.com
. Make sure to include the
document title, the product version and the publication date of the
documentation. To report errors or suggest enhancements, provide a concise
description of the problem and refer to the respective section number and
page (or URL).
The following notices and typographical conventions are used in this documentation:
/etc/passwd
: directory names and file names
PLACEHOLDER: replace PLACEHOLDER with the actual value
PATH
: the environment variable PATH
ls
, --help
: commands, options, and
parameters
user
: users or groups
package name : name of a package
Alt, Alt–F1: a key to press or a key combination; keys are shown in uppercase as on a keyboard
, › : menu items, buttons
Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.
Commands that must be run with root
privileges. Often you can also
prefix these commands with the sudo
command to run them
as non-privileged user.
root #
command
tux >
sudo
command
Commands that can be run by non-privileged users.
tux >
command
Notices
Vital information you must be aware of before proceeding. Warns you about security issues, potential loss of data, damage to hardware, or physical hazards.
Important information you should be aware of before proceeding.
Additional information, for example about differences in software versions.
Helpful information, like a guideline or a piece of practical advice.
One main characteristic of Linux is its ability to handle multiple users at the same time (multiuser) and to allow these users to simultaneously perform tasks (multitasking) on the same computer. To users, there is no difference between working with data stored locally and data stored in the network.
Due to the multiuser capability, data from different users has to be stored separately to guarantee security and privacy. Also important is the ability to keep data available in spite of a lost or damaged data medium, for example a hard disk.
This chapter is primarily focused on confidentiality and privacy. But a comprehensive security concept includes a regularly updated, workable, and tested backup. Without a backup, restoring data after it has been tampered with or after a hardware failure is very hard.
Use a defense-in-depth approach to security: Assume that no single threat mitigation can fully protect your systems and data, but multiple layers of defense will make an attack much harder. Components of a defense-in-depth strategy can be the following:
Hashing passwords (for example with PBKDF2, bcrypt, or scrypt) and salting them
Encrypting data (for example with AES)
Logging, monitoring, and intrusion detection
Firewall
Antivirus scanner
Defined and documented emergency procedures
Backups
Physical security
Audits, security scans, and intrusion tests
openSUSE Leap includes software that addresses the requirements of the list above. The following sections provide starting points for securing your system.
On a Linux system, only hashes of passwords are stored. Hashes are one-way algorithms that make it easy to encrypt data. At the same time, hash algorithms make it very hard to compute the original secret from the hash.
The hashes are stored in the file /etc/shadow
,
which cannot be read by normal users. Because restoring passwords is
possible with powerful computers, hashed passwords should not be
visible to regular users.
The National Institute of Standards and Technology (NIST) publishes a guideline for passwords, which is available at https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
For details about how to set a password policy, see Section 8.3, “. For general information about authentication on Linux, see ”Part I, “Authentication”.
If it is possible to physically access a computer, the firmware and boot process can be manipulated to gain access as soon as an authorized person boots the machine. While not all computers can be locked into inaccessible rooms, your first step should be physically locking the server room.
Consider taking the following additional measures:
Configure your system so it cannot be booted from a removable device, either by removing the drives entirely or by setting a UEFI password and configuring the UEFI to allow booting from a hard disk only.
To make the boot procedure more tamper-resistant, enable the UEFI secure boot feature. For more information about Secure Boot, see Book “Reference”, Chapter 14 “UEFI (Unified Extensible Firmware Interface)”.
Linux systems are started by a boot loader that usually allows
passing additional options to the booted kernel. You can prevent others
from using such parameters during boot by setting an additional
password for the boot loader. This is crucial to system
security. Not only does the kernel itself run with root
permissions, but it is also the first authority to grant
root
permissions at system start-up.
For more information about setting a password in the boot loader, see Book “Reference”, Chapter 12 “The Boot Loader GRUB 2”, Section 12.2.6 “Setting a Boot Password”.
Enable hard disk encryption. For more information, see Chapter 11, Encrypting Partitions and Files.
Use AIDE to detect any changes in your system configuration. For more information, see Chapter 13, Intrusion Detection with AIDE.
Because of the everything is a file approach in
Linux, file permissions are important for controlling access to most
resources. This means that by using file permissions, you can define
access to regular files and directories as well as hardware devices.
By default, most hardware devices are only accessible for
root
. However, some devices, for example serial ports, can be
accessible for normal users.
As a general rule, always work with the most restrictive privileges
possible for a given task. For example, it is definitely not
necessary to be root
to read or write e-mail. If the mail
program has a bug, this bug could be exploited for an attack that
acts with exactly the permissions of the program at the time of the
attack. By following the above rule, minimize the possible damage.
For details, see Section 10.1, “Traditional File Permissions” and Section 10.2, “Advantages of ACLs”.
AppArmor and SELinux allow you to set constraints for applications and users. For details, see Part IV, “Confining Privileges with AppArmor” and Part V, “SELinux”.
If there is a chance that hard disks could be accessed outside of the installed operating system, for example by booting a live system or removing the hardware, encrypt the data. openSUSE Leap allows you to encrypt partitions containing data and the operating system. For details, see Chapter 11, Encrypting Partitions and Files.
Securing network services is a crucial task. Aim to secure as many layers of the OSI model as possible.
All communication should be authenticated and encrypted with up-to-date cryptographic algorithms on the transport or application layer. Use a Virtual Private Network (VPN) as an additional secure layer on physical networks.
openSUSE Leap provides many options for securing your network:
Use openssl
to create X509 certificates. These certificates can be
used for encryption and authentication of many services.
You can set up your own certificate authority
(CA) and use it as a source of trust in your
network. For details, see man openssl
.
Usually, at least parts of networks are exposed to the public Internet. Reduce attack surfaces by closing ports with firewall rules and by uninstalling or at least disabling unrequired services. For details, see Chapter 16, Masquerading and Firewalls.
Use OpenVPN to secure communication channels over insecure physical networks. For details, see Chapter 17, Configuring a VPN Server.
Use strong authentication for network services. For details, see Part I, “Authentication”.
Software vulnerabilities are issues in software that can be exploited to obtain unauthorized access or misuse systems. Vulnerabilities are especially critical if they affect remote services, such as HTTP servers. Computer systems are very complex, therefore they always include certain vulnerabilities.
When such issues become known, they must usually be fixed in the software by software developers. The resulting update must then be installed by system administrators in a timely and safe manner on affected systems.
Vulnerabilities are usually announced on centralized databases, for example the National Vulnerability Database, which is maintained by the US government. You can subscribe to feeds to stay informed about newly discovered vulnerabilities. In some cases the problems induced by the bugs can be mitigated until a software update is provided. Vulnerabilities are assigned a Common Vulnerabilities and Exposures (CVE) number and a Common Vulnerability Scoring System (CVSS) score. The score helps identify the severity of vulnerabilities.
SUSE provides a feed of security advisories. It is available at https://www.suse.com/en-us/support/update/. There is also a list of security updates by CVE number available at https://www.suse.com/en-us/security/cve/.
In general, administrators should be prepared for severe vulnerabilities in their systems. This includes hardening all computers as far as possible. Also, we recommend to have predefined procedures in place for quickly installing updates for severe vulnerabilities.
To reduce the damage of possible attacks, use restrictive file permissions. See Section 10.1, “Traditional File Permissions”. SUSE provides a guide to hardening openSUSE Leap.
Other useful links:
http://lists.opensuse.org/opensuse-security-announce/, mailing list with openSUSE security announcements
https://nvd.nist.gov/home, the National Vulnerability Database
https://cve.mitre.org/, MITRE's CVE database
https://www.bsi.bund.de/DE/Service/Aktuell/Cert_Bund_Meldungen/cert_bund_meldungen_node.html, German Federal Office for Information Security vulnerability feed
https://www.first.org/cvss/, information about the Common Vulnerability Scoring System
Malware is software that is intended to interrupt the normal functioning of a computer or steal data. This includes viruses, worms, ransomware, or rootkits. Sometimes malware uses software vulnerabilities to attack a computer. However, in many cases it is accidentally executed by a user, especially when installing third-party software from unknown sources. openSUSE Leap provides an extensive list of programs (packages) in its download repositories. This reduces the need to download third-party software. All packages provided by SUSE are signed. The package manager of openSUSE Leap checks the signatures of packages after the download to verify their integrity.
The command rpm
--checksig
RPM_FILE
shows whether the
checksum and the signature of a package are correct.
You can find the signing key on the first DVD of openSUSE Leap and
on most key servers worldwide.
You can use the ClamAV antivirus software to detect malware on your system. ClamAV can be integrated into several services, for example mail servers and HTTP proxies. This can be used to filter malware before it reaches the user.
Restrictive user privileges can reduce the risk of accidental code execution.
The following tips are a quick summary of the sections above:
Stay informed about the latest security issues. Get and install the updated packages recommended by security announcements as quickly as possible.
Avoid using root
privileges whenever possible. Set
restrictive file permissions.
Only use encrypted protocols for network communication.
Disable any network services you do not absolutely require.
Conduct regular security audits. For example, scan your network for open ports.
Monitor the integrity of files on your systems with
AIDE
(Advanced Intrusion Detection
Environment).
Take proper care when installing any third-party software.
Check all your backups regularly.
Check your log files, for example with logwatch.
Configure the firewall to block all ports that are not explicitly whitelisted.
Design your security measures to be redundant.
Use encryption where possible, for example for hard disks of mobile computers.
If you discover a security-related problem, first check the available update packages. If no update is available, write an e-mail to <security@suse.de>. Include a detailed description of the problem and the version number of the package concerned. We encourage you to encrypt e-mails with GPG.
You can find a current version of the SUSE GPG key at https://www.suse.com/support/security/contact/.
Linux uses PAM (pluggable authentication modules) in the authentication process as a layer that mediates between user and application. PAM modules are available on a system wide basis, so they can be requested by any application. This chapter describes how the modular authentication mechanism works and how it is configured.
When multiple Unix systems in a network access common resources, it becomes imperative that all user and group identities are the same for all machines in that network. The network should be transparent to users: their environments should not vary, regardless of which machine they are actually using. This can be done by means of NIS and NFS services. NFS distributes file systems over a network and is discussed in Book “Reference”, Chapter 22 “Sharing File Systems with NFS”.
NIS (Network Information Service) can be described as a database-like
service that provides access to the contents of
/etc/passwd
, /etc/shadow
, and
/etc/group
across networks. NIS can also be used
for other purposes (making the contents of files like
/etc/hosts
or /etc/services
available, for example), but this is beyond the scope of this
introduction. People often refer to NIS as YP,
because it works like the network's “yellow pages.”
The Authentication Server is based on LDAP and optionally Kerberos. On openSUSE Leap you can configure it with a YaST wizard.
For more information about LDAP, see Chapter 5, LDAP—A Directory Service, and about Kerberos, see Chapter 6, Network Authentication with Kerberos.
The Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to access and maintain information directories. LDAP can be used for user and group management, system configuration management, address management, and more. This chapter provides a basic understanding of how OpenLDAP works.
Kerberos is a network authentication protocol which also provides encryption. This chapter describes how to set up Kerberos and integrate services like LDAP and NFS.
Active Directory* (AD) is a directory-service based on LDAP, Kerberos, and other services. It is used by Microsoft* Windows* to manage resources, services, and people. In a Microsoft Windows network, Active Directory provides information about these objects, restricts access to them, and enforces po…
Linux uses PAM (pluggable authentication modules) in the authentication process as a layer that mediates between user and application. PAM modules are available on a system wide basis, so they can be requested by any application. This chapter describes how the modular authentication mechanism works and how it is configured.
System administrators and programmers often want to restrict access to certain parts of the system or to limit the use of certain functions of an application. Without PAM, applications must be adapted every time a new authentication mechanism, such as LDAP, Samba, or Kerberos, is introduced. However, this process is time-consuming and error-prone. One way to avoid these drawbacks is to separate applications from the authentication mechanism and delegate authentication to centrally managed modules. Whenever a newly required authentication scheme is needed, it is sufficient to adapt or write a suitable PAM module for use by the program in question.
The PAM concept consists of:
PAM modules, which are a set of shared libraries for a specific authentication mechanism.
A module stack with of one or more PAM modules.
A PAM-aware service which needs authentication by
using a module stack or PAM modules. Usually a service is a familiar
name of the corresponding application, like login
or
su
. The service name other
is a
reserved word for default rules.
Module arguments, with which the execution of a single PAM module can be influenced.
A mechanism evaluating each result of a single PAM module execution. A positive value executes the next PAM module. The way a negative value is dealt with depends on the configuration: “no influence, proceed” up to “terminate immediately” and anything in between are valid options.
PAM can be configured in two ways:
/etc/pam.conf
)
The configuration of each service is stored in
/etc/pam.conf
. However, for maintenance and
usability reasons, this configuration scheme is not used in
openSUSE Leap.
/etc/pam.d/
)
Every service (or program) that relies on the PAM mechanism has its
own configuration file in the /etc/pam.d/
directory. For example, the service for
sshd
can be found in the
/etc/pam.d/sshd
file.
The files under /etc/pam.d/
define the PAM modules
used for authentication. Each file consists of lines, which define a
service, and each line consists of a maximum of four components:
TYPE CONTROL MODULE_PATH MODULE_ARGS
The components have the following meaning:
Declares the type of the service. PAM modules are processed as stacks. Different types of modules have different purposes. For example, one module checks the password, another verifies the location from which the system is accessed, and yet another reads user-specific settings. PAM knows about four different types of modules:
auth
Check the user's authenticity, traditionally by querying a password. However, this can also be achieved with a chip card or through biometrics (for example, fingerprints or iris scan).
account
Modules of this type check if the user has general permission to use the requested service. As an example, such a check should be performed to ensure that no one can log in with the user name of an expired account.
password
The purpose of this type of module is to enable the change of an authentication token. Usually this is a password.
session
Modules of this type are responsible for managing and configuring user sessions. They are started before and after authentication to log login attempts and configure the user's specific environment (mail accounts, home directory, system limits, etc.).
Indicates the behavior of a PAM module. Each module can have the following control flags:
required
A module with this flag must be successfully processed before the
authentication may proceed. After the failure of a module with the
required
flag, all other modules with the same
flag are processed before the user receives a message about the
failure of the authentication attempt.
requisite
Modules having this flag must also be processed successfully, in
much the same way as a module with the required
flag. However, in case of failure a module with this flag gives
immediate feedback to the user and no further modules are
processed. In case of success, other modules are subsequently
processed, like any modules with the required
flag. The requisite
flag can be used as a basic
filter checking for the existence of certain conditions that are
essential for a correct authentication.
sufficient
After a module with this flag has been successfully processed, the
requesting application receives an immediate message about the
success and no further modules are processed, provided there was no
preceding failure of a module with the required
flag. The failure of a module with the
sufficient
flag has no direct consequences, in
the sense that any subsequent modules are processed in their
respective order.
optional
The failure or success of a module with this flag does not have any direct consequences. This can be useful for modules that are only intended to display a message (for example, to tell the user that mail has arrived) without taking any further action.
include
If this flag is given, the file specified as argument is inserted at this place.
Contains a full file name of a PAM module. It does not need to be
specified explicitly, as long as the module is located in the default
directory /lib/security
(for all 64-bit platforms
supported by openSUSE® Leap, the directory is
/lib64/security
).
Contains a space-separated list of options to influence the behavior
of a PAM module, such as debug
(enables debugging) or
nullok
(allows the use of empty passwords).
In addition, there are global configuration files for PAM modules under
/etc/security
, which define the exact behavior of
these modules (examples include pam_env.conf
and
time.conf
). Every application that uses a PAM module
actually calls a set of PAM functions, which then process the information
in the various configuration files and return the result to the
requesting application.
To simplify the creation and maintenance of PAM modules, common default
configuration files for the types auth
,
account
, password
, and
session
modules have been introduced. These are
retrieved from every application's PAM configuration. Updates to the
global PAM configuration modules in common-*
are
thus propagated across all PAM configuration files without requiring the
administrator to update every single PAM configuration file.
The global PAM configuration files are maintained using the
pam-config
tool. This tool automatically adds new
modules to the configuration, changes the configuration of existing ones
or deletes modules (or options) from the configurations. Manual
intervention in maintaining PAM configurations is minimized or no longer
required.
When using a 64-bit operating system, it is possible to also include a runtime environment for 32-bit applications. In this case, make sure that you also install the 32-bit version of the PAM modules.
Consider the PAM configuration of sshd as an example:
/etc/pam.d/sshd
) ##%PAM-1.0 1 auth requisite pam_nologin.so 2 auth include common-auth 3 account requisite pam_nologin.so 2 account include common-account 3 password include common-password 3 session required pam_loginuid.so 4 session include common-session 3 session optional pam_lastlog.so silent noupdate showfailed 5
Declares the version of this configuration file for PAM 1.0. This is merely a convention, but could be used in the future to check the version. | |
Checks, if | |
Refers to the configuration files of four module types:
| |
Sets the login UID process attribute for the process that was authenticated. | |
Displays information about the last login of a user. |
By including the configuration files instead of adding each module separately to the respective PAM configuration, you automatically get an updated PAM configuration when an administrator changes the defaults. Formerly, you needed to adjust all configuration files manually for all applications when changes to PAM occurred or a new application was installed. Now the PAM configuration is made with central configuration files and all changes are automatically inherited by the PAM configuration of each service.
The first include file (common-auth
) calls three
modules of the auth
type:
pam_env.so
,
pam_gnome_keyring.so
and
pam_unix.so
. See
Example 2.2, “Default Configuration for the auth
Section (common-auth
)”.
auth
Section (common-auth
) #auth required pam_env.so 1 auth optional pam_gnome_keyring.so 2 auth required pam_unix.so try_first_pass 3
| |
| |
|
The whole stack of auth
modules is processed before
sshd
gets any feedback about
whether the login has succeeded. All modules of the stack having the
required
control flag must be processed successfully
before sshd
receives a message
about the positive result. If one of the modules is not successful, the
entire module stack is still processed and only then is
sshd
notified about the negative
result.
When all modules of the auth
type have been
successfully processed, another include statement is processed, in this
case, that in Example 2.3, “Default Configuration for the account
Section (common-account
)”.
common-account
contains only one module,
pam_unix
. If pam_unix
returns the
result that the user exists, sshd receives a message announcing this
success and the next stack of modules (password
) is
processed, shown in Example 2.4, “Default Configuration for the password
Section (common-password
)”.
account
Section (common-account
) #account required pam_unix.so try_first_pass
password
Section (common-password
) #password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password required pam_unix.so use_authtok nullok shadow try_first_pass
Again, the PAM configuration of
sshd
involves only an include
statement referring to the default configuration for
password
modules located in
common-password
. These modules must successfully be
completed (control flags requisite
and
required
) whenever the application requests the change
of an authentication token.
Changing a password or another authentication token requires a security
check. This is achieved with the pam_cracklib
module. The pam_unix
module used afterward carries
over any old and new passwords from pam_cracklib
, so
the user does not need to authenticate again after changing the password.
This procedure makes it impossible to circumvent the checks carried out
by pam_cracklib
. Whenever the
account
or the auth
type are
configured to complain about expired passwords, the
password
modules should also be used.
session
Section (common-session
) #session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_umask.so session optional pam_systemd.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so
As the final step, the modules of the session
type
(bundled in the common-session
file) are called to
configure the session according to the settings for the user in question.
The pam_limits
module loads the file
/etc/security/limits.conf
, which may define limits
on the use of certain system resources. The pam_unix
module is processed again. The pam_umask
module can
be used to set the file mode creation mask. Since this module carries the
optional
flag, a failure of this module would not
affect the successful completion of the entire session module stack. The
session
modules are called a second time when the user
logs out.
Some PAM modules are configurable. The configuration files are
located in /etc/security
. This section briefly
describes the configuration files relevant to the sshd
example—pam_env.conf
and
limits.conf
.
pam_env.conf
can be used to define a standardized
environment for users that is set whenever the
pam_env
module is called. With it, preset
environment variables using the following syntax:
VARIABLE [DEFAULT=VALUE] [OVERRIDE=VALUE]
Name of the environment variable to set.
[DEFAULT=<value>]
Default VALUE the administrator wants to set.
[OVERRIDE=<value>]
Values that may be queried and set by
pam_env
, overriding the default value.
A typical example of how pam_env
can be used is
the adaptation of the DISPLAY
variable, which is changed
whenever a remote login takes place. This is shown in
Example 2.6, “pam_env.conf”.
REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST} DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
The first line sets the value of the REMOTEHOST
variable
to localhost
, which is used whenever
pam_env
cannot determine any other value. The
DISPLAY
variable in turn contains the value of
REMOTEHOST
. Find more information in the comments in
/etc/security/pam_env.conf
.
The purpose of pam_mount
is to mount user home
directories during the login process, and to unmount them during logout
in an environment where a central file server keeps all the home
directories of users. With this method, it is not necessary to mount a
complete /home
directory where all the user home
directories would be accessible. Instead, only the home directory of the
user who is about to log in, is mounted.
After installing pam_mount
, a template for
pam_mount.conf.xml
is available in
/etc/security
. The description of the various
elements can be found in the manual page man 5
pam_mount.conf
.
A basic configuration of this feature can be done with YaST. Select Book “Reference”, Chapter 21 “Samba”, Section 21.5 “Configuring Clients”.
› › to add the file server; see
System limits can be set on a user or group basis in
limits.conf
, which is read by the
pam_limits
module. The file allows you to set
hard limits, which may not be exceeded, and soft limits, which
may be exceeded temporarily. For more information about the syntax and
the options, see the comments in
/etc/security/limits.conf
.
The pam-config
tool helps you configure the global PAM
configuration files (/etc/pam.d/common-*
) and
several selected application configurations. For a list of supported
modules, use the pam-config --list-modules
command.
Use the pam-config
command to maintain your PAM
configuration files. Add new modules to your PAM configurations, delete
other modules or modify options to these modules. When changing global
PAM configuration files, no manual tweaking of the PAM setup for
individual applications is required.
A simple use case for pam-config
involves the
following:
Auto-generate a fresh Unix-style PAM configuration.
Let pam-config create the simplest possible setup which you can extend
later on. The pam-config --create
command creates a
simple Unix authentication configuration. Pre-existing configuration
files not maintained by pam-config are overwritten, but backup copies
are kept as *.pam-config-backup
.
Add a new authentication method.
Adding a new authentication method (for example, LDAP) to your stack
of PAM modules comes down to a simple pam-config --add
--ldap
command. LDAP is added wherever appropriate across
all common-*-pc
PAM configuration files.
Add debugging for test purposes.
To make sure the new authentication procedure works as planned, turn
on debugging for all PAM-related operations. The pam-config
--add --ldap-debug
turns on debugging for LDAP-related PAM
operations. Find the debugging output in the systemd
journal (see
Book “Reference”, Chapter 11 “journalctl
: Query the systemd
Journal”).
Query your setup.
Before you finally apply your new PAM setup, check if it contains all
the options you wanted to add. The pam-config --query
--
MODULE lists both the type and
the options for the queried PAM module.
Remove the debug options.
Finally, remove the debug option from your setup when you are entirely
satisfied with the performance of it. The pam-config --delete
--ldap-debug
command turns off debugging for LDAP
authentication. In case you had debugging options added for other
modules, use similar commands to turn these off.
For more information on the pam-config
command and the
options available, refer to the manual page of
pam-config(8)
.
If you prefer to manually create or maintain your PAM configuration
files, make sure to disable pam-config
for these
files.
When you create your PAM configuration files from scratch using the
pam-config --create
command, it creates symbolic links
from the common-*
to the
common-*-pc
files.
pam-config
only modifies the
common-*-pc
configuration
files. Removing these symbolic links effectively disables pam-config,
because pam-config only operates on the
common-*-pc
files and
these files are not put into effect without the symbolic links.
pam_systemd.so
into Configuration
If you are creating your own PAM configuration, make sure to include
pam_systemd.so
configured as session
optional
. Not including the pam_systemd.so
can
cause problems with systemd
task limits. For details, refer to the man
page of pam_systemd.so
.
In the /usr/share/doc/packages/pam
directory after
installing the pam-doc
package, find the
following additional documentation:
In the top level of this directory, there is the
modules
subdirectory holding README files about
the available PAM modules.
This document comprises everything that the system administrator should know about PAM. It discusses a range of topics, from the syntax of configuration files to the security aspects of PAM.
This document summarizes the topic from the developer's point of view, with information about how to write standard-compliant PAM modules.
This document comprises everything needed by an application developer who wants to use the PAM libraries.
PAM in general and the individual modules come with manual pages that provide a good overview of the functionality of all the components.
When multiple Unix systems in a network access common resources, it becomes imperative that all user and group identities are the same for all machines in that network. The network should be transparent to users: their environments should not vary, regardless of which machine they are actually using. This can be done by means of NIS and NFS services. NFS distributes file systems over a network and is discussed in Book “Reference”, Chapter 22 “Sharing File Systems with NFS”.
NIS (Network Information Service) can be described as a database-like
service that provides access to the contents of
/etc/passwd
, /etc/shadow
, and
/etc/group
across networks. NIS can also be used
for other purposes (making the contents of files like
/etc/hosts
or /etc/services
available, for example), but this is beyond the scope of this
introduction. People often refer to NIS as YP,
because it works like the network's “yellow pages.”
To distribute NIS information across networks, either install one single server (a master) that serves all clients, or NIS slave servers requesting this information from the master and relaying it to their respective clients.
To configure just one NIS server for your network, proceed with Section 3.1.1, “Configuring a NIS Master Server”.
If your NIS master server needs to export its data to slave servers, set up the master server as described in Section 3.1.1, “Configuring a NIS Master Server” and set up slave servers in the subnets as described in Section 3.1.2, “Configuring a NIS Slave Server”.
To manage the NIS Server functionality with YaST, install the yast2-nis-server
package by running the zypper in yast2-nis-server
command as root. To configure a NIS master server for your network, proceed as follows:
Start
› › .If you need just one NIS server in your network or if this server is to act as the master for further NIS slave servers, select
. YaST installs the required packages.If NIS server software is already installed on your machine, initiate the creation of a NIS master server by clicking
.Determine basic NIS setup options:
Enter the NIS domain name.
Define whether the host should also be a NIS client (enabling users to log in and access data from the NIS server) by selecting
.If your NIS server needs to act as a master server to NIS slave servers in other subnets, select
.The option
is only useful with . It speeds up the transfer of maps to the slaves.
Select yppasswd
). This makes the options
and available. “GECOS”
means that the users can also change their names and address
settings with the command ypchfn
.
“Shell” allows users to change their default shell with
the command ypchsh
(for example, to switch from
Bash to sh). The new shell must be one of the predefined entries in
/etc/shells
.
Select
to have YaST adapt the firewall settings for the NIS server.Leave this dialog with
or click to make additional settings.
/etc
by default).
In addition, passwords can be merged here. The setting should be
to create the user database from the system
authentication files /etc/passwd
,
/etc/shadow
, and
/etc/group
. Also, determine the smallest user
and group ID that should be offered by NIS. Click
to confirm your settings and return to the
previous screen.
If you previously enabled
, enter the host names used as slaves and click . If no slave servers exist, this configuration step is skipped.Continue to the dialog for the database configuration. Specify the NIS Server Maps, the partial databases to transfer from the NIS server to the client. The default settings are usually adequate. Leave this dialog with .
Check which maps should be available and click
to continue.Determine which hosts are allowed to query the NIS server. You can add, edit, or delete hosts by clicking the appropriate button. Specify from which networks requests can be sent to the NIS server. Normally, this is your internal network. In this case, there should be the following two entries:
255.0.0.0 127.0.0.0 0.0.0.0 0.0.0.0
The first entry enables connections from your own host, which is the NIS server. The second one allows all hosts to send requests to the server.
Click
to save your changes and exit the setup.To configure additional NIS slave servers in your network, proceed as follows:
Start
› › .Select
and click .If NIS server software is already installed on your machine, initiate the creation of a NIS slave server by clicking
.Complete the basic setup of your NIS slave server:
Enter the NIS domain.
Enter host name or IP address of the master server.
Set
if you want to enable user logins on this server.Adapt the firewall settings with
.Click
.Enter the hosts that are allowed to query the NIS server. You can add, edit, or delete hosts by clicking the appropriate button. Specify all networks from which requests can be sent to the NIS server. If it applies to all networks, use the following configuration:
255.0.0.0 127.0.0.0 0.0.0.0 0.0.0.0
The first entry enables connections from your own host, which is the NIS server. The second one allows all hosts with access to the same network to send requests to the server.
Click
to save changes and exit the setup.To use NIS on a workstation, do the following:
Start
› › .Activate the
button.Enter the NIS domain. This is usually a domain name given by your administrator or a static IP address received by DHCP. For information about DHCP, see Book “Reference”, Chapter 20 “DHCP”.
Enter your NIS servers and separate their addresses by spaces. If you do not know your NIS server, click
to let YaST search for any NIS servers in your domain. Depending on the size of your local network, this may be a time-consuming process. asks for a NIS server in the local network after the specified servers fail to respond.Depending on your local installation, you may also want to activate the automounter. This option also installs additional software if required.
If you do not want other hosts to be able to query which server your
client is using, go to the man
ypbind
.
Click
to save them and return to the YaST control center. Your client is now configured with NIS.The Authentication Server is based on LDAP and optionally Kerberos. On openSUSE Leap you can configure it with a YaST wizard.
For more information about LDAP, see Chapter 5, LDAP—A Directory Service, and about Kerberos, see Chapter 6, Network Authentication with Kerberos.
To set up an authentication server for user account data, make sure the
yast2-auth-server
,
openldap2
,
krb5-server
, and
krb5-client
packages are installed; YaST will
remind you and install them if one of these packages is missing. For
Kerberos support, the krb5-plugin-kdb-ldap
package is required.
The first part of the Authentication Server configuration with YaST is setting up an LDAP server, then you can enable Kerberos.
Start YaST as root
and select › to invoke the configuration wizard.
Configure the Figure 4.1, “YaST Authentication Server Configuration”:
of your LDAP server (you can change these settings later)—seeSet LDAP to be started.
If the LDAP server should announce its services via SLP, check
.Configure
.Click
.Select the server type:
, , or .Select security options (
).It is strongly recommended to Procedure 4.2, “Editing Authentication Server Configuration”, Step 4.
. For more information, seeWhen using authentication without enabling transport encryption using TLS, the password will be transmitted in the clear.
Also consider using LDAP over SSL with certificates.
Confirm Figure 4.2, “YaST LDAP Server—New Database”.
with entering an and then clicking —seeIn the Figure 4.3, “YaST Kerberos Authentication”.
dialog, decide whether to enable Kerberos authentication or not (you can change these settings later)—seeChoose whether Kerberos support is needed or not. If you enable it, also specify your
. Then confirm with .The
allows you to specify various aspects such as or ports to use.Finally, check the
and click to exit the configuration wizard.For changes or additional configuration start the Authentication Server module again and in the left pane expand Figure 4.4, “YaST Editing Authentication Server Configuration”:
to make subentries visible—seeWith
, configure the degree of logging activity (verbosity) of the LDAP server. From the predefined list, select or deselect logging options according to your needs. The more options are enabled, the larger your log files grow.Configure which connection types the server should offer under
. Choose from:This option enables connection requests (bind requests) from clients using the previous version of the protocol (LDAPv2).
Normally, the LDAP server denies any authentication attempts with empty credentials, that is, a distinguished name (DN) or a password. However, enabling this option makes it possible to connect with a password and no DN to establish an anonymous connection.
Enabling this option makes it possible to connect without authentication (anonymously) using a distinguished name (DN) but no password.
Enabling this option allows non-authenticated (anonymous) update operations. Access is restricted according to ACLs and other rules.
also lets you configure the server flags. Choose from:
The server will no longer accept anonymous bind requests. Note, that this does not generally prohibit anonymous directory access.
Completely disable Simple Bind authentication.
The server will no longer force an authenticated connection back to the anonymous state when receiving the StartTLS operation.
The server will disallow the StartTLS operation on already authenticated connections.
To configure secure communication between client and server, proceed with
:Activate
to enable TLS and SSL encryption of the client/server communication.Add Schema files to be included in the server's configuration by selecting
in the left part of the dialog. The default selection of schema files applies to the server providing a source of YaST user account data.
YaST allows to add traditional Schema files (usually with a name
ending in .schema
) or LDIF files containing Schema
definitions in OpenLDAP's LDIF Schema format.
To configure the databases managed by your LDAP server, proceed as follows:
Select the
item in the left part of the dialog.Click
to add a new database.Specify the requested data:
Enter the base DN (distinguished name) of your LDAP server.
Enter the DN of the administrator in charge of the server. If you
check cn
of the administrator and the system fills in
the rest automatically.
Enter the password for the database administrator.
For convenience, check this option if wanted.
In the next dialog, configure replication settings.
In the next dialog, enable enforcement of password policies to provide extra security to your LDAP server:
Check
to be able to specify a password policy.Activate
to have clear text passwords be hashed before they are written to the database whenever they are added or modified.provides a relevant error message for bind requests to locked accounts.
Do not use the “Locked Account” error message provides security-sensitive information that can be exploited by a potential attacker.
option if your environment is sensitive to security issues, because theEnter the DN of the default policy object. To use a DN other than the one suggested by YaST, enter your choice. Otherwise, accept the default settings.
Complete the database configuration by clicking
.If you have not opted for password policies, your server is ready to run at this point. If you have chosen to enable password policies, proceed with the configuration of the password policy in detail. If you have chosen a password policy object that does not yet exist, YaST creates one:
Enter the LDAP server password. In the navigation tree below
expand your database object and activate the item.Make sure
is activated. Then click .Configure the password change policies:
Determine the number of passwords stored in the password history. Saved passwords may not be reused by the user.
Determine if users can change their passwords and if they will need to change their passwords after a reset by the administrator. Require the old password for password changes (optional).
Determine whether and to what extent passwords should be subject to quality checking. Set the minimum password length that must be met before a password is valid. If you select
, users are allowed to use encrypted passwords, even though the quality checks cannot be performed. If you opt for only those passwords that pass the quality tests are accepted as valid.Configure the password time-limit policies:
Determine the minimum password time-limit (the time that needs to pass between two valid password changes) and the maximum password time limit.
Determine the time between a password expiration warning and the actual password expiration.
Set the number of postponement uses of an expired password before the password expires permanently.
Configure the lockout policies:
Enable password locking.
Determine the number of bind failures that trigger a password lock.
Determine the duration of the password lock.
Determine the length of time that password failures are kept in the cache before they are purged.
Apply your password policy settings with
.To edit a previously created database, select its base DN in the tree to the left. In the right part of the window, YaST displays a dialog similar to the one used for the creation of a new database (with the main difference that the base DN entry is grayed out and cannot be changed).
After leaving the Authentication Server configuration by selecting
, you are ready to go with a basic working configuration for your Authentication Server. To fine-tune this setup, use OpenLDAP's dynamic configuration back-end.
The OpenLDAP's dynamic configuration back-end stores the configuration
in an LDAP database. That database consists of a set of
.ldif
files in
/etc/openldap/slapd.d
. There is no need to access
these files directly. To access the settings you can either use the
YaST Authentication Server module (the
yast2-auth-server
package) or an LDAP client
such as ldapmodify
or ldapsearch
.
For more information on the dynamic configuration of OpenLDAP, see the
“OpenLDAP Administration Guide”.
For editing LDAP users and groups with YaST, see Section 5.4, “Configuring LDAP Users and Groups in YaST”.
YaST allows setting up authentication to clients using different modules:
Use both an identity service (usually LDAP) and a user authentication service (usually Kerberos). This option is based on SSSD and in the majority of cases is best suited for joining Active Directory domains. .
This module is described in Section 7.3.2, “ Joining Active Directory Using . ”
Join an Active Directory (which entails use of Kerberos and LDAP). This option is
based on . winbind
and is best suited for joining an
Active Directory domain if support for NTLM or cross-forest trusts is necessary.
This module is described in Section 7.3.3, “ Joining Active Directory Using . ”
Allows setting up LDAP identities and Kerberos authentication independently from each other and provides fewer options. While this module also uses SSSD, it is not as well suited for connecting to Active Directory as the previous two options. .
This module is described in:
Two of the YaST modules are based on SSSD:
and .SSSD stands for System Security Services Daemon. SSSD talks to remote directory services that provide user data and provides various authentication methods, such as LDAP, Kerberos, or Active Directory (AD). It also provides an NSS (Name Service Switch) and PAM (Pluggable Authentication Module) interface.
SSSD can locally cache user data and then allow users to use the data, even if the real directory service is (temporarily) unreachable.
After running one of the YaST authentication modules, you can check whether SSSD is running with:
root #
systemctl status sssd
sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Active: active (running) since Thu 2015-10-23 11:03:43 CEST; 5s ago [...]
To allow logging in when the authentication back-end is unavailable, SSSD will use its cache even if it was invalidated. This happens until the back-end is available again.
To invalidate the cache, run sss_cache -E
(the
command sss_cache
is part of the package
sssd-tools).
To completely remove the SSSD cache, run:
tux >
sudo
systemctl stop sssd
tux >
sudo
rm -f /var/lib/sss/db/*
tux >
sudo
systemctl start sssd
For more information, see the SSSD man
pages sssd.conf
(man
sssd.conf
) and sssd
(man
sssd
). There are also man pages for most SSSD modules.
The Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to access and maintain information directories. LDAP can be used for user and group management, system configuration management, address management, and more. This chapter provides a basic understanding of how OpenLDAP works.
In a network environment, it is crucial to keep important information structured and to serve it quickly. A directory service keeps information available in a well-structured and searchable form.
Ideally, a central server stores the data in a directory and distributes it to all clients using a well-defined protocol. The structured data allow a wide range of applications to access them. A central repository reduces the necessary administrative effort. The use of an open and standardized protocol like LDAP ensures that as many client applications as possible can access such information.
A directory in this context is a type of database optimized for quick and effective reading and searching:
To make multiple concurrent reading accesses possible, the number of updates is usually very low. The number of read and write accesses is often limited to a few users with administrative privileges. In contrast, conventional databases are optimized for accepting the largest possible data volume in a short time.
When static data is administered, updates of the existing data sets are very rare. When working with dynamic data, especially when data sets like bank accounts or accounting are concerned, the consistency of the data is of primary importance. If an amount should be subtracted from one place to be added to another, both operations must happen concurrently, within one transaction, to ensure balance over the data stock. Traditional relational databases usually have a very strong focus on data consistency, such as the referential integrity support of transactions. Conversely, short-term inconsistencies are usually acceptable in LDAP directories. LDAP directories often do not have the same strong consistency requirements as relational databases.
The design of a directory service like LDAP is not laid out to support complex update or query mechanisms. All applications are guaranteed to access this service quickly and easily.
Unix system administrators traditionally use NIS (Network Information
Service) for name resolution and data distribution in a network. The
configuration data contained in the files group
,
hosts
, mail
,
netgroup
, networks
,
passwd
, printcap
,
protocols
, rpc
, and
services
in the /etc
directory
is distributed to clients all over the network. These files can be
maintained without major effort because they are simple text files. The
handling of larger amounts of data, however, becomes increasingly
difficult because of nonexistent structuring.
NIS is only designed for Unix platforms, and is not suitable as a
centralized data administration tool in heterogeneous networks.
Unlike NIS, the LDAP service is not restricted to pure Unix networks. Windows™ servers (starting with Windows 2000) support LDAP as a directory service. The application tasks mentioned above are additionally supported in non-Unix systems.
The LDAP principle can be applied to any data structure that needs to be centrally administered. A few application examples are:
Replacement for the NIS service
Mail routing (postfix)
Address books for mail clients, like Mozilla Thunderbird, Evolution, and Outlook
Administration of zone descriptions for a BIND 9 name server
User authentication with Samba in heterogeneous networks
This list can be extended because LDAP is extensible, unlike NIS. The clearly-defined hierarchical structure of the data simplifies the administration of large amounts of data, as it can be searched more easily.
To get background knowledge on how an LDAP server works and how the data is stored, it is vital to understand the way the data is organized on the server and how this structure enables LDAP to provide fast access to the data. To successfully operate an LDAP setup, you also need to be familiar with some basic LDAP terminology. This section introduces the basic layout of an LDAP directory tree and provides the basic terminology used with regard to LDAP. Skip this introductory section if you already have some LDAP background knowledge and only want to learn how to set up an LDAP environment in openSUSE Leap. Read on at Section 5.5, “Manually Configuring an LDAP Server”.
An LDAP directory has a tree structure. All entries (called objects) of the directory have a defined position within this hierarchy. This hierarchy is called the directory information tree (DIT). The complete path to the desired entry, which unambiguously identifies it, is called the distinguished name or DN. A single node along the path to this entry is called relative distinguished name or RDN.
The relations within an LDAP directory tree become more evident in the following example, shown in Figure 5.1, “Structure of an LDAP Directory”.
The complete diagram is a fictional directory information tree. The
entries on three levels are depicted. Each entry corresponds to one box
in the image. The complete, valid distinguished name
for the fictional employee Geeko
Linux
, in this case, is cn=Geeko
Linux,ou=doc,dc=example,dc=com
. It is composed by adding the
RDN cn=Geeko Linux
to the DN of the preceding entry
ou=doc,dc=example,dc=com
.
The types of objects that can be stored in the DIT are globally determined following a Schema. The type of an object is determined by the object class. The object class determines what attributes the relevant object must or can be assigned. The Schema, therefore, must contain definitions of all object classes and attributes used in the desired application scenario. There are a few common Schemas (see RFC 2252 and 2256). The LDAP RFC defines a few commonly used Schemas (see for example, RFC4519). Additionally, Schemas are available for many other use cases (for example, Samba or NIS replacement). It is, however, possible to create custom Schemas or to use multiple Schemas complementing each other (if this is required by the environment in which the LDAP server should operate).
Table 5.1, “Commonly Used Object Classes and Attributes” offers a small overview of the object
classes from core.schema
and
inetorgperson.schema
used in the example, including
required attributes (Req. Attr.) and valid attribute values.
Object Class |
Meaning |
Example Entry |
Req. Attr. |
---|---|---|---|
|
domainComponent (name components of the domain) |
example |
dc |
|
organizationalUnit (organizational unit) |
doc |
ou |
|
inetOrgPerson (person-related data for the intranet or Internet) |
Geeko Linux |
sn and cn |
Example 5.1, “Excerpt from schema.core” shows an excerpt from a Schema directive with explanations.
attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName') 1 DESC 'RFC2256: organizational unit this object belongs to' 2 SUP name ) 3 objectclass ( 2.5.6.5 NAME 'organizationalUnit' 4 DESC 'RFC2256: an organizational unit' 5 SUP top STRUCTURAL 6 MUST ou 7 MAY (userPassword $ searchGuide $ seeAlso $ businessCategory 8 $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description) ) ...
The attribute type organizationalUnitName
and the
corresponding object class organizationalUnit
serve as
an example here.
The name of the attribute, its unique OID (object identifier) (numerical), and the abbreviation of the attribute. | |
A brief description of the attribute with | |
| |
The definition of the object class
| |
A brief description of the object class. | |
The | |
With | |
With |
A very good introduction to the use of Schemas can be found in the
OpenLDAP documentation (openldap2-doc
). When
installed, find it in
/usr/share/doc/packages/openldap2/adminguide/guide.html
.
YaST includes the module
that helps define authentication scenarios involving either LDAP or Kerberos.It can also be used to join Kerberos and LDAP separately. However, in many such cases, using this module may not be the first choice, such as for joining Active Directory (which uses a combination of LDAP and Kerberos). For more information, see Section 4.2, “Configuring an Authentication Client with YaST”.
Start the module by selecting
› .To configure an LDAP client, follow the procedure below:
In the window
, click .Make sure that the tab
is chosen.Specify one or more LDAP server URLs, host names, or IP addresses under
. When specifying multiple addresses, separate them with spaces.
Specify the appropriate LDAP distinguished name (DN) under
dc=example,dc=com
.
If your LDAP server supports TLS encryption, choose the appropriate security option under
.To first ask the server whether it supports TLS encryption and be able to downgrade to an unencrypted connection if it does not, use
.Activate other options as necessary:
You can
and on the local computer for them.Use
to cache LDAP entries locally. However, this bears the danger that entries can be slightly out of date.Specify the types of data that should be used from the LDAP source, such as
and , , and (network-shared drives that can be automatically mounted on request).Specify the distinguished name (DN) and password of the user under whose name you want to bind to the LDAP directory in
and .Otherwise, if the server supports it, you can also leave both text boxes empty to bind anonymously to the server.
When using authentication without enabling transport encryption using TLS or StartTLS, the password will be transmitted in the clear.
Under
, you can additionally configure timeouts for BIND operations.To check whether the LDAP connection works, click
.To leave the dialog, click
. Then wait for the setup to complete.Finally, click
.The actual registration of user and group data differs only slightly from the procedure when not using LDAP. The following instructions relate to the administration of users. The procedure for administering groups is analogous.
Access the YaST user administration with
› .Use
to limit the view of users to the LDAP users and enter the password for Root DN.Click
to enter the user configuration. A dialog with four tabs opens:Specify the user's name, login name, and password in the
tab.Check the
tab for the group membership, login shell, and home directory of the new user. If necessary, change the default to values that better suit your needs.Modify or accept the default
.Enter the
tab, select the LDAP plug-in, and click to configure additional LDAP attributes assigned to the new user.Click
to apply your settings and leave the user configuration.The initial input form of user administration offers
. This allows you to apply LDAP search filters to the set of available users. Alternatively open the module for configuring LDAP users and groups by selecting .
YaST uses OpenLDAP's dynamic configuration database
(back-config
) to store the LDAP server's
configuration. For details about the dynamic configuration back-end, see
the slapd-config(5)
man page or the OpenLDAP
Software 2.4 Administrator's Guide located at
/usr/share/doc/packages/openldap2/guide/admin/guide.html
on your system if the openldap2
package is
installed.
YaST does not use /etc/openldap/slapd.conf
to
store the OpenLDAP configuration anymore. In case of a system upgrade, a
copy of the original /etc/openldap/slapd.conf
file
will get created as
/etc/openldap/slapd.conf.YaSTsave
.
To conveniently access the configuration back-end, you use SASL external
authentication. For example, the following ldapsearch
command executed as root
can show the complete
slapd
configuration:
tux >
ldapsearch -Y external -H ldapi:/// -b cn=config
Basic LDAP Server initialization and configuration can be done within the Authentication Server YaST module. For more information, see Section 4.1, “Configuring an Authentication Server with YaST”.
When the LDAP server is fully configured and all desired entries have
been made according to the pattern described in
Section 5.6, “Manually Administering LDAP Data”, start the LDAP server as
root
by entering sudo systemctl start
slapd
. To stop the server manually, enter the command
sudo systemctl stop slapd
. Query the status of
the running LDAP server with sudo systemctl status
slapd
.
Use the YaST Book “Reference”, Chapter 10 “The systemd
Daemon”, Section 10.4 “Managing Services with YaST”, to have the server started and
stopped automatically on system bootup and shutdown. You can also
create the corresponding links to the start and stop scripts with the
systemctl
commands as described
in Book “Reference”, Chapter 10 “The systemd
Daemon”, Section 10.2.1 “Managing Services in a Running System”.
OpenLDAP offers a series of tools for the administration of data in the LDAP directory. The four most important tools for adding to, deleting from, searching through and modifying the data stock are explained in this section.
Once your LDAP server
is correctly configured (it features appropriate entries for
suffix
, directory
,
rootdn
, rootpw
and
index
), proceed to entering records. OpenLDAP offers
the ldapadd
command for this task. If possible, add
the objects to the database in bundles (for practical reasons). LDAP
can process the LDIF format (LDAP data interchange format) for this.
An LDIF file is a simple text file that can contain an arbitrary number
of attribute and value pairs.
The LDIF file for creating a rough framework for the example in
Figure 5.1, “Structure of an LDAP Directory” would look like the one in
Example 5.2, “An LDIF File”.
LDAP works with UTF-8 (Unicode). Umlauts must be encoded correctly.
Otherwise, avoid umlauts and other special characters or use
iconv
to convert the input to UTF-8.
# The Organization dn: dc=example,dc=com objectClass: dcObject objectClass: organization o: Example dc: example # The organizational unit development (devel) dn: ou=devel,dc=example,dc=com objectClass: organizationalUnit ou: devel # The organizational unit documentation (doc) dn: ou=doc,dc=example,dc=com objectClass: organizationalUnit ou: doc # The organizational unit internal IT (it) dn: ou=it,dc=example,dc=com objectClass: organizationalUnit ou: it
Save the file with the .ldif
suffix then pass it to
the server with the following command:
tux >
ldapadd -x -D DN_OF_THE_ADMINISTRATOR -W -f FILE.ldif
-x
switches off the authentication with SASL in this
case. -D
declares the user that calls the operation.
The valid DN of the administrator is entered here, as it has been
configured in slapd.conf
. In the current example,
this is cn=Administrator,dc=example,dc=com
.
-W
circumvents entering the password on the command
line (in clear text) and activates a separate password prompt.
The -f
option passes the file name. See the details
of running ldapadd
in
Example 5.3, “ldapadd with example.ldif”.
tux >
ldapadd -x -D cn=Administrator,dc=example,dc=com -W -f example.ldif
Enter LDAP password:
adding new entry "dc=example,dc=com"
adding new entry "ou=devel,dc=example,dc=com"
adding new entry "ou=doc,dc=example,dc=com"
adding new entry "ou=it,dc=example,dc=com"
The user data of individuals can be prepared in separate LDIF files.
Example 5.4, “LDIF Data for Tux” adds
Tux
to the new LDAP directory.
# coworker Tux dn: cn=Tux Linux,ou=devel,dc=example,dc=com objectClass: inetOrgPerson cn: Tux Linux givenName: Tux sn: Linux mail: tux@example.com uid: tux telephoneNumber: +49 1234 567-8
An LDIF file can contain an arbitrary number of objects. It is possible to pass directory branches (entirely or in part) to the server in one go, as shown in the example of individual objects. If it is necessary to modify some data relatively often, a fine subdivision of single objects is recommended.
The tool ldapmodify
is provided for modifying the
data stock. The easiest way to do this is to modify the corresponding
LDIF file and pass the modified file to the LDAP server. To change the
telephone number of colleague Tux from +49 1234 567-8
to +49 1234 567-10
, edit the LDIF file like in
Example 5.5, “Modified LDIF File tux.ldif”.
# coworker Tux dn: cn=Tux Linux,ou=devel,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +49 1234 567-10
Import the modified file into the LDAP directory with the following command:
tux >
ldapmodify -x -D cn=Administrator,dc=example,dc=com -W -f tux.ldif
Alternatively, pass the attributes to change directly to
ldapmodify
as follows:
Start ldapmodify
and enter your password:
tux >
ldapmodify -x -D cn=Administrator,dc=example,dc=com -W
Enter LDAP password:
Enter the changes while carefully complying with the syntax in the order presented below:
dn: cn=Tux Linux,ou=devel,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +49 1234 567-10
For more information about ldapmodify
and its syntax,
see the ldapmodify
man page.
OpenLDAP provides, with ldapsearch
, a command line
tool for searching data within an LDAP directory and reading data from
it. This is a simple query:
tux >
ldapsearch -x -b dc=example,dc=com "(objectClass=*)"
The -b
option determines the search base (the section
of the tree within which the search should be performed). In the current
case, this is dc=example,dc=com
. To perform a more
finely-grained search in specific subsections of the LDAP directory (for
example, only within the devel
department), pass this
section to ldapsearch
with -b
.
-x
requests activation of simple authentication.
(objectClass=*)
declares that all objects contained
in the directory should be read. This command option can be used after
the creation of a new directory tree to verify that all entries have
been recorded correctly and the server responds as desired. For more
information about the use of ldapsearch
, see the
ldapsearch(1)
man page.
Delete unwanted entries with ldapdelete
. The syntax
is similar to that of the other commands. To delete, for example, the
complete entry for Tux Linux
, issue the following
command:
tux >
ldapdelete -x -D cn=Administrator,dc=example,dc=com -W cn=Tux \
Linux,ou=devel,dc=example,dc=com
More complex subjects (like SASL configuration or establishment of a replicating LDAP server that distributes the workload among multiple slaves) were omitted from this chapter. Find detailed information about both subjects in the OpenLDAP 2.4 Administrator's Guide—see at OpenLDAP 2.4 Administrator's Guide.
The Web site of the OpenLDAP project offers exhaustive documentation for beginner and advanced LDAP users:
A detailed question and answer collection applying to the installation, configuration, and use of OpenLDAP. Find it at http://www.openldap.org/faq/data/cache/1.html.
Brief step-by-step instructions for installing your first LDAP server.
Find it at
http://www.openldap.org/doc/admin24/quickstart.html
or on an installed system in Section 2 of
/usr/share/doc/packages/openldap2/guide/admin/guide.html
.
A detailed introduction to all important aspects of LDAP
configuration, including access controls and encryption. See
http://www.openldap.org/doc/admin24/ or, on an
installed system,
/usr/share/doc/packages/openldap2/guide/admin/guide.html
.
A detailed general introduction to the basic principles of LDAP: http://www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf.
Printed literature about LDAP:
LDAP System Administration by Gerald Carter (ISBN 1-56592-491-6)
Understanding and Deploying LDAP Directory Services by Howes, Smith, and Good (ISBN 0-672-32316-8)
The ultimate reference material for the subject of LDAP are the corresponding RFCs (request for comments), 2251 to 2256.
An open network provides no means of ensuring that a workstation can identify its users properly, except through the usual password mechanisms. In common installations, the user must enter the password each time a service inside the network is accessed. Kerberos provides an authentication method with which a user registers only once and is trusted in the complete network for the rest of the session. To have a secure network, the following requirements must be met:
Have all users prove their identity for each desired service and make sure that no one can take the identity of someone else.
Make sure that each network server also proves its identity. Otherwise an attacker might be able to impersonate the server and obtain sensitive information transmitted to the server. This concept is called mutual authentication, because the client authenticates to the server and vice versa.
Kerberos helps you meet these requirements by providing strongly encrypted authentication. Only the basic principles of Kerberos are discussed here. For detailed technical instruction, refer to the Kerberos documentation.
The following glossary defines some Kerberos terminology.
Users or clients need to present some kind of credentials that authorize them to request services. Kerberos knows two kinds of credentials—tickets and authenticators.
A ticket is a per-server credential used by a client to authenticate at a server from which it is requesting a service. It contains the name of the server, the client's name, the client's Internet address, a time stamp, a lifetime, and a random session key. All this data is encrypted using the server's key.
Combined with the ticket, an authenticator is used to prove that the client presenting a ticket is really the one it claims to be. An authenticator is built using the client's name, the workstation's IP address, and the current workstation's time, all encrypted with the session key known only to the client and the relevant server. An authenticator can only be used once, unlike a ticket. A client can build an authenticator itself.
A Kerberos principal is a unique entity (a user or service) to which it can assign a ticket. A principal consists of the following components:
USER/INSTANCE@REALM
primary: The first part of the principal. In the case of users, this is usually the same as the user name.
instance (optional):
Additional information characterizing the
primary. This string is separated from the
primary by a /
.
tux@example.org
and
tux/admin@example.org
can both exist on the same
Kerberos system and are treated as different principals.
realm: Specifies the Kerberos realm. Normally, your realm is your domain name in uppercase letters.
Kerberos ensures that both client and server can be sure of each others identity. They share a session key, which they can use to communicate securely.
Session keys are temporary private keys generated by Kerberos. They are known to the client and used to encrypt the communication between the client and the server for which it requested and received a ticket.
Almost all messages sent in a network can be eavesdropped, stolen, and resent. In the Kerberos context, this would be most dangerous if an attacker manages to obtain your request for a service containing your ticket and authenticator. The attacker could then try to resend it (replay) to impersonate you. However, Kerberos implements several mechanisms to deal with this problem.
Service is used to refer to a specific action to perform. The process behind this action is called a server.
Kerberos is often called a third-party trusted authentication service, which means all its clients trust Kerberos's judgment of another client's identity. Kerberos keeps a database of all its users and their private keys.
To ensure Kerberos is working correctly, run both the authentication and
ticket-granting server on a dedicated machine. Make sure that only the
administrator can access this machine physically and over the network.
Reduce the (networking) services running on it to the absolute
minimum—do not even run
sshd
.
Your first contact with Kerberos is quite similar to any login procedure at a normal networking system. Enter your user name. This piece of information and the name of the ticket-granting service are sent to the authentication server (Kerberos). If the authentication server knows you, it generates a random session key for further use between your client and the ticket-granting server. Now the authentication server prepares a ticket for the ticket-granting server. The ticket contains the following information—all encrypted with a session key only the authentication server and the ticket-granting server know:
The names of both, the client and the ticket-granting server
The current time
A lifetime assigned to this ticket
The client's IP address
The newly-generated session key
This ticket is then sent back to the client together with the session key, again in encrypted form, but this time the private key of the client is used. This private key is only known to Kerberos and the client, because it is derived from your user password. Now that the client has received this response, you are prompted for your password. This password is converted into the key that can decrypt the package sent by the authentication server. The package is “unwrapped” and password and key are erased from the workstation's memory. As long as the lifetime given to the ticket used to obtain other tickets does not expire, your workstation can prove your identity.
To request a service from any server in the network, the client application needs to prove its identity to the server. Therefore, the application generates an authenticator. An authenticator consists of the following components:
The client's principal
The client's IP address
The current time
A checksum (chosen by the client)
All this information is encrypted using the session key that the client has already received for this special server. The authenticator and the ticket for the server are sent to the server. The server uses its copy of the session key to decrypt the authenticator, which gives it all the information needed about the client requesting its service, to compare it to that contained in the ticket. The server checks if the ticket and the authenticator originate from the same client.
Without any security measures implemented on the server side, this stage of the process would be an ideal target for replay attacks. Someone could try to resend a request stolen off the net some time before. To prevent this, the server does not accept any request with a time stamp and ticket received previously. In addition to that, a request with a time stamp differing too much from the time the request is received is ignored.
Kerberos authentication can be used in both directions. It is not only a question of the client being the one it claims to be. The server should also be able to authenticate itself to the client requesting its service. Therefore, it sends an authenticator itself. It adds one to the checksum it received in the client's authenticator and encrypts it with the session key, which is shared between it and the client. The client takes this response as a proof of the server's authenticity and they both start cooperating.
Tickets are designed to be used for one server at a time. Therefore, you need to get a new ticket each time you request another service. Kerberos implements a mechanism to obtain tickets for individual servers. This service is called the “ticket-granting service”. The ticket-granting service is a service (like any other service mentioned before) and uses the same access protocols that have already been outlined. Any time an application needs a ticket that has not already been requested, it contacts the ticket-granting server. This request consists of the following components:
The requested principal
The ticket-granting ticket
An authenticator
Like any other server, the ticket-granting server now checks the ticket-granting ticket and the authenticator. If they are considered valid, the ticket-granting server builds a new session key to be used between the original client and the new server. Then the ticket for the new server is built, containing the following information:
The client's principal
The server's principal
The current time
The client's IP address
The newly-generated session key
The new ticket has a lifetime, which is either the remaining lifetime of the ticket-granting ticket or the default for the service. The lesser of both values is assigned. The client receives this ticket and the session key, which are sent by the ticket-granting service. But this time the answer is encrypted with the session key that came with the original ticket-granting ticket. The client can decrypt the response without requiring the user's password when a new service is contacted. Kerberos can thus acquire ticket after ticket for the client without bothering the user.
Ideally, a user only contact with Kerberos happens during login at the workstation. The login process includes obtaining a ticket-granting ticket. At logout, a user's Kerberos tickets are automatically destroyed, which makes it difficult for anyone else to impersonate this user.
The automatic expiration of tickets can lead to a situation when a user's login session lasts longer than the maximum
lifespan given to the ticket-granting ticket (a reasonable setting is 10
hours). However, the user can get a new ticket-granting ticket by running
kinit
. Enter the password again and Kerberos obtains
access to desired services without additional authentication. To get a
list of all the tickets silently acquired for you by Kerberos, run
klist
.
Here is a short list of applications that use Kerberos authentication.
These applications can be found under
/usr/lib/mit/bin
or
/usr/lib/mit/sbin
after installing the package
krb5-apps-clients
. They all have the full
functionality of their common Unix and Linux brothers plus the additional
bonus of transparent authentication managed by Kerberos:
telnet
,
telnetd
rlogin
rsh
, rcp
,
rshd
ftp
, ftpd
ksu
You no longer need to enter your password for using these applications
because Kerberos has already proven your identity.
ssh
, if compiled with Kerberos support, can even
forward all the tickets acquired for one workstation to another one. If
you use ssh
to log in to another workstation,
ssh
makes sure that the encrypted contents of the
tickets are adjusted to the new situation. Simply copying tickets between
workstations is not sufficient because the ticket contains
workstation-specific information (the IP address). XDM and GDM offer
Kerberos support, too. Read more about the Kerberos network applications
in Kerberos V5 UNIX User's Guide at
http://web.mit.edu/kerberos.
A Kerberos environment consists of several components. A key distribution center (KDC) holds the central database with all Kerberos-relevant data. All clients rely on the KDC for proper authentication across the network. Both the KDC and the clients need to be configured to match your setup:
Check your network setup and make sure it meets the minimum requirements outlined in Section 6.5.1, “Kerberos Network Topology”. Choose an appropriate realm for your Kerberos setup, see Section 6.5.2, “Choosing the Kerberos Realms”. Carefully set up the machine that is to serve as the KDC and apply tight security, see Section 6.5.3, “Setting Up the KDC Hardware”. Set up a reliable time source in your network to make sure all tickets contain valid time stamps, see Section 6.5.4, “Configuring Time Synchronization”.
Configure the KDC and the clients, see Section 6.5.5, “Configuring the KDC” and Section 6.5.6, “Configuring Kerberos Clients”. Enable remote administration for your Kerberos service, so you do not need physical access to your KDC machine, see Section 6.5.7, “Configuring Remote Kerberos Administration”. Create service principals for every service in your realm, see Section 6.5.8, “Creating Kerberos Service Principals”.
Various services in your network can use Kerberos. To add Kerberos password-checking to applications using PAM, proceed as outlined in Section 6.5.9, “Enabling PAM Support for Kerberos”. To configure SSH or LDAP with Kerberos authentication, proceed as outlined in Section 6.5.10, “Configuring SSH for Kerberos Authentication” and Section 6.5.11, “Using LDAP and Kerberos”.
Any Kerberos environment must meet the following requirements to be fully functional:
Provide a DNS server for name resolution across your network, so clients and servers can locate each other. Refer to Book “Reference”, Chapter 19 “The Domain Name System” for information on DNS setup.
Provide a time server in your network. Using exact time stamps is crucial to a Kerberos setup, because valid Kerberos tickets must contain correct time stamps. Refer to Book “Reference”, Chapter 18 “Time Synchronization with NTP” for information on NTP setup.
Provide a key distribution center (KDC) as the center piece of the Kerberos architecture. It holds the Kerberos database. Use the tightest possible security policy on this machine to prevent any attacks on this machine compromising your entire infrastructure.
Configure the client machines to use Kerberos authentication.
The following figure depicts a simple example network with only the minimum components needed to build a Kerberos infrastructure. Depending on the size and topology of your deployment, your setup may vary.
For a setup similar to the one in Figure 6.1, “Kerberos Network Topology”, configure routing between the two subnets (192.168.1.0/24 and 192.168.2.0/24). Refer to Book “Reference”, Chapter 13 “Basic Networking”, Section 13.4.1.5 “Configuring Routing” for more information on configuring routing with YaST.
The domain of a Kerberos installation is called a realm and is
identified by a name, such as EXAMPLE.COM
or simply
ACCOUNTING
. Kerberos is case-sensitive, so
example.com
is actually a different realm than
EXAMPLE.COM
. Use the case you prefer. It is common
practice, however, to use uppercase realm names.
It is also a good idea to use your DNS domain name (or a subdomain, such
as ACCOUNTING.EXAMPLE.COM
). As shown below, your life
as an administrator can be much easier if you configure your Kerberos
clients to locate the KDC and other Kerberos services via DNS. To do so,
it is helpful if your realm name is a subdomain of your DNS domain name.
Unlike the DNS name space, Kerberos is not hierarchical. So if you have
a realm named EXAMPLE.COM
with two
“subrealms” named DEVELOPMENT
and
ACCOUNTING
, these subordinate realms do not inherit
principals from EXAMPLE.COM
. Instead, you would have
three separate realms, and you would need to configure cross-realm
authentication for each realm, so that users from one realm can interact with
servers or other users from another realm.
For the sake of simplicity, let us assume you are setting up only one
realm for your entire organization. For the remainder of this section,
the realm name EXAMPLE.COM
is used in all examples.
The first thing required to use Kerberos is a machine that acts as the key distribution center, or KDC for short. This machine holds the entire Kerberos user database with passwords and all information.
The KDC is the most important part of your security infrastructure—if someone breaks into it, all user accounts and all of your infrastructure protected by Kerberos is compromised. An attacker with access to the Kerberos database can impersonate any principal in the database. Tighten security for this machine as much as possible:
Put the server machine into a physically secured location, such as a locked server room to which only a very few people have access.
Do not run any network applications on it except the KDC. This includes servers and clients—for example, the KDC should not import any file systems via NFS or use DHCP to retrieve its network configuration.
Install a minimal system first then check the list of installed
packages and remove any unneeded packages. This includes servers, such
as inetd
,
portmap
, and CUPS, plus
anything X-based. Even installing an SSH server should be considered a
potential security risk.
No graphical login is provided on this machine as an X server is a potential security risk. Kerberos provides its own administration interface.
Configure /etc/nsswitch.conf
to use only local
files for user and group lookup. Change the lines for
passwd
and group
to look like
this:
passwd: files group: files
Edit the passwd
, group
, and
shadow
files in /etc
and
remove the lines that start with a +
character
(these are for NIS lookups).
Disable all user accounts except root
's account by editing
/etc/shadow
and replacing the hashed passwords
with *
or !
characters.
To use Kerberos successfully, make sure that all system clocks within your organization are synchronized within a certain range. This is important because Kerberos protects against replayed credentials. An attacker might be able to observe Kerberos credentials on the network and reuse them to attack the server. Kerberos employs several defenses to prevent this. One of them is that it puts time stamps into its tickets. A server receiving a ticket with a time stamp that differs from the current time rejects the ticket.
Kerberos allows a certain leeway when comparing time stamps. However, computer clocks can be very inaccurate in keeping time—it is not unheard of for PC clocks to lose or gain half an hour during a week. For this reason, configure all hosts on the network to synchronize their clocks with a central time source.
A simple way to do so is by installing an NTP time server on one machine and
having all clients synchronize their clocks with this server. Do this by
running an NTP daemon chronyd
as a client on all these machines. The KDC
itself needs to be synchronized to the common time source as well. Because
running an NTP daemon on this machine would be a security risk, it is
probably a good idea to do this by running chronyd -q
via
a cron job. To configure your machine as an NTP client, proceed as outlined
in Book “Reference”, Chapter 18 “Time Synchronization with NTP”, Section 18.1 “Configuring an NTP Client with YaST”.
A different way to secure the time service and still use the NTP daemon is to attach a hardware reference clock to a dedicated NTP server and an additional hardware reference clock to the KDC.
It is also possible to adjust the maximum deviation Kerberos allows when
checking time stamps. This value (called clock
skew) can be set in the krb5.conf
file
as described in
Section 6.5.6.3, “Adjusting the Clock Skew”.
This section covers the initial configuration and installation of the KDC, including the creation of an administrative principal. This procedure consists of several steps:
Install the RPMs.
On a machine designated as the KDC, install the following software
packages: krb5
,
krb5-server
and
krb5-client
packages.
Adjust the Configuration Files.
The /etc/krb5.conf
and
/var/lib/kerberos/krb5kdc/kdc.conf
configuration
files must be adjusted for your scenario. These files contain all
information on the KDC.
Create the Kerberos Database. Kerberos keeps a database of all principal identifiers and the secret keys of all principals that need to be authenticated. Refer to Section 6.5.5.1, “Setting Up the Database” for details.
Adjust the ACL Files: Add Administrators.
The Kerberos database on the KDC can be managed remotely. To prevent
unauthorized principals from tampering with the database, Kerberos
uses access control lists. You must explicitly enable remote access
for the administrator principal to enable them to manage the database.
The Kerberos ACL file is located under
/var/lib/kerberos/krb5kdc/kadm5.acl
. Refer to
Section 6.5.7, “Configuring Remote Kerberos Administration” for details.
Adjust the Kerberos Database: Add Administrators. You need at least one administrative principal to run and administer Kerberos. This principal must be added before starting the KDC. Refer to Section 6.5.5.2, “Creating a Principal” for details.
Start the Kerberos Daemon. After the KDC software is installed and properly configured, start the Kerberos daemon to provide Kerberos service for your realm. Refer to Section 6.5.5.3, “Starting the KDC” for details.
Create a Principal for Yourself. You need a principal for yourself. Refer to Section 6.5.5.2, “Creating a Principal” for details.
Your next step is to initialize the database where Kerberos keeps all information about principals. Set up the database master key, which is used to protect the database from accidental disclosure (in particular if it is backed up to tape). The master key is derived from a pass phrase and is stored in a file called the stash file. This is so you do not need to enter the password every time the KDC is restarted. Make sure that you choose a good pass phrase, such as a sentence from a book opened to a random page.
When you make tape backups of the Kerberos database
(/var/lib/kerberos/krb5kdc/principal
), do not back
up the stash file (which is in
/var/lib/kerberos/krb5kdc/.k5.EXAMPLE.COM
).
Otherwise, everyone able to read the tape could also decrypt the
database. Therefore, keep a copy of the pass phrase in a safe or some
other secure location, because you will need it to restore your
database from backup tape after a crash.
To create the stash file and the database, run:
tux >
sudo
kdb5_util create -r EXAMPLE.COM -s
You will see the following output:
Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: 1 Re-enter KDC database master key to verify: 2
To verify, use the list command:
tux >
kadmin.localkadmin>
listprincs
You will see several principals in the database, which are for internal use by Kerberos:
K/M@EXAMPLE.COM kadmin/admin@EXAMPLE.COM kadmin/changepw@EXAMPLE.COM krbtgt/EXAMPLE.COM@EXAMPLE.COM
Create two Kerberos principals for yourself: one normal principal for
everyday work and one for administrative tasks relating to Kerberos.
Assuming your login name is exampleuserIII_plain
, proceed as follows:
tux >
kadmin.localkadmin>
ank geeko
You will see the following output:
geeko@EXAMPLE.COM's Password: 1 Verifying password: 2
Next, create another principal named
geeko/admin
by typing
ank
geeko/admin
at
the kadmin
prompt. The admin
suffixed to your user name is a role. Later, use
this role when administering the Kerberos database. A user can have
several roles for different purposes. Roles act like completely
different accounts that have similar names.
Start the KDC daemon and the kadmin daemon. To start the daemons manually, enter:
tux >
sudo
systemctl start krb5kdc sudo systemctl start kadmind
Also make sure that the services KDC (krb5kdc
) and
kadmind (kadmind
) are started by
default when the server machine is rebooted. Enable them by entering:
tux >
sudo
systemctl enable krb5kdc kadmind
or by using the YaST
.When the supporting infrastructure is in place (DNS, NTP) and the KDC has been properly configured and started, configure the client machines. To configure a Kerberos client, use one of the two manual approaches described below.
When configuring Kerberos, there are two approaches you can
take—static configuration in the
/etc/krb5.conf
file or dynamic configuration with
DNS. With DNS configuration, Kerberos applications try to locate the
KDC services using DNS records. With static configuration, add the host
names of your KDC server to krb5.conf
(and update
the file whenever you move the KDC or reconfigure your realm in other
ways).
DNS-based configuration is generally a lot more flexible and the amount
of configuration work per machine is a lot less. However, it requires
that your realm name is either the same as your DNS domain or a
subdomain of it. Configuring Kerberos via DNS also creates a
security issue: An attacker can seriously disrupt your
infrastructure through your DNS (by shooting down the name server,
spoofing DNS records, etc.). However, this amounts to a denial of
service at worst. A similar scenario applies to the static
configuration case unless you enter IP addresses in
krb5.conf
instead of host names.
One way to configure Kerberos is to edit
/etc/krb5.conf
. The file installed by default
contains various sample entries. Erase all of these entries before
starting. krb5.conf
is made up of several
sections (stanzas), each introduced by the section name in brackets
like [this]
.
To configure your Kerberos clients, add the following stanza to
krb5.conf
(where
kdc.example.com
is the
host name of the KDC):
[libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.example.com admin_server = kdc.example.com }
The default_realm
line sets the default realm for
Kerberos applications. If you have several realms, add additional
statements to the [realms]
section.
Also add a statement to this file that tells applications how to map
host names to a realm. For example, when connecting to a remote host,
the Kerberos library needs to know in which realm this host is
located. This must be configured in the
[domain_realms]
section:
[domain_realm] .example.com = EXAMPLE.COM www.example.org = EXAMPLE.COM
This tells the library that all hosts in the
example.com
DNS domains are in the
EXAMPLE.COM
Kerberos realm. In addition, one
external host named www.example.org
should also
be considered a member of the EXAMPLE.COM
realm.
DNS-based Kerberos configuration makes heavy use of SRV records. See (RFC2052) A DNS RR for specifying the location of services at http://www.ietf.org.
The name of an SRV record, as far as Kerberos is concerned, is always
in the format _service._proto.realm
, where realm is
the Kerberos realm. Domain names in DNS are case-insensitive, so
case-sensitive Kerberos realms would break when using this
configuration method. _service
is a service name
(different names are used when trying to contact the KDC or the
password service, for example). _proto
can be
either _udp
or _tcp
, but not all
services support both protocols.
The data portion of SRV resource records consists of a priority value, a weight, a port number, and a host name. The priority defines the order in which hosts should be tried (lower values indicate a higher priority). The weight value is there to support some sort of load balancing among servers of equal priority. You probably do not need any of this, so it is okay to set these to zero.
MIT Kerberos currently looks up the following names when looking for services:
This defines the location of the KDC daemon (the authentication and ticket granting server). Typical records look like this:
_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc.example.com.
This describes the location of the remote administration service. Typical records look like this:
_kerberos-adm._tcp.EXAMPLE.COM. IN SRV 0 0 749 kdc.example.com.
Because kadmind does not support UDP, there should be no
_udp
record.
As with the static configuration file, there is a mechanism to inform
clients that a specific host is in the EXAMPLE.COM
realm, even if it is not part of the example.com
DNS domain. This can be done by attaching a TXT record to
_kerberos.host_name
, as shown here:
_kerberos.www.example.org. IN TXT "EXAMPLE.COM"
The clock skew is the tolerance for accepting tickets with time stamps that do not exactly match the host's system clock. Usually, the clock skew is set to 300 seconds (five minutes). This means a ticket can have a time stamp somewhere between five minutes behind and five minutes ahead of the server's clock.
When using NTP to synchronize all hosts, you can reduce this value to
about one minute. The clock skew value can be set in
/etc/krb5.conf
like this:
[libdefaults] clockskew = 60
To be able to add and remove principals from the Kerberos database
without accessing the KDC's console directly, tell the Kerberos
administration server which principals are allowed to do what by editing
/var/lib/kerberos/krb5kdc/kadm5.acl
. The ACL
(access control list) file allows you to specify privileges with a
precise degree of control. For details, refer to the manual page with
man
8 kadmind
.
For now, grant yourself the privilege to administer the database by putting the following line into the file:
geeko/admin *
Replace the user name exampleuserIII_plain
with your own. Restart
kadmind
for the change to take effect.
You should now be able to perform Kerberos administration tasks remotely using the kadmin tool. First, obtain a ticket for your admin role and use that ticket when connecting to the kadmin server:
tux >
kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin: getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:
Using the getprivs
command, verify which privileges
you have. The list shown above is the full set of privileges.
As an example, modify the principal exampleuserIII_plain
:
tux >
kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin: getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin: modify_principal -maxlife "8 hours" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin: getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:
This changes the maximum ticket life time to eight hours. For more
information about the kadmin
command and the options
available, see the krb5-doc
package or refer to
the man
8 kadmin
manual page.
So far, only user credentials have been discussed. However,
Kerberos-compatible services usually need to authenticate themselves to
the client user, too. Therefore, special service principals must be
in the Kerberos database for each service offered in the realm.
For example, if ldap.example.com offers an LDAP service, you need a service
principal, ldap/ldap.example.com@EXAMPLE.COM
, to
authenticate this service to all clients.
The naming convention for service principals is
SERVICE/HOSTNAME@REALM
,
where HOSTNAME is the host's fully qualified
host name.
Valid service descriptors are:
Service Descriptor |
Service |
---|---|
|
Telnet, RSH, SSH |
|
NFSv4 (with Kerberos support) |
|
HTTP (with Kerberos authentication) |
|
IMAP |
|
POP3 |
|
LDAP |
Service principals are similar to user principals, but have significant differences. The main difference between a user principal and a service principal is that the key of the former is protected by a password. When a user obtains a ticket-granting ticket from the KDC, they needs to type their password, so Kerberos can decrypt the ticket. It would be inconvenient for system administrators to obtain new tickets for the SSH daemon every eight hours or so.
Instead, the key required to decrypt the initial ticket for the service
principal is extracted by the administrator from the KDC only once and
stored in a local file called the keytab. Services
such as the SSH daemon read this key and use it to obtain new tickets
automatically, when needed. The default keytab file resides in
/etc/krb5.keytab
.
To create a host service principal for jupiter.example.com
enter the following commands during your kadmin session:
tux >
kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin: addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.
Instead of setting a password for the new principal, the
-randkey
flag tells kadmin
to
generate a random key. This is used here because no user interaction is
wanted for this principal. It is a server account for the machine.
Finally, extract the key and store it in the local keytab file
/etc/krb5.keytab
. This file is owned by the
superuser, so you must be root
to execute the next command in the kadmin shell:
kadmin: ktadd host/jupiter.example.com Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/jupiter.example.com with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab. kadmin:
When completed, make sure that you destroy the admin ticket obtained
with kinit above with kdestroy
.
An incomplete Kerberos configuration may completely lock you out of
your system, including the root user. To prevent this, add the
ignore_unknown_principals
directive to the
pam_krb5
module after you
have added the pam_krb5
module to the existing
PAM configuration files as described below.
tux >
sudo
pam-config --add --krb5-ignore_unknown_principals
This will direct the pam_krb5
module to ignore
some errors that would otherwise cause the account phase to fail.
openSUSE® Leap comes with a PAM module named
pam_krb5
, which supports Kerberos login and
password update. This module can be used by applications such as console
login, su
, and graphical login applications like GDM.
That is, it can be used in all cases where the user enters a password
and expects the authenticating application to obtain an initial Kerberos
ticket on their behalf. To configure PAM support for Kerberos, use the
following command:
tux >
sudo
pam-config --add --krb5
The above command adds the pam_krb5
module to the
existing PAM configuration files and makes sure it is called in the
right order. To make precise adjustments to the way in which
pam_krb5
is used, edit the file
/etc/krb5.conf
and add default applications to
PAM. For details, refer to the manual page with
man 5 pam_krb5
.
The pam_krb5
module was specifically not designed
for network services that accept Kerberos tickets as part of user
authentication. This is an entirely different matter, and is
discussed below.
OpenSSH supports Kerberos authentication in both protocol version 1 and 2. In version 1, there are special protocol messages to transmit Kerberos tickets. Version 2 does not use Kerberos directly anymore, but relies on GSSAPI, the General Security Services API. This is a programming interface that is not specific to Kerberos—it was designed to hide the peculiarities of the underlying authentication system, be it Kerberos, a public-key authentication system like SPKM, or others. However, the included GSSAPI library only supports Kerberos.
To use sshd with Kerberos authentication, edit
/etc/ssh/sshd_config
and set the following options:
# These are for protocol version 1 # # KerberosAuthentication yes # KerberosTicketCleanup yes # These are for version 2 - better to use this GSSAPIAuthentication yes GSSAPICleanupCredentials yes
Then restart your SSH daemon using sudo systemctl restart
sshd
.
To use Kerberos authentication with protocol version 2, enable it on the
client side as well. Do this either in the system wide configuration file
/etc/ssh/ssh_config
or on a per-user level by
editing ~/.ssh/config
. In both cases, add the
option GSSAPIAuthentication yes
.
You should now be able to connect using Kerberos authentication. Use
klist
to verify that you have a valid ticket, then
connect to the SSH server. To force SSH protocol version 1, specify the
-1
option on the command line.
The file
/usr/share/doc/packages/openssh/README.kerberos
discusses the interaction of OpenSSH and Kerberos in more detail.
The GSSAPIKeyExchange
mechanism (RFC 4462) is
supported. This directive specifies how host keys are exchanged. For
more information, see the sshd_config manual page (man
sshd_config
).
When using Kerberos, one way to distribute the user information (such as user ID, groups, and home directory) in your local network is to use LDAP. This requires a strong authentication mechanism that prevents packet spoofing and other attacks. One solution is to use Kerberos for LDAP communication, too.
OpenLDAP implements most authentication flavors through SASL, the simple
authentication session layer. SASL is a network protocol designed for
authentication. The SASL implementation is cyrus-sasl, which supports
several authentication flavors. Kerberos authentication is
performed through GSSAPI (General Security Services API). By default,
the SASL plug-in for GSSAPI is not installed. Install the
cyrus-sasl-gssapi
with YaST.
To enable Kerberos to bind to the OpenLDAP server, create a principal
ldap/ldap.example.com
and add that to the keytab.
By default, the LDAP server slapd runs as user and group
ldap
, while the keytab file is
readable by root
only.
Therefore, either change the LDAP configuration so the server runs as
root
or make the keytab file
readable by the group ldap
.
The latter is done automatically by the OpenLDAP start script
(/usr/lib/openldap/start
) if the keytab file has
been specified in the OPENLDAP_KRB5_KEYTAB
variable in
/etc/sysconfig/openldap
and the
OPENLDAP_CHOWN_DIRS
variable is set to
yes
, which is the default setting. If
OPENLDAP_KRB5_KEYTAB
is left empty, the default keytab
under /etc/krb5.keytab
is used and you must adjust
the privileges yourself as described below.
To run slapd as root
, edit
/etc/sysconfig/openldap
. Disable the
OPENLDAP_USER
and
OPENLDAP_GROUP
variables by putting a comment
character in front of them.
To make the keytab file readable by group LDAP, execute
tux >
sudo
chgrp ldap /etc/krb5.keytabtux >
sudo
chmod 640 /etc/krb5.keytab
A third (and maybe the best) solution is to tell OpenLDAP to use a special keytab file. To do this, start kadmin, and enter the following command after you have added the principal ldap/ldap.example.com:
tux >
sudo
ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM
Then in the shell run:
tux >
sudo
chown ldap:ldap /etc/openldap/ldap.keytabtux >
sudo
chmod 600 /etc/openldap/ldap.keytab
To tell OpenLDAP to use a different keytab file, change the following
variable in /etc/sysconfig/openldap
:
OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"
Finally, restart the LDAP server using sudo systemctl
restart slapd
.
You are now able to automatically use tools such as ldapsearch with Kerberos authentication.
tux >
ldapsearch -b ou=people,dc=example,dc=com '(uid=geeko)'
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]
# geeko, people, example.com
dn: uid=geeko,ou=people,dc=example,dc=com
uid: geeko
cn: Suzanne Geeko
[...]
As you can see, ldapsearch
prints a message that it
started GSSAPI authentication. The next message is very cryptic, but it
shows that the security strength factor (SSF for
short) is 56 (The value 56 is somewhat arbitrary. Most likely it was
chosen because this is the number of bits in a DES encryption key).
This means that GSSAPI authentication was successful and that
encryption is being used to protect integrity and provide
confidentiality for the LDAP connection.
In Kerberos, authentication is always mutual. This means that not only have you authenticated yourself to the LDAP server, but also the LDAP server has authenticated itself to you. In particular, this means communication is with the desired LDAP server, rather than some bogus service set up by an attacker.
There is one minor piece of the puzzle missing—how the LDAP
server can find out that the Kerberos user
tux@EXAMPLE.COM
corresponds to the LDAP
distinguished name
uid=tux,ou=people,dc=example,dc=com
.
This sort of mapping must be configured manually using the
saslExpr
directive. In this example, the
"authz-regexp" change in LDIF would look as follows:
dn: cn=config add: olcAuthzRegexp olcAuthzRegexp: uid=(.*),cn=GSSAPI,cn=auth uid=$1,ou=people,dc=example,dc=com
All these changes can be applied via ldapmodify
on
the command line.
When SASL authenticates a user, OpenLDAP forms a distinguished name
from the name given to it by SASL (such as tux
) and the
name of the SASL flavor (GSSAPI
). The result
would be
uid=tux,cn=GSSAPI,cn=auth
.
If a authz-regexp
has been configured, it checks the
DN formed from the SASL information using the first argument as a
regular expression. If this regular expression matches, the name is
replaced with the second argument of the
authz-regexp
statement. The placeholder
$1
is replaced with the substring matched by the
(.*)
expression.
More complicated match expressions are possible. If you have a more complicated directory structure or a schema in which the user name is not part of the DN, you can even use search expressions to map the SASL DN to the user DN.
For more information, see the slapd-config
man page.
YaST includes the module
that helps define authentication scenarios involving either LDAP or Kerberos.It can also be used to join Kerberos and LDAP separately. However, in many such cases, using this module may not be the first choice, such as for joining Active Directory (which uses a combination of LDAP and Kerberos). For more information, see Section 4.2, “Configuring an Authentication Client with YaST”.
Start the module by selecting
› .To configure a Kerberos client, follow the procedure below:
In the window
, click .Choose the tab
.Click
.In the appearing dialog, specify the correct
. Usually, the realm name is an uppercase version of the domain name. Additionally, you can specify the following:To apply mappings from the realm name to the domain name, activate
and/or .You can specify the
, the and additional .
All of these items are optional if they can be automatically
discovered via the SRV
and
TXT
records in DNS.
To manually map Principals to local user names, use
.
You can also use auth_to_local
rules to supply such
mappings using . For more information about using such rules, see
the official documentation at
https://web.mit.edu/kerberos/krb5-current/doc/admin/conf_files/krb5_conf.html#realms
and an article at https://community.hortonworks.com/articles/14463/auth-to-local-rules-syntax.html.
Continue with
.To add more realms, repeat from Step 2.
Enable Kerberos users logging in and creation of home directories by activating
and .If you left empty the optional text boxes in Step 3, make sure to enable automatic discovery of realms and key distribution centers by activating and .
You can additionally activate the following:
http://web.mit.edu/kerberos/krb5-current/doc/admin/conf_files/kdc_conf.html#encryption-types.
allows the encryption types listed as weak atallows forwarding of tickets.
allows the use of proxies between the computer of the user and the key distribution center.
allows granting tickets to users behind networks using network address translation.
To set up allowed encryption types and define the name of the keytab file which lists the names of principals and their encrypted keys, use the
.Finish with
and .YaST may now install extra packages.
Most NFS servers can export file systems using any combination of the
default “trust the network” form of security known as
sec=sys
, and three different levels of Kerberos-based
security, sec=krb5
, sec=krb5i
, and
sec=krb5p
. The sec
option is set as a
mount option on the client. It is often the case that the NFS service will first
be configured and used with sec=sys
, and then Kerberos can be
imposed afterwards. In this case it is likely that the server will be
configured to support both sec=sys
and one of the Kerberos
levels, and then after all clients have transitioned, the
sec=sys
support will be removed, thus achieving true
security. The transition to Kerberos should be fairly transparent if done in an
orderly manner. However there is one subtle detail of NFS behavior that
works differently when Kerberos is used, and the implications of this need to
be understood and possibly addressed. See Section 6.7.1, “Group Membership”.
The three Kerberos levels indicate different levels of security. With more security comes a need for more processor power to encrypt and decrypt messages. Choosing the right balance is an important consideration when planning a roll-out of Kerberos for NFS.
krb5
provides only authentication. The server
can know who sent a request, and the client can know that the
server sent a reply. No security is provided for the content of
the request or reply, so an attacker with physical network access
could transform the request or reply, or both, in various ways to
deceive either server or client. They cannot directly read or
change any file that the authenticated user could not read or
change, but almost anything is theoretically
possible.
krb5i
adds integrity checks to all messages.
With krb5i
, an attacker cannot modify any
request or reply, but they can view all the data exchanged, and so
could discover the content of any file that is read.
krb5p
adds privacy to the protocol. As well as
reliable authentication and integrity checking, messages are fully
encrypted so an attacker can only know that messages were exchanged
between client and server, and cannot extract other information
directly from the message. Whether information can be extracted
from message timing is a separate question that Kerberos does not
address.
The one behavioral difference between sec=sys
and
the various Kerberos security levels that might be visible is related
to group membership. In Unix and Linux, each file system access
comes from a process which is owned by a particular user and has a
particular group owner, and a number of supplemental groups. Access
rights to files can vary based on the owner and the various groups.
With sec=sys
, the user-id, group-id, and a list of
up to 16 supplementary groups are sent to the server in each
request.
If a user is a member of more than 16 supplementary groups, the extra groups are lost and some files may not be accessible over NFS that the user would normally expect to have access to. For this reason, most sites that use NFS find a way to limit all users to at most 16 supplementary groups.
If the user runs the newgrp
command or runs a
set-group-id program, either of which can change the list of groups
they are a member of, these changes take effect immediately and
provide different accesses over NFS.
With Kerberos, group information is not sent in requests at all. Only the user is identified (using a Kerberos “principal”), and the server performs a lookup to determine the user ID and group list for that principal. This means that if the user is a member of more than 16 groups, all of these group memberships will be used in determining file access permissions. However it also means that if the user changes a group-id on the client in some way, the server will not notice the change and will not take it into account in determining access rights.
In most cases, the improvement of having access to more groups brings a real benefit, and the loss of not being able to change groups is not noticed as it is not widely used. A site administrator considering the use of Kerberos should be aware of the difference though and ensure that it will not actually cause problems.
Using Kerberos for security requires extra CPU power for encrypting and
decrypting messages. How much extra CPU power is required and whether the
difference is noticeable will vary with different hardware and different
applications. If the server or client are already saturating the available
CPU power, it is likely that a performance drop will be measurable when
switching from sec=sys
to Kerberos. If there is spare CPU
capacity available, it is quite possible that the transition will not
result in any throughput change. The only way to be sure how much impact
the use of Kerberos will have is to test your load on your hardware.
The only configuration options that might reduce the load will also
reduce the quality of the protection offered.
sec=krb5
should produce noticeably less load than
sec=krb5p
but, as discussed above, it doesn't
produce very strong security. Similarly it is possible to adjust
the list of ciphers that Kerberos can choose from, and this might
change the CPU requirement. However the defaults are carefully
chosen and should not be changed without similar careful
consideration.
The other possible performance issue when configuring NFS to use Kerberos involves availability of the Kerberos authentication servers, known as the KDC or Key Distribution Center.
The use of NFS adds load to such servers to the same degree that
adding the use of Kerberos for any other services adds some load.
Every time a given user (Kerberos principal) establishes a
session with a service, for example by accessing files
exported by a particular NFS server, the client needs to negotiate
with the KDC. Once a session key has been negotiated, the client
server can communicate without further help for many hours,
depending on details of the Kerberos configuration, particularly the
ticket_lifetime
setting.
The concerns most likely to affect the provisioning of Kerberos KDC servers are availability and peak usage.
As with other core services such as DNS, LDAP or similar name-lookup
services, having two servers that are reasonably "close" to every client
provides good availability for modest resources. Kerberos allows for multiple
KDC servers with flexible models for database propagation, so distributing
servers as needed around campuses, buildings, and even cabinets is fairly
straightforward. The best mechanism to ensure each client finds a nearby
Kerberos server is to use split-horizon DNS with each building (or similar)
getting different details from the DNS server. If this is not possible,
then managing the /etc/krb5.conf
file to be different
at different locations is a suitable alternative.
As access to the Kerberos KDC is infrequent, load is only likely to be a problem at peak times. If thousands of people all log in between 9:00 and 9:05, then the servers will receive many more requests-per-minute than they might in the middle of the night. The load on the Kerberos server is likely to be more than that on an LDAP server, but not orders of magnitude more. A sensible guideline is to provision Kerberos replicas in the same manner that you provision LDAP replicas, and then monitor performance to determine if demand ever exceeds capacity.
One service of the Kerberos KDC that is not easily distributed is the handling of updates, such as password changes and new user creation. These must happen at a single master KDC.
These updates are not likely to happen with such frequency that any significant load will be generated, but availability could be an issue. It can be annoying if you want to create a new user or change a password, and the master KDC on the other side of the world is temporarily unavailable.
When an organization is geographically distributed and has a policy of handling administration tasks locally at each site, it can be beneficial to create multiple Kerberos domains, one for each administrative center. Each domain would then have its own master KDC which would be geographically local. Users in one domain can still get access to resources in another domain by setting up trust relationships between domains.
The easiest arrangement for multiple domains is to have a global domain (e.g. EXAMPLE.COM) and various local domains (e.g. ASIA.EXAMPLE.COM, EUROPE.EXAMPLE.COM, etc). If the global domain is configured to trust each local domain, and each local domain is configured to trust the global domain, then fully transitive trust is available between any pair of domains, and any principal can establish a secure connection with any service. Ensuring appropriate access rights to resources, for example files provided by that service, will be dependent on the user name lookup service used, and the functionality of the NFS file server, and is beyond the scope of this document.
The official site of MIT Kerberos is http://web.mit.edu/kerberos. There, find links to any other relevant resource concerning Kerberos, including Kerberos installation, user, and administration guides.
The book Kerberos—A Network Authentication System by Brian Tung (ISBN 0-201-37924-4) offers extensive information.
Active Directory* (AD) is a directory-service based on LDAP, Kerberos, and other services. It is used by Microsoft* Windows* to manage resources, services, and people. In a Microsoft Windows network, Active Directory provides information about these objects, restricts access to them, and enforces policies. openSUSE® Leap lets you join existing Active Directory domains and integrate your Linux machine into a Windows environment.
With a Linux client (configured as an Active Directory client) that is joined to an existing Active Directory domain, benefit from various features not available on a pure openSUSE Leap Linux client:
GNOME Files (previously called Nautilus) supports browsing shared resources through SMB.
GNOME Files supports sharing directories and files as in Windows.
Through GNOME Files, users can access their Windows user data and can edit, create, and delete files and directories on the Windows server. Users can access their data without having to enter their password multiple times.
Users can log in and access their local data on the Linux machine even if they are offline or the Active Directory server is unavailable for other reasons.
This port of Active Directory support in Linux enforces corporate password policies
stored in Active Directory. The display managers and console support
password change messages and accept your input. You can even use the
Linux passwd
command to set Windows passwords.
Many desktop applications are Kerberos-enabled (kerberized), which means they can transparently handle authentication for the user without the need for password reentry at Web servers, proxies, groupware applications, or other locations.
In Windows Server 2016 and later, Microsoft has removed the role IDMU/NIS Server and along with it the Unix Attributes plug-in for the Active Directory Users and Computers MMC snap-in.
However, Unix attributes can still be managed manually when Active Directory Users and Computers MMC snap-in. For more information, see Clarification regarding the status of Identity Management for Unix (IDMU) & NIS Server Role in Windows Server 2016 Technical Preview and beyond.
are enabled in theAlternatively, use the method described in Procedure 7.1, “Joining an Active Directory Domain Using to complete attributes on the client side (in particular, see ”Step 6.c).
The following section contains technical background for most of the previously named features. For more information about file and printer sharing using Active Directory, see Book “GNOME User Guide”.
Many system components need to interact flawlessly to integrate a Linux client into an existing Windows Active Directory domain. The following sections focus on the underlying processes of the key events in Active Directory server and client interaction.
To communicate with the directory service, the client needs to share at least two protocols with the server:
LDAP is a protocol optimized for managing directory information. A Windows domain controller with Active Directory can use the LDAP protocol to exchange directory information with the clients. To learn more about LDAP in general and about the open source port of it, OpenLDAP, refer to Chapter 5, LDAP—A Directory Service.
Kerberos is a third-party trusted authentication service. All its clients trust Kerberos's authorization of another client's identity, enabling kerberized single-sign-on (SSO) solutions. Windows supports a Kerberos implementation, making Kerberos SSO possible even with Linux clients. To learn more about Kerberos in Linux, refer to Chapter 6, Network Authentication with Kerberos.
Depending on which YaST module you use to set up Kerberos authentication, different client components process account and authentication data:
The sssd
daemon is the
central part of this solution. It handles all communication with the
Active Directory server.
To gather name service information,
sssd_nss
is used.
To authenticate users, the
pam_sss
module for PAM
is used. The creation of user homes for the Active Directory users on the Linux
client is handled by pam_mkhomedir
.
For more information about PAM, see Chapter 2, Authentication with PAM.
The winbindd
daemon is the
central part of this solution. It handles all communication with the
Active Directory server.
To gather name service information,
nss_winbind
is used.
To authenticate users, the
pam_winbind
module for PAM
is used. The creation of user homes for the Active Directory users on the Linux
client is handled by pam_mkhomedir
.
For more information about PAM, see Chapter 2, Authentication with PAM.
Figure 7.1, “Schema of Winbind-based Active Directory Authentication” highlights the most prominent components of Winbind-based Active Directory authentication.
Applications that are PAM-aware, like the login routines and the GNOME display manager, interact with the PAM and NSS layer to authenticate against the Windows server. Applications supporting Kerberos authentication (such as file managers, Web browsers, or e-mail clients) use the Kerberos credential cache to access user's Kerberos tickets, making them part of the SSO framework.
During domain join, the server and the client establish a secure relation. On the client, the following tasks need to be performed to join the existing LDAP and Kerberos SSO environment provided by the Windows domain controller. The entire join process is handled by the YaST Domain Membership module, which can be run during installation or in the installed system:
The Windows domain controller providing both LDAP and KDC (Key Distribution Center) services is located.
A machine account for the joining client is created in the directory service.
An initial ticket granting ticket (TGT) is obtained for the client and stored in its local Kerberos credential cache. The client needs this TGT to get further tickets allowing it to contact other services, like contacting the directory server for LDAP queries.
NSS and PAM configurations are adjusted to enable the client to authenticate against the domain controller.
During client boot, the winbind daemon is started and retrieves the initial Kerberos ticket for the machine account. winbindd automatically refreshes the machine's ticket to keep it valid. To keep track of the current account policies, winbindd periodically queries the domain controller.
The login manager of GNOME (GDM) has been extended to allow the handling of Active Directory domain login. Users can choose to log in to the primary domain the machine has joined or to one of the trusted domains with which the domain controller of the primary domain has established a trust relationship.
User authentication is mediated by several PAM modules as described in Section 7.2, “Background Information for Linux Active Directory Support”. If there are errors, the error codes are translated into user-readable error messages that PAM gives at login through any of the supported methods (GDM, console, and SSH):
Password has expired
The user sees a message stating that the password has expired and needs to be changed. The system prompts for a new password and informs the user if the new password does not comply with corporate password policies (for example the password is too short, too simple, or already in the history). If a user's password change fails, the reason is shown and a new password prompt is given.
Account disabled
The user sees an error message stating that the account has been disabled and to contact the system administrator.
Account locked out
The user sees an error message stating that the account has been locked and to contact the system administrator.
Password has to be changed
The user can log in but receives a warning that the password needs to be changed soon. This warning is sent three days before that password expires. After expiration, the user cannot log in.
Invalid workstation
When a user is restricted to specific workstations and the current openSUSE Leap machine is not among them, a message appears that this user cannot log in from this workstation.
Invalid logon hours
When a user is only allowed to log in during working hours and tries to log in outside working hours, a message informs the user that logging in is not possible at that time.
Account expired
An administrator can set an expiration time for a specific user account. If that user tries to log in after expiration, the user gets a message that the account has expired and cannot be used to log in.
During a successful authentication, the client acquires a ticket granting ticket (TGT) from the Kerberos server of Active Directory and stores it in the user's credential cache. It also renews the TGT in the background, requiring no user interaction.
openSUSE Leap supports local home directories for Active Directory users. If configured through YaST as described in Section 7.3, “Configuring a Linux Client for Active Directory”, user home directories are created when a Windows/Active Directory user first logs in to the Linux client. These home directories look and feel identical to standard Linux user home directories and work independently of the Active Directory Domain Controller.
Using a local user home, it is possible to access a user's data on this machine (even when the Active Directory server is disconnected) as long as the Linux client has been configured to perform offline authentication.
Users in a corporate environment must have the ability to become roaming users (for example, to switch networks or even work disconnected for some time). To enable users to log in to a disconnected machine, extensive caching was integrated into the winbind daemon. The winbind daemon enforces password policies even in the offline state. It tracks the number of failed login attempts and reacts according to the policies configured in Active Directory. Offline support is disabled by default and must be explicitly enabled in the YaST Domain Membership module.
When the domain controller has become unavailable, the user can still access network resources (other than the Active Directory server itself) with valid Kerberos tickets that have been acquired before losing the connection (as in Windows). Password changes cannot be processed unless the domain controller is online. While disconnected from the Active Directory server, a user cannot access any data stored on this server. When a workstation has become disconnected from the network entirely and connects to the corporate network again later, openSUSE Leap acquires a new Kerberos ticket when the user has locked and unlocked the desktop (for example, using a desktop screen saver).
Before your client can join an Active Directory domain, some adjustments must be made to your network setup to ensure the flawless interaction of client and server.
Configure your client machine to use a DNS server that can forward DNS requests to the Active Directory DNS server. Alternatively, configure your machine to use the Active Directory DNS server as the name service data source.
To succeed with Kerberos authentication, the client must have its time set accurately. It is highly recommended to use a central NTP time server for this purpose (this can be also the NTP server running on your Active Directory domain controller). If the clock skew between your Linux host and the domain controller exceeds a certain limit, Kerberos authentication fails and the client is logged in using the weaker NTLM (NT LAN Manager) authentication. For more details about using Active Directory for time synchronization, see Procedure 7.2, “ Joining an Active Directory Domain Using . ”
To browse your network neighborhood, either disable the firewall entirely or mark the interface used for browsing as part of the internal zone.
To change the firewall settings on your client, log in as
root
and start the YaST firewall module. Select
. Select your network interface from the
list of interfaces and click . Select
and apply your settings with
. Leave the firewall settings with › . To
disable the firewall, check the option, and leave the firewall module with
› .
You cannot log in to an Active Directory domain unless the Active Directory administrator has provided you with a valid user account for that domain. Use the Active Directory user name and password to log in to the Active Directory domain from your Linux client.
YaST contains multiple modules that allow connecting to an Active Directory:
Use both an identity service (usually LDAP) and a user authentication service (usually Kerberos). This option is based on SSSD and in the majority of cases is best suited for joining Active Directory domains. .
This module is described in Section 7.3.2, “ Joining Active Directory Using . ”
Join an Active Directory (which entails use of Kerberos and LDAP). This option is
based on . winbind
and is best suited for joining an
Active Directory domain if support for NTLM or cross-forest trusts is necessary.
This module is described in Section 7.3.3, “ Joining Active Directory Using . ”
Allows setting up LDAP identities and Kerberos authentication independently from each other and provides fewer options. While this module also uses SSSD, it is not as well suited for connecting to Active Directory as the previous two options. .
This module is described in:
The YaST module
supports authentication at an Active Directory. Additionally, it also supports the following related authentication and identification providers:Support for legacy NSS providers via a proxy. .
FreeIPA and Red Hat Enterprise Identity Management provider. .
An LDAP provider. For more information about configuring LDAP, see
. man 5 sssd-ldap
.
An SSSD-internal provider for local users. .
Relay authentication to another PAM target via a proxy. .
FreeIPA and Red Hat Enterprise Identity Management provider. .
An LDAP provider. .
Kerberos authentication. .
An SSSD-internal provider for local users. .
Disables authentication explicitly. .
To join an Active Directory domain using SSSD and the
module of YaST, proceed as follows:Open YaST.
To be able to use DNS auto-discovery later, set up the Active Directory Domain Controller (the Active Directory server) as the name server for your client.
In YaST, click
.Select
, then enter the IP address of the Active Directory Domain Controller into the text box .Save the setting with
.From the YaST main window, start the module
.The module opens with an overview showing different network properties of your computer and the authentication method currently in use.
To start editing, click
.Now join the domain.
Click
.In the appearing dialog, specify the correct
. Then specify the services to use for identity data and authentication: Select for both.Ensure that
is activated.Click
.(Optional) Usually, you can keep the default settings in the following dialog. However, there are reasons to make changes:
If the Local Host Name Does Not Match the Host Name Set on the
Domain Controller.
Find out if the host name of your computer matches what the name
your computer is known as to the Active Directory Domain Controller. In a
terminal, run the command hostname
, then compare
its output to the configuration of the Active Directory Domain Controller.
If the values differ, specify the host name from the Active Directory configuration under
. Otherwise, leave the appropriate text box empty.If You Do Not Want to Use DNS Auto-Discovery. Specify the that you want to use. If there are multiple Domain Controllers, separate their host names with commas.
To continue, click
.If not all software is installed already, the computer will now install missing software. It will then check whether the configured Active Directory Domain Controller is available.
If everything is correct, the following dialog should now show that it has discovered an
but that you are .
In the dialog, specify the Administrator
).
To make sure that the current domain is enabled for Samba, activate
.To enroll, click
.You should now see a message confirming that you have enrolled successfully. Finish with
.After enrolling, configure the client using the window
.To allow logging in to the computer using login data provided by Active Directory, activate
.(Optional)
Optionally, under ,
activate additional data sources such as information on which users are
allowed to use sudo
or which network drives are
available.
To allow Active Directory users to have home directories, activate
. The path for home directories can be set in multiple ways—on the client, on the server, or both ways:
To configure the home directory paths on the Domain Controller, set
an appropriate value for the attribute
UnixHomeDirectory
for each user. Additionally,
make sure that this attribute replicated to the global catalog. For
information on achieving that under Windows, see
https://support.microsoft.com/en-us/kb/248717.
To configure home directory paths on the client in such a way that
precedence will be given to the path set on the domain controller,
use the option fallback_homedir
.
To configure home directory paths on the client in such a way that
the client setting will override the server setting, use
override_homedir
.
As settings on the Domain Controller are outside of the scope of this documentation, only the configuration of the client-side options will be described in the following.
From the side bar, select
fallback_homedir
or
override_homedir
, then click .
Specify a value. To have home directories follow the format
/home/USER_NAME
, use
/home/%u
.
For more information about possible variables, see the man page
sssd.conf
(man 5 sssd.conf
),
section
override_homedir.
Click
.Save the changes by clicking
. Then make sure that the values displayed now are correct. To leave the dialog, click .
To join an Active Directory domain using winbind
and the
module of YaST, proceed as
follows:
Log in as root
and start YaST.
Start
› .
Enter the domain to join at Figure 7.5, “Determining Windows Domain Membership”). If the DNS settings on your host
are properly integrated with the Windows DNS server, enter the Active Directory
domain name in its DNS format
(mydomain.mycompany.com
). If you enter the short
name of your domain (also known as the pre–Windows 2000 domain
name), YaST must rely on NetBIOS name resolution instead of DNS to
find the correct domain controller.
To use the SMB source for Linux authentication, activate
.To automatically create a local home directory for Active Directory users on the Linux machine, activate
.Check
to allow your domain users to log in even if the Active Directory server is temporarily unavailable, or if you do not have a network connection.To change the UID and GID ranges for the Samba users and groups, select
. Let DHCP retrieve the WINS server only if you need it. This is the case when some machines are resolved only by the WINS system.Configure NTP time synchronization for your Active Directory environment by selecting
and entering an appropriate server name or IP address. This step is obsolete if you have already entered the appropriate settings in the stand-alone YaST NTP configuration module.Click
and confirm the domain join when prompted for it.Provide the password for the Windows administrator on the Active Directory server and click Figure 7.6, “Providing Administrator Credentials”).
(seeAfter you have joined the Active Directory domain, you can log in to it from your workstation using the display manager of your desktop or the console.
Joining a domain may not succeed if the domain name ends with
.local
. Names ending in .local
cause conflicts with Multicast DNS (MDNS) where
.local
is reserved for link-local host names.
Only a domain administrator account, such as
Administrator
, can join openSUSE Leap into Active
Directory.
To check whether you are successfully enrolled in an Active Directory domain, use the following commands:
klist
shows whether the current user has a valid
Kerberos ticket.
getent passwd
shows published LDAP data for all
users.
Provided your machine has been configured to authenticate against Active Directory and you have a valid Windows user identity, you can log in to your machine using the Active Directory credentials. Login is supported for GNOME, the console, SSH, and any other PAM-aware application.
openSUSE Leap supports offline authentication, allowing you to log in to your client machine even when it is offline. See Section 7.2.3, “Offline Service and Policy Support” for details.
To authenticate a GNOME client machine against an Active Directory server, proceed as follows:
Click
.
In the text box DOMAIN_NAME\USER_NAME
.
Enter your Windows password.
If configured to do so, openSUSE Leap creates a user home directory on the local machine on the first login of each user authenticated via Active Directory. This allows you to benefit from the Active Directory support of openSUSE Leap while still having a fully functional Linux machine at your disposal.
Besides logging in to the Active Directory client machine using a graphical front-end, you can log in using the text-based console or even remotely using SSH.
To log in to your Active Directory client from a console, enter
DOMAIN_NAME\USER_NAME
at the login:
prompt and provide the password.
To remotely log in to your Active Directory client machine using SSH, proceed as follows:
At the login prompt, enter:
tux >
ssh DOMAIN_NAME\\USER_NAME@HOST_NAME
The \
domain and login delimiter is escaped with
another \
sign.
Provide the user's password.
openSUSE Leap helps the user choose a suitable new password that meets the corporate security policy. The underlying PAM module retrieves the current password policy settings from the domain controller, informing the user about the specific password quality requirements a user account typically has by means of a message on login. Like its Windows counterpart, openSUSE Leap presents a message describing:
Password history settings
Minimum password length requirements
Minimum password age
Password complexity
The password change process cannot succeed unless all requirements have been successfully met. Feedback about the password status is given both through the display managers and the console.
GDM provides feedback about password expiration and the prompt for new passwords in an interactive mode. To change passwords in the display managers, provide the password information when prompted.
To change your Windows password, you can use the standard Linux utility,
passwd
, instead of having to manipulate this data on
the server. To change your Windows password, proceed as follows:
Log in at the console.
Enter passwd
.
Enter your current password when prompted.
Enter the new password.
Reenter the new password for confirmation. If your new password does not comply with the policies on the Windows server, this feedback is given to you and you are prompted for another password.
To change your Windows password from the GNOME desktop, proceed as follows:
Click the
icon on the left edge of the panel.Select
.From the
section, select › .Enter your old password.
Enter and confirm the new password.
Leave the dialog with
to apply your settings.The YaST module openSUSE Leap. Use it to configure security aspects such as settings for the login procedure and for password creation, for boot permissions, user creation or for default file permissions. Launch it from the YaST control center by › . The dialog always starts with the , and other configuration dialogues are available from the right pane.
offers a central clearinghouse to configure security-related settings for
PolKit (formerly known as PolicyKit) is an application framework that
acts as a negotiator between the unprivileged user session and the
privileged system context. Whenever a process from the user session
tries to carry out an action in the system context, PolKit is queried.
Based on its configuration—specified in a so-called
“policy”—the answer could be “yes”,
“no”, or “needs authentication”. Unlike
classical privilege authorization programs such as sudo, PolKit does
not grant root
permissions to an entire session, but only to
the action in question.
POSIX ACLs (access control lists) can be used as an expansion of the traditional permission concept for file system objects. With ACLs, permissions can be defined more flexibly than with the traditional permission concept.
Encrypting files, partitions, and entire disks prevents unauthorized access to your data and protects your confidential files and documents.
Certificates play an important role in the authentication of companies and individuals. Usually certificates are administered by the application itself. In some cases, it makes sense to share certificates between applications. The certificate store is a common ground for Firefox, Evolution, and NetworkManager. This chapter explains some details.
Securing your systems is a mandatory task for any mission-critical
system administrator. Because it is impossible to always guarantee that
the system is not compromised, it is very important to do extra checks
regularly (for example with
cron
) to ensure that the system
is still under your control. This is where AIDE, the
Advanced Intrusion Detection Environment, comes
into play.
The YaST module openSUSE Leap. Use it to configure security aspects such as settings for the login procedure and for password creation, for boot permissions, user creation or for default file permissions. Launch it from the YaST control center by › . The dialog always starts with the , and other configuration dialogues are available from the right pane.
offers a central clearinghouse to configure security-related settings forThe
displays a comprehensive list of the most important security settings for your system. The security status of each entry in the list is clearly visible. A green check mark indicates a secure setting while a red cross indicates an entry as being insecure. Click to open an overview of the setting and information on how to make it secure. To change a setting, click the corresponding link in the Status column. Depending on the setting, the following entries are available:Click this entry to toggle the status of the setting to either enabled or disabled.
Click this entry to launch another YaST module for configuration. You will return to the Security Overview when leaving the module.
A setting's status is set to unknown when the associated service is not installed. Such a setting does not represent a potential security risk.
openSUSE Leap comes with three . These configurations affect all the settings available in the module. Each configuration can be modified to your needs using the dialogues available from the right pane changing its state to :
A configuration for a workstation with any kind of network connection (including a connection to the Internet).
This setting is designed for a laptop or tablet that connects to different networks.
Security settings designed for a machine providing network services such as a Web server, file server, name server, etc. This set provides the most secure configuration of the predefined settings.
A pre-selected
(when opening the dialog) indicates that one of the predefined sets has been modified. Actively choosing this option does not change the current configuration—you will need to change it using the .Passwords that are easy to guess are a major security issue. The
dialog provides the means to ensure that only secure passwords can be used.By activating this option, a warning will be issued if new passwords appear in a dictionary, or if they are proper names (proper nouns).
If the user chooses a password with a length shorter than specified here, a warning will be issued.
When password expiration is activated (via
), this setting stores the given number of a user's previous passwords, preventing their reuse.Choose a password encryption algorithm. Normally there is no need to change the default (Blowfish).
Activate password expiration by specifying a minimum and a maximum
time limit (in days). By setting the minimum age to a value greater
than 0
days, you can prevent users from immediately
changing their passwords again (and in doing so circumventing the
password expiration). Use the values 0
and
99999
to deactivate password expiration.
When a password expires, the user receives a warning in advance. Specify the number of days prior to the expiration date that the warning should be issued.
Configure which users can shut down the machine via the graphical login manager in this dialog. You can also specify how Ctrl–Alt–Del will be interpreted and who can hibernate the system.
This dialog lets you configure security-related login settings:
To make it difficult to guess a user's password by repeatedly logging in, it is recommended to delay the display of the login prompt that follows an incorrect login. Specify the value in seconds. Make sure that users who have mistyped their passwords do not need to wait too long.
When checked, the graphical login manager (GDM) can be accessed from the network. This is a potential security risk.
Set minimum and maximum values for user and group IDs. These default settings would rarely need to be changed.
Other security settings that do not fit the above-mentioned categories are listed here:
openSUSE Leap comes with three predefined sets of file permissions
for system files. These permission sets define whether a regular user
may read log files or start certain programs.
file permissions are suitable for stand-alone machines. These settings
allow regular users to, for example, read most system files. See the
file /etc/permissions.easy
for the complete
configuration. The file permissions are
designed for multiuser machines with network access. A thorough
explanation of these settings can be found in
/etc/permissions.secure
. The
settings are the most restrictive ones and
should be used with care. See
/etc/permissions.paranoid
for more information.
The program updatedb
scans the system and creates a
database of all file locations which can be queried with the command
locate
. When updatedb
is run as
user nobody, only world-readable files will be added to the database.
When run as user root
, almost all files (except the ones root
is not allowed to read) will be added.
The magic SysRq key is a key combination that enables you to have some control over the system even when it has crashed. The complete documentation can be found at https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html.
PolKit (formerly known as PolicyKit) is an application framework that
acts as a negotiator between the unprivileged user session and the
privileged system context. Whenever a process from the user session
tries to carry out an action in the system context, PolKit is queried.
Based on its configuration—specified in a so-called
“policy”—the answer could be “yes”,
“no”, or “needs authentication”. Unlike
classical privilege authorization programs such as sudo, PolKit does
not grant root
permissions to an entire session, but only to
the action in question.
PolKit works by limiting specific actions by users, by group, or by name. It then defines how those users are allowed to perform this action.
When a user starts a session (using the graphical environment or on the console), each session consists of the authority and an authentication agent. The authority is implemented as a service on the system message bus, whereas the authentication agent is used to authenticate the current user, which started the session. The current user needs to prove their authenticity, for example, using a passphrase.
Each desktop environment has its own authentication agent. Usually it is started automatically, whatever environment you choose.
PolKit's configuration depends on actions and authorization rules:
*.policy
)
Written as XML files and located in
/usr/share/polkit-1/actions
. Each file defines
one or more actions, and each action contains descriptions and
default permissions. Although a system administrator can write their
own rules, PolKit's files must not be edited.
*.rules
)
Written as JavaScript files and located in two places:
/usr/share/polkit-1/rules.d
is used for third
party packages and /etc/polkit-1/rules.d
for
local configurations. Each rule file refers to the action specified
in the action file. A rule determines what restrictions are allowed
to a subset of users. For example, a rule file could overrule a
restrictive permission and allow some users to allow it.
PolKit contains several commands for specific tasks (see also the specific man page for further details):
pkaction
Get details about a defined action. See Section 9.3, “Querying Privileges” for more information.
pkcheck
Checks whether a process is authorized, specified by either
--process
or --system-bus-name
.
pkexec
Allows an authorized user to execute the specific program as another user.
pkttyagent
Starts a textual authentication agent. This agent is used if a desktop environment does not have its own authentication agent.
At the moment, not all applications requiring privileges use PolKit. Find the most important policies available on openSUSE® Leap below, sorted into the categories where they are used.
Set scheduling priorities for the PulseAudio daemon |
Add, remove, edit, enable or disable printers |
Modify schedule |
Modify system and mandatory values with GConf |
Change the system time |
Manage and monitor local virtualized systems |
Apply and modify connections |
Read and change privileges for other users |
Modify defaults |
Update and remove packages |
Change and refresh repositories |
Install local files |
Rollback |
Import repository keys |
Accepting EULAs |
Setting the network proxy |
Wake on LAN |
Mount or unmount fixed, hotpluggable and encrypted devices |
Eject and decrypt removable media |
Enable or disable WLAN |
Enable or disable Bluetooth |
Device access |
Stop, suspend, hibernate and restart the system |
Undock a docking station |
Change power-management settings |
Register product |
Change the system time and language |
Every time a PolKit-enabled process carries out a privileged operation,
PolKit is asked whether this process is entitled to do so. PolKit
answers according to the policy defined for this process. The answers can
be yes
, no
, or
authentication needed
. By default, a policy contains
implicit
privileges, which automatically apply to all
users. It is also possible to specify explicit
privileges which apply to a specific user.
Implicit privileges can be defined for any active and inactive sessions. An active session is the one in which you are currently working. It becomes inactive when you switch to another console for example. When setting implicit privileges to “no”, no user is authorized, whereas “yes” authorizes all users. However, usually it is useful to demand authentication.
A user can either authorize by authenticating as root
or by
authenticating as self. Both authentication methods exist in four
variants:
The user always needs to authenticate.
The authentication is bound to the instance of the program currently running. After the program is restarted, the user is required to authenticate again.
The authentication dialog offers a check button
. If checked, the authentication is valid until the user logs out.The authentication dialog offers a check button
. If checked, the user needs to authenticate only once.Explicit privileges can be granted to specific users. They can either be granted without limitations, or, when using constraints, limited to an active session and/or a local console.
It is not only possible to grant privileges to a user, a user can also be blocked. Blocked users cannot carry out an action requiring authorization, even though the default implicit policy allows authorization by authentication.
Each application supporting PolKit comes with a default set of implicit policies defined by the application's developers. Those policies are the so-called “upstream defaults”. The privileges defined by the upstream defaults are not necessarily the ones that are activated by default on SUSE systems. openSUSE Leap comes with a predefined set of privileges that override the upstream defaults:
/etc/polkit-default-privs.standard
Defines privileges suitable for most desktop systems
/etc/polkit-default-privs.restrictive
Designed for machines administrated centrally
To switch between the two sets of default privileges, adjust the value
of POLKIT_DEFAULT_PRIVS
to either
restrictive
or standard
in
/etc/sysconfig/security
. Then run the command
set_polkit_default_privs
as root
.
Do not modify the two files in the list above. To define your
own custom set of privileges, use
/etc/polkit-default-privs.local
. For details, refer
to
Section 9.4.3, “Modifying Configuration Files for Implicit Privileges”.
To query privileges use the command pkaction
included
in PolKit.
PolKit comes with command line tools for changing privileges and
executing commands as another user (see
Section 9.1.3, “Available Commands” for a short
overview). Each existing policy has a speaking, unique name with which it
can be identified. List all available policies with the command
pkaction
.
When invoked with no parameters, the command pkaction
lists all policies. By adding the
--show-overrides
option, you can list all policies that
differ from the default values. To reset the privileges for a given
action to the (upstream) defaults, use the option
--reset-defaults ACTION
.
See man pkaction
for more information.
If you want to display the needed authorization for a given policy (for
example, org.freedesktop.login1.reboot
) use
pkaction
as follows:
tux >
pkaction -v --action-id org.freedesktop.login1.reboot
org.freedesktop.login1.reboot:
description: Reboot the system
message: Authentication is required to allow rebooting the system
vendor: The systemd Project
vendor_url: http://www.freedesktop.org/wiki/Software/systemd
icon:
implicit any: auth_admin_keep
implicit inactive: auth_admin_keep
implicit active: yes
The keyword auth_admin_keep
means that users need to
enter a passphrase.
pkaction
on openSUSE Leap
pkaction
always operates on the upstream defaults.
Therefore it cannot be used to list or restore the defaults shipped with
openSUSE Leap. To do so, refer to
Section 9.5, “Restoring the Default Privileges”.
Adjusting privileges by modifying configuration files is useful when you want to deploy the same set of policies to different machines, for example to the computers of a specific team. It is possible to change implicit and explicit privileges by modifying configuration files.
The available actions depend on what additional packages you have
installed on your system. For a quick overview, use
pkaction
to list all defined rules.
To get an idea, the following example describes how the command
gparted
(“GNOME Partition Editor”)
is integrated into PolKit.
The file
/usr/share/polkit-1/actions/org.opensuse.policykit.gparted.policy
contains the following content:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"> <policyconfig> 1 <action id="org.opensuse.policykit.gparted"> 2 <message>Authentication is required to run the GParted Partition Editor</message> <icon_name>gparted</icon_name> <defaults> 3 <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> < allow_active>auth_admin</allow_active> </defaults> <annotate 4 key="org.freedesktop.policykit.exec.path">/usr/sbin/gparted</annotate> <annotate 4 key="org.freedesktop.policykit.exec.allow_gui">true</annotate> </action> </policyconfig>
Root element of the policy file. | |
Contains one single action. | |
The | |
The |
To add your own policy, create a .policy
file with
the structure above, add the appropriate value into the
id
attribute, and define the default permissions.
Your own authorization rules overrule the default settings. To add your
own settings, store your files under
/etc/polkit-1/rules.d/
.
The files in this directory start with a two-digit number, followed by a
descriptive name, and end with .rules
. Functions
inside these files are executed in the order they have been sorted in.
For example, 00-foo.rules
is sorted (and hence
executed) before 60-bar.rules
or even
90-default-privs.rules
.
Inside the file, the script checks for the specified action ID, which is
defined in the .policy
file. For example, if you
want to allow the command gparted
to be executed by
any member of the admin
group, check for the action ID
org.opensuse.policykit.gparted
:
/* Allow users in admin group to run GParted without authentication */ polkit.addRule(function(action, subject) { if (action.id == "org.opensuse.policykit.gparted" && subject.isInGroup("admin")) { return polkit.Result.YES; } });
Find the description of all classes and methods of the functions in the PolKit API at http://www.freedesktop.org/software/polkit/docs/latest/ref-api.html.
openSUSE Leap ships with two sets of default authorizations, located
in /etc/polkit-default-privs.standard
and
/etc/polkit-default-privs.restrictive
. For more
information, refer to
Section 9.2.3, “Default Privileges”.
Custom privileges are defined in
/etc/polkit-default-privs.local
. Privileges defined
here will always take precedence over the ones defined in the other
configuration files. To define your custom set of privileges,
do the following:
Open /etc/polkit-default-privs.local
. To define a
privilege, add a line for each policy with the following format:
<privilege_identifier> <any session>:<inactive session>:<active session>
For example:
org.freedesktop.policykit.modify-defaults auth_admin_keep_always
The following values are valid for the SESSION placeholders:
yes
grant privilege
no
block
auth_self
user needs to authenticate with own password every time the privilege is requested
auth_self_keep_session
user needs to authenticate with own password once per session, privilege is granted for the whole session
auth_self_keep_always
user needs to authenticate with own password once, privilege is granted for the current and for future sessions
auth_admin
user needs to authenticate with root
password every time
the privilege is requested
auth_admin_keep_session
user needs to authenticate with root
password once per
session, privilege is granted for the whole session
auth_admin_keep_always
user needs to authenticate with root
password once,
privilege is granted for the current and for future sessions
Run as root
for changes to take effect:
# /sbin/set_polkit_default_privs
Optionally check the list of all privilege identifiers with the
command pkaction
.
openSUSE Leap comes with a predefined set of privileges that is activated by default and thus overrides the upstream defaults. For details, refer to Section 9.2.3, “Default Privileges”.
Since the graphical PolKit tools and the command line tools always
operate on the upstream defaults, openSUSE Leap includes an additional
command-line tool, set_polkit_default_privs
. It resets
privileges to the values defined in
/etc/polkit-default-privs.*
. However, the command
set_polkit_default_privs
will only reset policies that
are set to the upstream defaults.
Make sure /etc/polkit-default-privs.local
does not
contain any overrides of the default policies.
Policies defined in
/etc/polkit-default-privs.local
will be applied
on top of the defaults during the next step.
To reset all policies to the upstream defaults first and then apply the openSUSE Leap defaults:
tux >
sudo
rm -f /var/lib/polkit/* && set_polkit_default_privs
The term POSIX ACL suggests that this is a true POSIX (portable operating system interface) standard. The respective draft standards POSIX 1003.1e and POSIX 1003.2c have been withdrawn for several reasons. Nevertheless, ACLs (as found on many systems belonging to the Unix family) are based on these drafts and the implementation of file system ACLs (as described in this chapter) follows these two standards.
The permissions of all files included in openSUSE Leap are
carefully chosen. When installing additional software or files,
take great care when setting the permissions. Always use the
-l
option with the command ls
to detect any incorrect file permissions immediately. An incorrect
file attribute does not only mean that files could be changed or
deleted. Modified files could be executed by root
or
services could be hijacked by modifying configuration files. This
significantly increases the danger of an attack.
A openSUSE® Leap system includes the files
permissions
,
permissions.easy
,
permissions.secure
, and
permissions.paranoid
, all in the directory
/etc
. The purpose of these files is to define
special permissions, such as world-writable directories or, for
files, the setuser ID bit. Programs with the setuser ID bit set do
not run with the permissions of the user that launched it, but
with the permissions of the file owner, usually root
. An
administrator can use the file
/etc/permissions.local
to add their own
settings.
To define one of the available profiles, select /etc/permissions
or consult
man chmod
.
Find detailed information about the traditional file permissions in the
GNU Coreutils Info page, Node File permissions
(info coreutils "File permissions"
). More advanced
features are the setuid, setgid, and sticky bit.
In certain situations, the access permissions may be too restrictive.
Therefore, Linux has additional settings that enable the temporary
change of the current user and group identity for a specific action. For
example, the passwd
program normally requires root
permissions to access /etc/passwd
. This file
contains some important information, like the home directories of users
and user and group IDs. Thus, a normal user would not be able to change
passwd
, because it would be too dangerous to grant
all users direct access to this file. A possible solution to this
problem is the setuid mechanism. setuid (set user
ID) is a special file attribute that instructs the system to execute
programs marked accordingly under a specific user ID. Consider the
passwd
command:
-rwsr-xr-x 1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd
You can see the s
that denotes that the setuid bit is
set for the user permission. By means of the setuid bit, all users
starting the passwd
command execute it as
root
.
The setuid bit applies to users. However, there is also an equivalent property for groups: the setgid bit. A program for which this bit was set runs under the group ID under which it was saved, no matter which user starts it. Therefore, in a directory with the setgid bit, all newly created files and subdirectories are assigned to the group to which the directory belongs. Consider the following example directory:
drwxrws--- 2 tux archive 48 Nov 19 17:12 backup
You can see the s
that denotes that the setgid bit is
set for the group permission. The owner of the directory and members of
the group archive
may access
this directory. Users that are not members of this group are
“mapped” to the respective group. The effective group ID of
all written files will be
archive
. For example, a
backup program that runs with the group ID
archive
can access
this directory even without root privileges.
There is also the sticky bit. It makes a difference
whether it belongs to an executable program or a directory. If it
belongs to a program, a file marked in this way is loaded to RAM to
avoid needing to get it from the hard disk each time it is used. This
attribute is used rarely, because modern hard disks are fast enough. If
this bit is assigned to a directory, it prevents users from deleting
each other's files. Typical examples include the
/tmp
and /var/tmp
directories:
drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp
Traditionally, three permission sets are defined for each file object on
a Linux system. These sets include the read (r
), write
(w
), and execute (x
) permissions
for each of three types of users—the file owner, the group, and
other users. In addition to that, it is possible to set the set
user id, the set group id, and the
sticky bit. This lean concept is fully adequate for
most practical cases. However, for more complex scenarios or advanced
applications, system administrators formerly needed to use several
workarounds to circumvent the limitations of the traditional permission
concept.
ACLs can be used as an extension of the traditional file permission concept. They allow the assignment of permissions to individual users or groups even if these do not correspond to the original owner or the owning group. Access control lists are a feature of the Linux kernel and are currently supported by Ext2, Ext3, Ext4, JFS, and XFS. Using ACLs, complex scenarios can be realized without implementing complex permission models on the application level.
The advantages of ACLs are evident if you want to replace a Windows
server with a Linux server. Some connected workstations may
continue to run under Windows even after the migration. The Linux system
offers file and print services to the Windows clients with Samba. With
Samba supporting access control lists, user permissions can be configured
both on the Linux server and in Windows with a graphical user interface
(only Windows NT and later). With winbindd
, part of
the Samba suite, it is even possible to assign permissions to users only
existing in the Windows domain without any account on the Linux server.
The conventional POSIX permission concept uses three
classes of users for assigning permissions in the
file system: the owner, the owning group, and other users. Three
permission bits can be set for each user class, giving permission to
read (r
), write (w
), and execute
(x
).
The user and group access permissions for all kinds of file system objects (files and directories) are determined by means of ACLs.
Default ACLs can only be applied to directories. They determine the permissions a file system object inherits from its parent directory when it is created.
Each ACL consists of a set of ACL entries. An ACL entry contains a type, a qualifier for the user or group to which the entry refers, and a set of permissions. For some entry types, the qualifier for the group or users is undefined.
Table 10.1, “ACL Entry Types” summarizes the six possible types of ACL
entries, each defining permissions for a user or a group of users. The
owner entry defines the permissions of the user
owning the file or directory. The owning group entry
defines the permissions of the file's owning group. The superuser can
change the owner or owning group with chown
or
chgrp
, in which case the owner and owning group
entries refer to the new owner and owning group. Each named
user entry defines the permissions of the user specified in
the entry's qualifier field. Each named group entry
defines the permissions of the group specified in the entry's qualifier
field. Only the named user and named group entries have a qualifier field
that is not empty. The other entry defines the
permissions of all other users.
The mask entry further limits the permissions granted by named user, named group, and owning group entries by defining which of the permissions in those entries are effective and which are masked. If permissions exist in one of the mentioned entries and in the mask, they are effective. Permissions contained only in the mask or only in the actual entry are not effective—meaning the permissions are not granted. All permissions defined in the owner and owning group entries are always effective. The example in Table 10.2, “Masking Access Permissions” demonstrates this mechanism.
There are two basic classes of ACLs: A minimum ACL contains only the entries for the types owner, owning group, and other, which correspond to the conventional permission bits for files and directories. An extended ACL goes beyond this. It must contain a mask entry and may contain several entries of the named user and named group types.
Type |
Text Form |
---|---|
owner |
|
named user |
|
owning group |
|
named group |
|
mask |
|
other |
|
Entry Type |
Text Form |
Permissions |
---|---|---|
named user |
|
|
mask |
|
|
effective permissions: |
|
Figure 10.1, “Minimum ACL: ACL Entries Compared to Permission Bits” and
Figure 10.2, “Extended ACL: ACL Entries Compared to Permission Bits” illustrate the two cases of a minimum
ACL and an extended ACL. The figures are structured in three
blocks—the left block shows the type specifications of the ACL
entries, the center block displays an example ACL, and the right block
shows the respective permission bits according to the conventional
permission concept (for example, as displayed by ls
-l
). In both cases, the owner
class permissions are mapped to the ACL entry owner.
Other class permissions are mapped to the
respective ACL entry. However, the mapping of the group
class permissions is different in the two cases.
In the case of a minimum ACL—without mask—the group class permissions are mapped to the ACL entry owning group. This is shown in Figure 10.1, “Minimum ACL: ACL Entries Compared to Permission Bits”. In the case of an extended ACL—with mask—the group class permissions are mapped to the mask entry. This is shown in Figure 10.2, “Extended ACL: ACL Entries Compared to Permission Bits”.
This mapping approach ensures the smooth interaction of applications, regardless of whether they have ACL support. The access permissions that were assigned by means of the permission bits represent the upper limit for all other “fine adjustments” made with an ACL. Changes made to the permission bits are reflected by the ACL and vice versa.
With getfacl
and setfacl
on the
command line, you can access ACLs. The usage of these commands is
demonstrated in the following example.
Before creating the directory, use the umask
command
to define which access permissions should be masked each time a file
object is created. The command umask
027
sets the default permissions by giving the owner
the full range of permissions (0
), denying the group
write access (2
), and giving other users no
permissions (7
). umask
actually masks the corresponding permission bits or turns them off. For
details, consult the umask
man page.
mkdir mydir
creates the mydir
directory with the default permissions as set by
umask
. Use ls
-dl
mydir
to check whether all permissions were assigned correctly.
The output for this example is:
drwxr-x--- ... tux project3 ... mydir
With getfacl
mydir
, check the
initial state of the ACL. This gives information like:
# file: mydir # owner: tux # group: project3 user::rwx group::r-x other::---
The first three output lines display the name, owner, and
owning group of the directory. The next three lines contain the three
ACL entries owner, owning group, and other. In fact, in the case of this
minimum ACL, the getfacl
command does not produce any
information you could not have obtained with ls
.
Modify the ACL to assign read, write, and execute permissions to an
additional user geeko
and an additional group
mascots
with:
root #
setfacl -m user:geeko:rwx,group:mascots:rwx mydir
The option -m
prompts setfacl
to
modify the existing ACL. The following argument indicates the ACL
entries to modify (multiple entries are separated by commas). The final
part specifies the name of the directory to which these modifications
should be applied. Use the getfacl
command to take a
look at the resulting ACL.
# file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx group::r-x group:mascots:rwx mask::rwx other::---
In addition to the entries initiated for the user
geeko
and the group mascots
, a
mask entry has been generated. This mask entry is set automatically so
that all permissions are effective. setfacl
automatically adapts existing mask entries to the settings modified,
unless you deactivate this feature with -n
. The mask
entry defines the maximum effective access permissions for all entries
in the group class. This includes named user, named group, and owning
group. The group class permission bits displayed by
ls
-dl mydir
now correspond to the
mask
entry.
drwxrwx---+ ... tux project3 ... mydir
The first column of the output contains an additional
+
to indicate that there is an
extended ACL for this item.
According to the output of the ls
command, the
permissions for the mask entry include write access. Traditionally, such
permission bits would mean that the owning group (here
project3
) also has write access to the directory
mydir
.
However, the effective access permissions for the owning group
correspond to the overlapping portion of the permissions defined for the
owning group and for the mask—which is r-x
in our example (see Table 10.2, “Masking Access Permissions”). As far as the effective
permissions of the owning group in this example are concerned, nothing
has changed even after the addition of the ACL entries.
Edit the mask entry with setfacl
or
chmod
. For example, use chmod
g-w mydir
. ls
-dl
mydir
then shows:
drwxr-x---+ ... tux project3 ... mydir
getfacl
mydir
provides the following
output:
# file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx # effective: r-x group::r-x group:mascots:rwx # effective: r-x mask::r-x other::---
After executing chmod
to remove the write
permission from the group class bits, the output of
ls
is sufficient to see that the mask bits
must have changed accordingly: write permission is again limited to the
owner of mydir
. The output of the
getfacl
confirms this. This output includes a comment
for all those entries in which the effective permission bits do not
correspond to the original permissions, because they are filtered
according to the mask entry. The original permissions can be restored at
any time with chmod g+w mydir
.
Directories can have a default ACL, which is a special kind of ACL defining the access permissions that objects in the directory inherit when they are created. A default ACL affects both subdirectories and files.
There are two ways in which the permissions of a directory's default ACL are passed to the files and subdirectories:
A subdirectory inherits the default ACL of the parent directory both as its default ACL and as an ACL.
A file inherits the default ACL as its ACL.
All system calls that create file system objects use a
mode
parameter that defines the access permissions
for the newly created file system object. If the parent directory does
not have a default ACL, the permission bits as defined by the
umask
are subtracted from the permissions as passed
by the mode
parameter, with the result being
assigned to the new object. If a default ACL exists for the parent
directory, the permission bits assigned to the new object correspond to
the overlapping portion of the permissions of the
mode
parameter and those that are defined in the
default ACL. The umask
is disregarded in this case.
The following three examples show the main operations for directories and default ACLs:
Add a default ACL to the existing directory
mydir
with:
tux >
setfacl -d -m group:mascots:r-x mydir
The option -d
of the setfacl
command prompts setfacl
to perform the following
modifications (option -m
) in the default ACL.
Take a closer look at the result of this command:
tux >
getfacl mydir
# file: mydir
# owner: tux
# group: project3
user::rwx
user:geeko:rwx
group::r-x
group:mascots:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:mascots:r-x
default:mask::r-x
default:other::---
getfacl
returns both the ACL and the default ACL.
The default ACL is formed by all lines that start with
default
. Although you merely executed the
setfacl
command with an entry for the
mascots
group for the default ACL,
setfacl
automatically copied all other entries
from the ACL to create a valid default ACL. Default ACLs do not have
an immediate effect on access permissions. They only come into play
when file system objects are created. These new objects inherit
permissions only from the default ACL of their parent directory.
In the next example, use mkdir
to create a
subdirectory in mydir
, which inherits the
default ACL.
tux >
mkdir mydir/mysubdir
getfacl mydir/mysubdir
# file: mydir/mysubdir
# owner: tux
# group: project3
user::rwx
group::r-x
group:mascots:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:mascots:r-x
default:mask::r-x
default:other::---
As expected, the newly-created subdirectory
mysubdir
has the permissions from the default
ACL of the parent directory. The ACL of mysubdir
is an exact reflection of the default ACL of
mydir
. The default ACL that this directory will
hand down to its subordinate objects is also the same.
Use touch
to create a file in the
mydir
directory, for example,
touch
mydir/myfile
.
ls
-l mydir/myfile
then shows:
-rw-r-----+ ... tux project3 ... mydir/myfile
The output of getfacl
mydir/myfile
is:
# file: mydir/myfile # owner: tux # group: project3 user::rw- group::r-x # effective:r-- group:mascots:r-x # effective:r-- mask::r-- other::---
touch
uses a mode
with the
value 0666
when creating new files, which means
that the files are created with read and write permissions for all
user classes, provided no other restrictions exist in
umask
or in the default ACL (see
Section 10.4.3.1, “Effects of a Default ACL”). In effect,
this means that all access permissions not contained in the
mode
value are removed from the respective ACL
entries. Although no permissions were removed from the ACL entry of
the group class, the mask entry was modified to mask permissions not
set in mode
.
This approach ensures the smooth interaction of applications (such as
compilers) with ACLs. You can create files with restricted access
permissions and subsequently mark them as executable. The
mask
mechanism guarantees that the right users and
groups can execute them as desired.
A check algorithm is applied before any process or application is granted access to an ACL-protected file system object. As a basic rule, the ACL entries are examined in the following sequence: owner, named user, owning group or named group, and other. The access is handled in accordance with the entry that best suits the process. Permissions do not accumulate.
Things are more complicated if a process belongs to more than one group and would potentially suit several group entries. An entry is randomly selected from the suitable entries with the required permissions. It is irrelevant which of the entries triggers the final result “access granted”. Likewise, if none of the suitable group entries contain the required permissions, a randomly selected entry triggers the final result “access denied”.
ACLs can be used to implement very complex permission scenarios that meet
the requirements of modern applications. The traditional permission
concept and ACLs can be combined in a smart manner. The basic file
commands (cp
, mv
,
ls
, etc.) support ACLs, as do Samba and Nautilus.
Vi/Vim and emacs both fully support ACLs by preserving the permissions on
writing files including backups. Unfortunately, many other editors and file
managers still lack ACL support. When modifying files with an editor, the
ACLs of files are sometimes preserved and sometimes not, depending on the
backup mode of the editor used. If the editor writes the changes to the
original file, the ACL is preserved. If the editor saves the updated
contents to a new file that is subsequently renamed to the old file name,
the ACLs may be lost, unless the editor supports ACLs. Except for the
star
archiver, there are currently no backup applications
that preserve ACLs.
For more information about ACLs, see the man pages for
getfacl(1)
, acl(5)
, and
setfacl(1)
.
Encrypting files, partitions, and entire disks prevents unauthorized access to your data and protects your confidential files and documents.
You can choose between the following encryption options:
It is possible to create an encrypted partition with YaST during installation or in an already installed system. For further info, see Section 11.1.1, “Creating an Encrypted Partition during Installation” and Section 11.1.2, “Creating an Encrypted Partition on a Running System”. This option can also be used for removable media, such as external hard disks, as described in Section 11.1.4, “Encrypting the Content of Removable Media”.
You can create a file-based encrypted virtual disk on your hard disk or a removable medium with YaST. The encrypted virtual disk can then be used as a regular folder for storing files or directories. For more information, refer to Section 11.1.3, “Creating an Encrypted Virtual Disk”.
To quickly encrypt one or more files, you can use the GPG tool. See Section 11.2, “Encrypting Files with GPG” for more information.
Encryption methods described in this chapter cannot protect your running system from being compromised. After the encrypted volume is successfully mounted, everybody with appropriate permissions can access it. However, encrypted media are useful in case of loss or theft of your computer, or to prevent unauthorized individuals from reading your confidential data.
Use YaST to encrypt partitions or parts of your file system during installation or in an already installed system. However, encrypting a partition in an already-installed system is more difficult, because you need to resize and change existing partitions. In such cases, it may be more convenient to create an encrypted file of a defined size, in which to store other files or parts of your file system. To encrypt an entire partition, dedicate a partition for encryption in the partition layout. The standard partitioning proposal, as suggested by YaST, does not include an encrypted partition by default. Add an encrypted partition manually in the partitioning dialog.
Make sure to memorize the password for your encrypted partitions well. Without that password, you cannot access or restore the encrypted data.
The YaST expert dialog for partitioning offers the options needed for creating an encrypted partition. To create a new encrypted partition proceed as follows:
Run the YaST Expert Partitioner with
› .Select a hard disk, click
, and select a primary or an extended partition.Select the partition size or the region to use on the disk.
Select the file system, and mount point of this partition.
Activate the
check box.After checking
, a pop-up window asking for installing additional software may appear. Confirm to install all the required packages to ensure that the encrypted partition works well.If the encrypted file system needs to be mounted only when necessary, enable
in the . otherwise enable and enter the mount point.Click
and enter a password which is used to encrypt this partition. This password is not displayed. To prevent typing errors, you need to enter the password twice.Complete the process by clicking
. The newly-encrypted partition is now created.
During the boot process, the operating system asks for the password
before mounting any encrypted partition which is set to be auto-mounted
in /etc/fstab
. Such a partition is then available
to all users when it has been mounted.
To skip mounting the encrypted partition during start-up, press Enter when prompted for the password. Then decline the offer to enter the password again. In this case, the encrypted file system is not mounted and the operating system continues booting, blocking access to your data.
To mount an encrypted partition which is not mounted during the boot process, open a file manager and click the partition entry in the pane listing common places on your file system. You will be prompted for a password and the partition will be mounted.
When you are installing your system on a machine where partitions already exist, you can also decide to encrypt an existing partition during installation. In this case follow the description in Section 11.1.2, “Creating an Encrypted Partition on a Running System” and be aware that this action destroys all data on the existing partition.
It is also possible to create encrypted partitions on a running system. However, encrypting an existing partition destroys all data on it, and requires re-sizing and restructuring of existing partitions.
On a running system, select Section 11.1.1, “Creating an Encrypted Partition during Installation”.
› in the YaST control center. Click to proceed. In the , select the partition to encrypt and click . The rest of the procedure is the same as described inInstead of encrypting an entire disk or partition, you can use YaST to set up a file-based encrypted virtual disk. It will appear as a regular file in the file system, but can be mounted and used like a regular folder. Unlike encrypted partitions, encrypted virtual disks can be created without re-partitioning the hard disk.
To set up an encrypted virtual disk, you need to create an empty
file first. This file is called a loop file and is going to contain
the encrypted data. In the terminal, switch to the desired
directory and run the touch
LOOP_FILE
command (where
LOOP_FILE is the desired name, for
example: secret
). We recommend to create an
empty directory that will act as a mount point for the encrypted
virtual disk. To do this, use the mkdir
MOUNT_DIR
command (replace
MOUNT_DIR with the actual path and
directory name, for example ~/my_docs
).
LOOP_FILE must reside outside of
MOUNT_DIR.
To set up an encrypted virtual disk, launch YaST, switch to the
~/my_docs
). Make sure that the
option is enabled and press
. Provide the desired password and press
.
YaST changes the owner of the mount point to root
by
default. If the content should be accessible to other users, change
the group and permissions, for example with chgrp users
MOUNT_DIR
and chmod
775 MOUNT_DIR
.
YaST treats removable media (like external hard disks or flash disks) the same as any other storage device. Virtual disks or partitions on external media can be encrypted as described above. However, you should disable mounting at boot time, because removable media is usually connected only when the system is up and running.
If you encrypted your removable device with YaST, the GNOME desktop
automatically recognizes the encrypted partition and prompts for the
password when the device is detected. If you plug in a FAT-formatted
removable device when running GNOME, the desktop user entering the
password automatically becomes the owner of the device.
For devices with a file system other than FAT, change the
ownership explicitly for users other than root
to give them
read-write access to the device.
If you have created a virtual disk as described in Section 11.1.3, “Creating an Encrypted Virtual Disk” but with the loop file on a removable disk, then you need to mount the file manually as follows:
tux >
sudo
cryptsetup luksOpen FILE NAME sudo mount /dev/mapper/NAME DIR
In the commands above, FILE refers to the path to the loop file, NAME is a user-defined name, and DIR is the path to the mount point. For example:
tux >
sudo
cryptsetup luksOpen /run/media/tux/usbstick/secret my_secrettux >
sudo
mount /dev/mapper/my_secret /home/tux/my_docs
The GPG encryption software can be used to encrypt individual files and documents.
To encrypt a file with GPG, you need to generate a key pair first. To do
this, run the gpg --gen-key
and follow the on-screen
instructions. When generating the key pair, GPG creates a user ID (UID) to
identify the key based on your real name, comments, and email address. You
need this UID (or just a part of it like your first name or email address)
to specify the key you want to use to encrypt a file. To find the UID of an
existing key, use the gpg --list-keys
command. To encrypt
a file use the following command:
tux >
gpg -e -r UID
FILE
Replace UID with part of the UID (for example, your first name) and FILE with the file you want to encrypt. For example:
tux >
gpg -e -r Tux secret.txt
This command creates an encrypted version of the specified file
recognizable by the .gpg
file extension (in
this example, it is secret.txt.gpg
).
To decrypt an encrypted file, use the following command:
tux >
gpg -d -o DECRYPTED_FILE
ENCRYPTED_FILE
Replace DECRYPTED_FILE with the desired name for the decrypted file and ENCRYPTED_FILE with the encrypted file you want to decrypt.
Keep in mind that the encrypted file can be only decrypted using the same key that was used for encryption. If you want to share an encrypted file with another person, you have to use that person's public key to encrypt the file.
Certificates play an important role in the authentication of companies and individuals. Usually certificates are administered by the application itself. In some cases, it makes sense to share certificates between applications. The certificate store is a common ground for Firefox, Evolution, and NetworkManager. This chapter explains some details.
The certificate store is a common database for Firefox, Evolution, and NetworkManager at the moment. Other applications that use certificates are not covered but may be in the future. If you have such an application, you can continue to use its private, separate configuration.
The configuration is mostly done in the background. To activate it, proceed as follows:
Decide if you want to activate the certificate store globally (for every user on your system) or specifically to a certain user:
For every user.
Use the file /etc/profile.local
For a specific user.
Use the file ~/.bashrc
Open the file from the previous step and insert the following line:
export NSS_USE_SHARED_DB=1
Save the file
Log out of and log in to your desktop.
All the certificates are stored under
$HOME/.local/var/pki/nssdb/
.
To import a certificate into the certificate store, do the following:
Start Firefox.
Open the dialog from
› . Change to › and click .Import your certificate depending on your type: use
to import server certificate, to identify other, and to identify yourself.
Securing your systems is a mandatory task for any mission-critical
system administrator. Because it is impossible to always guarantee that
the system is not compromised, it is very important to do extra checks
regularly (for example with
cron
) to ensure that the system
is still under your control. This is where AIDE, the
Advanced Intrusion Detection Environment, comes
into play.
An easy check that often can reveal unwanted changes can be done by means
of RPM. The package manager has a built-in verify function that checks
all the managed files in the system for changes. To verify of all files,
run the command rpm -Va
. However, this command will
also display changes in configuration files and you will need to do some
filtering to detect important changes.
An additional problem to the method with RPM is that an intelligent
attacker will modify rpm
itself to hide any changes
that might have been done by some kind of root-kit which allows the
attacker to mask its intrusion and gain root privilege. To solve this,
you should implement a secondary check that can also be run completely
independent of the installed system.
Before you install your system, verify the checksum of your medium (see Book “Start-Up”, Chapter 4 “Troubleshooting”, Section 4.1 “Checking Media”) to make sure you do not use a compromised source. After you have installed the system, initialize the AIDE database. To make sure that all went well during and after the installation, do an installation directly on the console, without any network attached to the computer. Do not leave the computer unattended or connected to any network before AIDE creates its database.
AIDE is not installed by default on openSUSE Leap. To install it,
either use › , or enter zypper install
aide
on the command line as root
.
To tell AIDE which attributes of which files should be checked, use
the /etc/aide.conf
configuration file. It must be
modified to become the actual configuration. The first section handles
general parameters like the location of the AIDE database file. More
relevant for local configurations are the Custom
Rules
and the Directories and Files
sections. A typical rule looks like the following:
Binlib = p+i+n+u+g+s+b+m+c+md5+sha1
After defining the variable Binlib
, the respective
check boxes are used in the files section. Important options include the
following:
Option |
Description |
---|---|
p |
Check for the file permissions of the selected files or directories. |
i |
Check for the inode number. Every file name has a unique inode number that should not change. |
n |
Check for the number of links pointing to the relevant file. |
u |
Check if the owner of the file has changed. |
g |
Check if the group of the file has changed. |
s |
Check if the file size has changed. |
b |
Check if the block count used by the file has changed. |
m |
Check if the modification time of the file has changed. |
c |
Check if the files access time has changed. |
S |
Check for a changed file size. |
I |
Ignore changes of the file name. |
md5 |
Check if the md5 checksum of the file has changed. We recommend to use sha256 or sha512. |
sha1 |
Check if the sha1 (160 Bit) checksum of the file has changed. We recommend to use sha256 or sha512. |
sha256 |
Check if the sha256 checksum of the file has changed. |
sha512 |
Check if the sha512 checksum of the file has changed. |
This is a configuration that checks for all files in
/sbin
with the options defined in
Binlib
but omits the
/sbin/conf.d/
directory:
/sbin Binlib !/sbin/conf.d
To create the AIDE database, proceed as follows:
Open /etc/aide.conf
.
Define which files should be checked with which check boxes. For a
complete list of available check boxes, see
/usr/share/doc/packages/aide/manual.html
. The
definition of the file selection needs some knowledge about regular
expressions. Save your modifications.
To check whether the configuration file is valid, run:
root #
aide --config-check
Any output of this command is a hint that the configuration is not valid. For example, if you get the following output:
root #
aide --config-check
35:syntax error:!
35:Error while reading configuration:!
Configuration error
The error is to be expected in line 36 of
/etc/aide.conf
. Note that the error message
contains the last successfully read line of the configuration file.
Initialize the AIDE database. Run the command:
root #
aide -i
Copy the generated database to a save location like a CD-R or DVD-R, a remote server or a flash disk for later use.
This step is essential as it avoids compromising your database. It is recommended to use a medium which can be written only once to prevent the database being modified. Never leave the database on the computer which you want to monitor.
To perform a file system check, proceed as follows:
Rename the database:
root #
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
After any configuration change, you always need to re-initialize the AIDE database and subsequently move the newly generated database. It is also a good idea to make a backup of this database. See Section 13.2, “Setting Up an AIDE Database” for more information.
Perform the check with the following command:
root #
aide --check
If the output is empty, everything is fine. If AIDE found changes, it displays a summary of changes, for example:
root #
aide --check
AIDE found differences between database and filesystem!!
Summary:
Total number of files: 1992
Added files: 0
Removed files: 0
Changed files: 1
To learn about the actual changes, increase the verbose level of the
check with the parameter -V
. For the previous example,
this could look like the following:
root #
aide --check -V
AIDE found differences between database and filesystem!!
Start timestamp: 2009-02-18 15:14:10
Summary:
Total number of files: 1992
Added files: 0
Removed files: 0
Changed files: 1
---------------------------------------------------
Changed files:
---------------------------------------------------
changed: /etc/passwd
--------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /etc/passwd
Mtime : 2009-02-18 15:11:02 , 2009-02-18 15:11:47
Ctime : 2009-02-18 15:11:02 , 2009-02-18 15:11:47
In this example, the file /etc/passwd
was touched to
demonstrate the effect.
To avoid risk, it is advisable to also run the AIDE binary from a trusted source. This excludes the risk that some attacker also modified the aide binary to hide its traces.
To accomplish this task, AIDE must be run from a rescue system that is independent of the installed system. With openSUSE Leap it is relatively easy to extend the rescue system with arbitrary programs, and thus add the needed functionality.
Before you can start using the rescue system, you need to provide two packages to the system. These are included with the same syntax as you would add a driver update disk to the system. For a detailed description about the possibilities of linuxrc that are used for this purpose, see http://en.opensuse.org/SDB:Linuxrc. In the following, one possible way to accomplish this task is discussed.
Provide an FTP server as a second machine.
Copy the packages aide
and
mhash
to the FTP server directory, in our case
/srv/ftp/
. Replace the placeholders
ARCH and VERSION
with the corresponding values:
root #
cp DVD1/suse/ARCH/aideVERSION.ARCH.rpm /srv/ftproot #
cp DVD1/suse/ARCH/mhashVERSION.ARCH.rpm /srv/ftp
Create an info file /srv/ftp/info.txt
that
provides the needed boot parameters for the rescue system:
dud:ftp://ftp.example.com/aideVERSION.ARCH.rpm dud:ftp://ftp.example.com/mhashVERSION.ARCH.rpm
Replace your FTP domain name, VERSION and ARCH with the values used on your system.
Restart the server that needs to go through an AIDE check with the Rescue system from your DVD. Add the following string to the boot parameters:
info=ftp://ftp.example.com/info.txt
This parameter tells linuxrc
to also read in all
information from the info.txt
file.
After the rescue system has booted, the AIDE program is ready for use.
Information about AIDE is available at the following places:
The home page of AIDE: http://aide.sourceforge.net
In the documented template configuration
/etc/aide.conf
.
In several files below
/usr/share/doc/packages/aide
after installing the
aide
package.
On the AIDE user mailing list at https://www.ipi.fi/mailman/listinfo/aide.
As mentioned at the beginning, network transparency is one of the central characteristics of a Unix system. X, the windowing system of Unix operating systems, can use this feature in an impressive way. With X, it is no problem to log in to a remote host and start a graphical program that is then sen…
In networked environments, it is often necessary to access hosts from a
remote location. If a user sends login and password strings for
authentication purposes as plain text, they could be intercepted and
misused to gain access to that user account. This would open all the user's files to an attacker
and the illegal account could be used to obtain administrator or
root
access, or to penetrate
other systems. In the past, remote connections were established with
telnet
, rsh
or
rlogin
, which offered no guards against eavesdropping
in the form of encryption or other security mechanisms. There are other
unprotected communication channels, like the traditional FTP protocol
and some remote copying programs like rcp
.
Whenever Linux is used in a network environment, you can use the kernel functions that allow the manipulation of network packets to maintain a separation between internal and external network areas. The Linux netfilter framework provides the means to establish an effective firewall that keeps differ…
Today, Internet connections are cheap and available almost everywhere. However, not all connections are secure. Using a Virtual Private Network (VPN), you can create a secure network within an insecure network such as the Internet or Wi-Fi. It can be implemented in different ways and serves several purposes. In this chapter, we focus on the OpenVPN implementation to link branch offices via secure wide area networks (WANs).
An increasing number of authentication mechanisms are based on cryptographic procedures. Digital certificates that assign cryptographic keys to their owners play an important role in this context. These certificates are used for communication and can also be found, for example, on company ID cards. The generation and administration of certificates is mostly handled by official institutions that offer this as a commercial service. In some cases, however, it may make sense to carry out these tasks yourself. For example, if a company does not want to pass personal data to third parties.
YaST provides two modules for certification, which offer basic management functions for digital X.509 certificates. The following sections explain the basics of digital certification and how to use YaST to create and administer certificates of this type.
As mentioned at the beginning, network transparency is one of the central characteristics of a Unix system. X, the windowing system of Unix operating systems, can use this feature in an impressive way. With X, it is no problem to log in to a remote host and start a graphical program that is then sent over the network to be displayed on your computer.
When an X client needs to be displayed remotely using an X server,
the latter should protect the resource managed by it (the display)
from unauthorized access. In more concrete terms, certain permissions
must be given to the client program. With the X Window System, there
are two ways to do this, called host-based access control and
cookie-based access control. The former relies on the IP address of
the host where the client should run. The program to control this is
xhost
. xhost
enters the IP
address of a legitimate client into a database belonging to the X
server. However, relying on IP addresses for authentication is not
very secure. For example, if there were a second user working on the
host sending the client program, that user would have access to the X
server as well—like someone spoofing the IP address. Because of
these shortcomings, this authentication method is not described in
more detail here, but you can learn about it with
man
xhost
.
In the case of cookie-based access control, a character string is
generated that is only known to the X server and to the legitimate
user, like an ID card of some kind. This cookie is stored on login in
the file .Xauthority
in the user's home directory
and is available to any X client wanting to use the X server to display
a window. The file .Xauthority
can be examined by
the user with the tool xauth
. If you rename
.Xauthority
, or if you delete the file from your
home directory by accident, you will not be able to open any new
windows or X clients.
SSH (secure shell) can be used to encrypt a network connection and forward it to an X server transparently. This is also called X forwarding. X forwarding is achieved by simulating an X server on the server side and setting a DISPLAY variable for the shell on the remote host. Further details about SSH can be found in Chapter 15, SSH: Secure Network Operations.
If you do not consider the computer where you log in to be a secure host, do not use X forwarding. If X forwarding is enabled, an attacker could authenticate via your SSH connection. The attacker could then intrude on your X server and, for example, read your keyboard input.
In networked environments, it is often necessary to access hosts from a
remote location. If a user sends login and password strings for
authentication purposes as plain text, they could be intercepted and
misused to gain access to that user account. This would open all the user's files to an attacker
and the illegal account could be used to obtain administrator or
root
access, or to penetrate
other systems. In the past, remote connections were established with
telnet
, rsh
or
rlogin
, which offered no guards against eavesdropping
in the form of encryption or other security mechanisms. There are other
unprotected communication channels, like the traditional FTP protocol
and some remote copying programs like rcp
.
The SSH suite provides the necessary protection by encrypting the authentication strings (usually a login name and a password) and all the other data exchanged between the hosts. With SSH, the data flow could still be recorded by a third party, but the contents are encrypted and cannot be reverted to plain text unless the encryption key is known. So SSH enables secure communication over insecure networks, such as the Internet. The SSH implementation coming with openSUSE Leap is OpenSSH.
openSUSE Leap installs the OpenSSH package by default providing the
commands ssh
, scp
, and
sftp
. In the default configuration, remote access of a
openSUSE Leap system is only possible with the OpenSSH utilities, and
only if the sshd
is running and
the firewall permits access.
SSH on openSUSE Leap uses cryptographic hardware acceleration if available. As a result, the transfer of large quantities of data through an SSH connection is considerably faster than without cryptographic hardware. As an additional benefit, the CPU will see a significant reduction in load.
ssh
—Secure Shell #
With ssh
it is possible to log in to remote
systems and to work interactively. To log in to the host
sun
as user tux
enter one of
the following commands:
tux >
ssh tux@suntux >
ssh -l tux sun
If the user name is the same on both machines, you can omit it. Using
ssh sun
is sufficient. The remote host
prompts for the remote user's password. After a successful
authentication, you can work on the remote command line or use
interactive applications, such as YaST in text mode.
Furthermore, ssh
offers the possibility to run
non-interactive commands on remote systems using ssh
HOST COMMAND.
COMMAND needs to be properly quoted. Multiple
commands can be concatenated as on a local shell.
tux >
ssh root@sun "dmesg -T | tail -n 25"tux >
ssh root@sun "cat /etc/issue && uptime"
SSH also simplifies the use of remote X applications. If you run
ssh
with the -X
option, the
DISPLAY
variable is automatically set on the remote
machine and all X output is exported to the local machine over the
existing SSH connection. At the same time, X applications started
remotely cannot be intercepted by unauthorized individuals.
By adding the -A
option, the ssh-agent authentication
mechanism is carried over to the next machine. This way, you can work
from different machines without having to enter a password, but only if
you have distributed your public key to the destination hosts and
properly saved it there. Refer to
Section 15.5.2, “Copying an SSH Key” for details.
This mechanism is deactivated in the default settings, but can be
permanently activated at any time in the system wide configuration file
/etc/ssh/sshd_config
by setting
AllowAgentForwarding yes
.
scp
—Secure Copy #
scp
copies files to or from a remote machine. If
the user name on jupiter is different than the user name on
sun, specify the latter using the
USER_NAME@host
format. If
the file should be copied into a directory other than the remote
user's home directory, specify it as
sun:DIRECTORY. The following
examples show how to copy a file from a local to a remote machine and
vice versa.
tux >
scp ~/MyLetter.tex tux@sun:/tmp 1tux >
scp tux@sun:/tmp/MyLetter.tex ~ 2
-l
Option
With the ssh
command, the option
-l
can be used to specify a remote user (as an
alternative to the
USER_NAME@host
format). With scp
the option -l
is used to limit the bandwidth consumed by scp
.
After the correct password is entered, scp
starts the
data transfer. It displays a progress bar and the time remaining for each
file that is copied. Suppress all output with the -q
option.
scp
also provides a recursive copying feature for
entire directories. The command
tux >
scp -r src/ sun:backup/
copies the entire contents of the directory src
including all subdirectories to the ~/backup
directory on the host sun. If this subdirectory does not
exist, it is created automatically.
The -p
option tells scp
to leave the
time stamp of files unchanged. -C
compresses the data
transfer. This minimizes the data volume to transfer, but creates a
heavier burden on the processors of both machines.
sftp
—Secure File Transfer #sftp
#
If you want to copy several files from or to different locations,
sftp
is a convenient alternative to
scp
. It opens a shell with a set of commands similar
to a regular FTP shell. Type help
at the sftp-prompt
to get a list of available commands. More details are available from the
sftp
man page.
tux >
sftp sun
Enter passphrase for key '/home/tux/.ssh/id_rsa':
Connected to sun.
sftp> help
Available commands:
bye Quit sftp
cd path Change remote directory to 'path'
[...]
As with a regular FTP server, a user cannot only download,
but also upload files to a remote machine running an SFTP server
by using the put
command. By default the
files will be uploaded to the remote host with the same
permissions as on the local host. There are two options to
automatically alter these permissions:
A umask works as a filter against the permissions of the original file on the local host. It can only withdraw permissions:
permissions original |
umask |
permissions uploaded |
---|---|---|
0666 |
0002 |
0664 |
0600 |
0002 |
0600 |
0775 |
0025 |
0750 |
To apply a umask on an SFTP server, edit the file
/etc/ssh/sshd_configuration
. Search for the line
beginning with Subsystem sftp
and add the
-u
parameter with the desired setting, for example:
Subsystem sftp /usr/lib/ssh/sftp-server -u 0002
Explicitly setting the permissions sets the same permissions for all
files uploaded via SFTP. Specify a three-digit pattern such as
600
, 644
, or
755
with -u
. When both
-m
and -u
are specified,
-u
is ignored.
To apply explicit permissions for uploaded files on an SFTP server,
edit the file /etc/ssh/sshd_configuration
.
Search for the line beginning with Subsystem sftp
and add the -m
parameter with the desired setting,
for example:
Subsystem sftp /usr/lib/ssh/sftp-server -m 600
sshd
) #
To work with the SSH client programs ssh
and
scp
, a server (the SSH daemon) must be running in the
background, listening for connections on TCP/IP port
22
. The daemon generates three key pairs when starting for the
first time. Each key pair consists of a private and a public key.
Therefore, this procedure is called public key-based. To
guarantee the security of the communication via SSH, access to the
private key files must be restricted to the system administrator. The
file permissions are set accordingly by the default installation. The
private keys are only required locally by the SSH daemon and must not be
given to anyone else. The public key components (recognizable by the name
extension .pub
) are sent to the client requesting
the connection. They are readable for all users.
A connection is initiated by the SSH client. The waiting SSH daemon and the requesting SSH client exchange identification data to compare the protocol and software versions, and to prevent connections through the wrong port. Because a child process of the original SSH daemon replies to the request, several SSH connections can be made simultaneously.
For the communication between SSH server and SSH client, OpenSSH supports
versions 1 and 2 of the SSH protocol. Version 2 of the
SSH protocol is used by default. Override this to use version 1
of protocol with the -1
option.
When using version 1 of SSH, the server sends its public host key and a server key, which is regenerated by the SSH daemon every hour. Both allow the SSH client to encrypt a freely chosen session key, which is sent to the SSH server. The SSH client also tells the server which encryption method (cipher) to use. Version 2 of the SSH protocol does not require a server key. Both sides use an algorithm according to Diffie-Hellman to exchange their keys.
The private host and server keys are absolutely required to decrypt the
session key and cannot be derived from the public parts. Only the
contacted SSH daemon can decrypt the session key using its private keys.
This initial connection phase can be watched closely by turning on
verbose debugging using the -v
option of the SSH client.
To watch the log entries from the sshd
use the following command:
tux >
sudo
journalctl -u sshd
It is recommended to back up the private and public keys stored in
/etc/ssh/
in a secure, external location. In this
way, key modifications can be detected or the old ones can be used again
after having installed a new system.
If you install openSUSE Leap on a machine with existing Linux installations, the installation routine automatically imports the SSH host key with the most recent access time from an existing installation.
When establishing a secure connection with a remote host for the first
time, the client stores all public host keys in
~/.ssh/known_hosts
. This prevents any
man-in-the-middle attacks—attempts by foreign SSH servers to use
spoofed names and IP addresses. Such attacks are detected either by a
host key that is not included in ~/.ssh/known_hosts
,
or by the server's inability to decrypt the session key in the absence of
an appropriate private counterpart.
If the public keys of a host have changed (that needs to be verified
before connecting to such a server), the offending keys can be
removed with ssh-keygen -r
HOSTNAME
.
As of version 6.8, OpenSSH comes with a protocol extension that supports host key rotation. It makes sense to replace keys, if you are still using weak keys such as 1024-bit RSA keys. It is strongly recommended to replace such a key and go for 2048-bit DSA keys or something even better. The client will then use the “best” host key.
After installing new host keys on the server, restart sshd.
This protocol extension can
inform a client of all the new host keys on the server, if the user
initiates a connection with ssh
. Then, the
software on the client updates
~/.ssh/known_hosts
, and the user is not
required to accept new keys of previously known and trusted hosts
manually. The local known_hosts
file will
contain all the host keys of the remote hosts, in addition to the
one that authenticated the host during this session.
Once the administrator of the server knows that all the clients have
fetched the new keys, they can remove the old keys. The protocol
extension ensures that the obsolete keys will be removed from the
client's configuration, too. The key removal occurs while initiating
an ssh
session.
For more information, see:
http://blog.djm.net.au/2015/02/key-rotation-in-openssh-68.html
http://heise.de/-2540907 (“Endlich neue Schlüssel für SSH-Server”, German only)
In its simplest form, authentication is done by entering the user's
password just as if logging in locally. However, having to memorize
passwords of several users on remote machines is inefficient. What is
more, these passwords may change. On the other hand—when
granting root
access—an administrator needs to be able
to quickly revoke such a permission without having to change the
root
password.
To accomplish a login that does not require to enter the remote
user's password, SSH uses another key pair, which needs to be generated
by the user. It consists of a public (id_rsa.pub
or
id_dsa.pub
) and a private key
(id_rsa
or id_dsa
).
To be able to log in without having to specify the remote user's
password, the public key of the “SSH user” must be
in ~/.ssh/authorized_keys
. This approach also
ensures that the remote user has got full control: adding the key
requires the remote user's password and removing the key revokes the
permission to log in from remote.
For maximum security such a key should be protected by a passphrase which
needs to be entered every time you use ssh
,
scp
, or sftp
. Contrary to the
simple authentication, this passphrase is independent from the remote
user and therefore always the same.
An alternative to the key-based authentication described above, SSH also offers a host-based authentication. With host-based authentication, users on a trusted host can log in to another host on which this feature is enabled using the same user name. openSUSE Leap is set up for using key-based authentication, covering setting up host-based authentication on openSUSE Leap is beyond the scope of this manual.
If the host-based authentication is to be used, the file
/usr/lib/ssh/ssh-keysign
(32-bit systems) or
/usr/lib64/ssh/ssh-keysign
(64-bit systems) should
have the setuid bit set, which is not the default setting in
openSUSE Leap. In such case, set the file permissions manually. You
should use /etc/permissions.local
for this purpose,
to make sure that the setuid bit is preserved after security updates of
openssh.
To generate a key with default parameters (RSA, 2048 bits), enter the
command ssh-keygen
.
Accept the default location to store the key
(~/.ssh/id_rsa
) by pressing
Enter (strongly recommended) or enter an
alternative location.
Enter a passphrase consisting of 10 to 30 characters. The same rules as for creating safe passwords apply. It is strongly advised to refrain from specifying no passphrase.
You should make absolutely sure that the private key is not accessible
by anyone other than yourself (always set its permissions to
0600
). The private key must never fall into the hands
of another person.
To change the password of an existing key pair, use the command
ssh-keygen -p
.
To copy a public SSH key to ~/.ssh/authorized_keys
of a user on a remote machine, use the command
ssh-copy-id
. To copy your personal key
stored under ~/.ssh/id_rsa.pub
you may use the
short form. To copy DSA keys or keys of other users, you need
to specify the path:
tux >
~/.ssh/id_rsa.pub
ssh-copy-id -i tux@suntux >
~/.ssh/id_dsa.pub
ssh-copy-id -i ~/.ssh/id_dsa.pub tux@suntux >
~notme/.ssh/id_rsa.pub
ssh-copy-id -i ~notme/.ssh/id_rsa.pub tux@sun
To successfully copy the key, you need to enter the remote
user's password. To remove an existing key, manually edit
~/.ssh/authorized_keys
.
ssh-agent
#
When doing lots of secure shell operations it is cumbersome to type the
SSH passphrase for each such operation. Therefore, the SSH package
provides another tool, ssh-agent
, which retains the
private keys for the duration of an X or terminal session. All other
windows or programs are started as clients to the
ssh-agent
. By starting the agent, a set of
environment variables is set, which will be used by
ssh
, scp
, or
sftp
to locate the agent for automatic login. See
the ssh-agent
man page for details.
After the ssh-agent
is started, you need to add your
keys by using ssh-add
. It will prompt for the
passphrase. After the password has been provided once, you can use the
secure shell commands within the running session without having to
authenticate again.
ssh-agent
in an X Session #
On openSUSE Leap, the ssh-agent
is automatically
started by the GNOME display manager. To also invoke
ssh-add
to add your keys to the agent at the
beginning of an X session, do the following:
Log in as the desired user and check whether the file
~/.xinitrc
exists.
If it does not exist, use an existing template or copy it from
/etc/skel
:
if [ -f ~/.xinitrc.template ]; then mv ~/.xinitrc.template ~/.xinitrc; \ else cp /etc/skel/.xinitrc.template ~/.xinitrc; fi
If you have copied the template, search for the following lines and
uncomment them. If ~/.xinitrc
already existed,
add the following lines (without comment signs).
# if test -S "$SSH_AUTH_SOCK" -a -x "$SSH_ASKPASS"; then # ssh-add < /dev/null # fi
When starting a new X session, you will be prompted for your SSH passphrase.
ssh-agent
in a Terminal Session #
In a terminal session you need to manually start the
ssh-agent
and then call ssh-add
afterward. There are two ways to start the agent. The first example
given below starts a new Bash shell on top of your existing shell. The
second example starts the agent in the existing shell and modifies the
environment as needed.
tux >
ssh-agent -s /bin/bash
eval $(ssh-agent)
After the agent has been started, run ssh-add
to
provide the agent with your keys.
ssh
can also be used to redirect TCP/IP connections.
This feature, also called SSH tunneling
, redirects TCP
connections to a certain port to another machine via an encrypted
channel.
With the following command, any connection directed to jupiter port 25 (SMTP) is redirected to the SMTP port on sun. This is especially useful for those using SMTP servers without SMTP-AUTH or POP-before-SMTP features. From any arbitrary location connected to a network, e-mail can be transferred to the “home” mail server for delivery.
root #
ssh -L 25:sun:25 jupiter
Similarly, all POP3 requests (port 110) on jupiter can be forwarded to the POP3 port of sun with this command:
root #
ssh -L 110:sun:110 jupiter
Both commands must be executed as root
, because the connection
is made to privileged local ports. E-mail is sent and retrieved by
normal users in an existing SSH connection. The SMTP and POP3 host
must be set to localhost
for this to
work. Additional information can be found in the manual pages for
each of the programs described above and in the OpenSSH package
documentation under
/usr/share/doc/packages/openssh
.
The home page of OpenSSH
The OpenSSH Wikibook
man sshd
The man page of the OpenSSH daemon
man ssh_config
The man page of the OpenSSH SSH client configuration files
man scp
, man sftp
, man slogin
, man ssh
, man ssh-add
, man ssh-agent
, man ssh-copy-id
, man ssh-keyconvert
, man ssh-keygen
, man ssh-keyscan
Man pages of several binary files to securely copy files
(scp
, sftp
), to log in
(slogin
, ssh
), and to manage
keys.
/usr/share/doc/packages/openssh/README.SUSE
,
/usr/share/doc/packages/openssh/README.FIPS
SUSE package specific documentation; changes in defaults with respect to upstream, notes on FIPS mode etc.
Whenever Linux is used in a network environment, you can use the
kernel functions that allow the manipulation of network packets to
maintain a separation between internal and external network areas. The
Linux netfilter
framework provides the means
to establish an effective firewall that keeps different networks
apart. Using iptables—a generic table structure for the
definition of rule sets—precisely controls the packets allowed to
pass a network interface. Such a packet filter can be set up using
firewalld
and its graphical interface firewall-config
.
This section discusses the low-level details of packet filtering. The
components netfilter
and
iptables
are responsible for the filtering and
manipulation of network packets and for network address translation (NAT).
The filtering criteria and any actions associated with them are stored in
chains, which must be matched one after another by individual network
packets as they arrive. The chains to match are stored in tables. The
iptables
command allows you to alter these tables and
rule sets.
The Linux kernel maintains three tables, each for a particular category of functions of the packet filter:
This table holds the bulk of the filter rules, because it implements
the packet filtering mechanism in the stricter
sense, which determines whether packets are let through
(ACCEPT
) or discarded (DROP
),
for example.
This table defines any changes to the source and target addresses of packets. Using these functions also allows you to implement masquerading, which is a special case of NAT used to link a private network with the Internet.
The rules held in this table make it possible to manipulate values stored in IP headers (such as the type of service).
These tables contain several predefined chains to match packets:
This chain is applied to all incoming packets.
This chain is applied to packets destined for the system's internal processes.
This chain is applied to packets that are only routed through the system.
This chain is applied to packets originating from the system itself.
This chain is applied to all outgoing packets.
Figure 16.1, “iptables: A Packet's Possible Paths” illustrates the paths along which a network packet may travel on a given system. For the sake of simplicity, the figure lists tables as parts of chains, but in reality these chains are held within the tables themselves.
In the simplest case, an incoming packet destined for the system itself
arrives at the eth0
interface. The packet is first
referred to the PREROUTING
chain of the
mangle
table then to the PREROUTING
chain of the nat
table. The following step, concerning
the routing of the packet, determines that the actual target of the
packet is a process of the system itself. After passing the
INPUT
chains of the mangle
and the
filter
table, the packet finally reaches its target,
provided that the rules of the filter
table allow this.
Masquerading is the Linux-specific form of NAT (network address
translation) and can be used to connect a small LAN with the
Internet. LAN hosts use IP
addresses from the private range (see
Book “Reference”, Chapter 13 “Basic Networking”, Section 13.1.2 “Netmasks and Routing”) and on the Internet
official IP addresses are used. To be able to connect
to the Internet, a LAN host's private address is translated to an official
one. This is done on the router, which acts as the gateway between the
LAN and the Internet. The underlying principle is a simple one: The
router has more than one network interface, typically a network card and
a separate interface connecting with the Internet. While the latter links
the router with the outside world, one or several others link it with the
LAN hosts. With these hosts in the local network connected to the network
card (such as eth0
) of the router, they can send any
packets not destined for the local network to their default gateway or
router.
When configuring your network, make sure both the broadcast address and the netmask are the same for all local hosts. Failing to do so prevents packets from being routed properly.
As mentioned, whenever one of the LAN hosts sends a packet destined for
an Internet address, it goes to the default router. However, the router
must be configured before it can forward such packets. For security
reasons, this is not enabled in a default installation. To enable it, add
the line net.ipv4.ip_forward = 1
in the file
/etc/sysctl.conf
. Alternatively do this via YaST,
for example by calling yast routing ip-forwarding on
.
The target host of the connection can see your router, but knows nothing about the host in your internal network where the packets originated. This is why the technique is called masquerading. Because of the address translation, the router is the first destination of any reply packets. The router must identify these incoming packets and translate their target addresses, so packets can be forwarded to the correct host in the local network.
With the routing of inbound traffic depending on the masquerading table, there is no way to open a connection to an internal host from the outside. For such a connection, there would be no entry in the table. In addition, any connection already established has a status entry assigned to it in the table, so the entry cannot be used by another connection.
As a consequence of all this, you might experience some problems with several application protocols, such as ICQ, cucme, IRC (DCC, CTCP), and FTP (in PORT mode). Web browsers, the standard FTP program, and many other programs use the PASV mode. This passive mode is much less problematic as far as packet filtering and masquerading are concerned.
Firewall is probably the term most widely used to describe a mechanism that controls the data flow between networks. Strictly speaking, the mechanism described in this section is called a packet filter. A packet filter regulates the data flow according to certain criteria, such as protocols, ports, and IP addresses. This allows you to block packets that, according to their addresses, are not supposed to reach your network. To allow public access to your Web server, for example, explicitly open the corresponding port. However, a packet filter does not scan the contents of packets with legitimate addresses, such as those directed to your Web server. For example, if incoming packets were intended to compromise a CGI program on your Web server, the packet filter would still let them through.
A more effective but more complex mechanism is the combination of several types of systems, such as a packet filter interacting with an application gateway or proxy. In this case, the packet filter rejects any packets destined for disabled ports. Only packets directed to the application gateway are accepted. This gateway or proxy pretends to be the actual client of the server. In a sense, such a proxy could be considered a masquerading host on the protocol level used by the application. One example for such a proxy is Squid, an HTTP and FTP proxy server. To use Squid, the browser must be configured to communicate via the proxy. Any HTTP pages or FTP files requested are served from the proxy cache and objects not found in the cache are fetched from the Internet by the proxy.
The following section focuses on the packet filter that comes with openSUSE Leap. For further information about packet filtering and firewalling, read the Firewall HOWTO.
firewalld
#
firewalld
is a daemon that maintains the system's
iptables
rules and offers a D-Bus interface for
operating on them. It comes with a command line utility
firewall-cmd
and a graphical user interface
firewall-config
for interacting with it. Since
firewalld
is running in the background and provides a well defined
interface it allows other applications to request changes to the iptables
rules, for example to set up virtual machine networking.
firewalld
implements different security zones. A number of predefined
zones like internal
and public
exist.
The administrator can define additional custom zones if desired. Each
zone contains its own set of iptables rules. Each network interface is a
member of exactly one zone. Individual connections can also be assigned to
a zone based on the source addresses.
Each zone represents a certain level of trust. For example the
public
zone is not trusted, because other computers in
this network are not under your control (suitable for Internet or wireless
hotspot connections). On the other hand the internal
zone
is used for networks that are under your control, like a
home or company network. By utilizing zones this way, a host can offer
different kinds of services to trusted networks and untrusted networks in a
defined way.
For more information about the predefined zones and their meaning in
firewalld
, refer to its manual at
http://www.firewalld.org/documentation/zone/predefined-zones.html.
The initial state for network interfaces is to be assigned to no zone at
all. In this case the network interface will be implicitly handled in the
default zone, which can be determined by calling firewall-cmd
--get-default-zone
. If not configured otherwise, the default
zone is the public
zone.
The firewalld
packet filtering model allows any outgoing connections to
pass. Outgoing connections are connections that are actively established by
the local host. Incoming connections that are established by remote hosts are
blocked if the respective service is not allowed in the zone in
question. Therefore, each of the interfaces with incoming traffic must be
placed in a suitable zone to allow for the desired services to be
accessible. For each of the zones, define the services or protocols you
need.
An important concept of firewalld
is the distinction between two separate
configurations: the runtime and the
permanent configuration. The runtime configuration
represents the currently active rules, while the permanent configuration
represents the saved rules that will be applied when restarting
firewalld
. This allows to add temporary rules that will be discarded after
restarting firewalld
, or to experiment with new rules while being able to
revert back to the original state. When you are changing the configuration,
you need to be aware of which configuration you're editing. How this is done
is discussed in Section 16.4.1.2, “Runtime Versus Permanent Configuration”.
If you want to perform the firewalld
configuration using the graphical
user interface firewall-config
then refer to its documentation.
In the following section we will be looking at how to perform typical
firewalld
configuration tasks using firewall-cmd
on the
command line.
firewalld
will be installed and enabled by default. It is a regular
systemd
service that can be configured via systemctl
or the YaST Services Manager.
After the installation, YaST automatically starts firewalld
and
leaves all interfaces in the default public
zone. If a
server application is configured and activated on the system, YaST can
adjust the firewall rules via the options or in the server configuration modules. Some server module
dialogues include a button for
activating additional services and ports.
By default all firewall-cmd
commands operate on the
runtime configuration. You can apply most operations to the permanent
configuration only by adding the
--permanent
parameter. When doing so the change will
only affect the permanent configuration and will not be effective
immediately in the runtime configuration. There is currently no way to add
a rule to both runtime and permanent configurations in a single invocation.
To achieve this you can apply all necessary changes to the runtime
configuration and when all is working as expected issue the following
command:
root #
firewall-cmd --runtime-to-permanent
This will write all current runtime rules into the permanent configuration.
Any temporary modifications you or other programs may have made to the
firewall in other contexts are made permanent this way. If you're unsure
about this, you can also take the opposite approach to be on the safe side:
Add new rules to the permanent configuration and reload firewalld
to
make them active.
Some configuration items, like the default zone, are shared by both the runtime and permanent configurations. Changing them will reflect in both configurations at once.
To revert the runtime configuration to the permanent configuration and
thereby discard any temporary changes, two possibilities exist, either via
the firewalld
command line interface or via systemd
:
root #
firewall-cmd --reload
root #
systemctl reload firewalld
For brevity the examples in the following sections will always operate on the runtime configuration, if applicable. Adjust them accordingly if you want to make them permanent.
You can list all network interfaces currently assigned to a zone like this:
root #
firewall-cmd --zone=public --list-interfaces
eth0
Similarly you can query which zone a specific interface is assigned to:
root #
firewall-cmd --get-zone-of-interface=eth0
public
The following command lines assign an interface to a zone. The variant
using --add-interface
will only work if
eth0
is not already assigned to another zone. The
variant using --change-interface
will always work,
removing eth0
from its current zone if necessary:
root #
firewall-cmd --zone=internal --add-interface=eth0
root #
firewall-cmd --zone=internal --change-interface=eth0
Any operations without an explicit --zone
argument will
implicitly operate on the default zone. This pair of commands can be used
for getting and setting the default zone assignment:
root #
firewall-cmd --get-default-zone
dmzroot #
firewall-cmd --set-default-zone=public
Any network interfaces not explicitly assigned to a zone will be
automatically part of the default zone. Changing the default zone will
reassign all those network interfaces immediately for the permanent and
runtime configurations. You should never use a trusted zone like
internal
as the default zone, to avoid unexpected
exposure to threats. For example hotplugged network interfaces like USB
ethernet interfaces would automatically become part of the trusted zone in
such cases.
Also note that interfaces that are not explicitly part of any zone will not appear in the zone interface list. There is currently no command to list unassigned interfaces. Due to this it is best to avoid unassigned network interfaces during regular operation.
firewalld
has a concept of services. A service
consists of definitions of ports and protocols. These definitions
logically belong together in the context of a given network service like
a Web or mail server protocol. The following commands can be used to get
information about predefined services and their details:
root #
firewall-cmd --get-services
[...] dhcp dhcpv6 dhcpv6-client dns docker-registry [...]root #
firewall-cmd --info-service dhcp
dhcp ports: 67/udp protocols: source-ports: modules: destination:
These service definitions can be used for easily making the associated network functionality accessible in a zone. This command line will open the http Web server port in the internal zone, for example:
root #
firewall-cmd --add-service=http --zone=internal
The removal of a service from a zone is performed using the counterpart
command --remove-service
. You can also define custom
services using the --new-service
subcommand. Refer to
http://www.firewalld.org/documentation/howto/add-a-service.html
for more details on how to do this.
If you just want to open a single port by number, you can use the following approach. This will open TCP port 8000 in the internal zone:
root #
firewall-cmd --add-port=8000/tcp --zone=internal
For removal use the counterpart command --remove-port
.
firewalld
supports a --timeout
parameter that allows
to open a service or port for a limited time duration. This can be helpful
for quick testing and makes sure that closing the service or port will not
be forgotten. To allow the imap
service in the
internal
zone for 5 minutes, you would call
root #
firewall-cmd --add-service=imap --zone=internal --timeout=5m
firewalld
offers a lockdown mode that prevents
changes to the firewall rules while it is active. Since applications can
automatically change the firewall rules via the D-Bus interface, and
depending on the PolicyKit rules regular users may be able to do the same,
it can be helpful to prevent changes in some situations. You can find more
information about this at
https://fedoraproject.org/wiki/Features/FirewalldLockdown.
It is important to understand that the lockdown mode feature
provides no real security, but merely protection against accidental or
benign attempts to change the firewall. The way the lockdown mode is
currently implemented in firewalld
provides no security against malicious
intent. as is pointed out at
http://seclists.org/oss-sec/2017/q3/139.
iptables
Rules #
firewalld
claims exclusive control over the host's
netfilter
rules. You should never modify
firewall rules using other tools like iptables
. Doing
so could confuse firewalld
and break security or functionality.
If you need to add custom firewall rules that aren't covered by
firewalld
features then there are two ways to do so. To directly pass
raw iptables
syntax you can use the
--direct
option. It expects the table, chain, and
priority as initial arguments and the rest of the command line is passed
as is to iptables
. The following example adds a
connection tracking rule for the forwarding filter table:
root #
firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i eth0 -o eth1 \ -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
Additionally, firewalld
implements so called rich
rules, an extended syntax for specifying
iptables
rules in an easier way. You can find the
syntax specification at
http://www.firewalld.org/documentation/man-pages/firewalld.richlanguage.html.
The following example drops all IPv4 packets originating from a certain
source address:
root #
firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" \ source address="192.168.2.4" drop'
firewalld
is not designed to run as a fully fledged router. The
basic functionality for typical home router setups is available. For a
corporate production router you should not use firewalld
, however, but
use dedicated router and firewall devices instead. The following provides
just a few pointers on what to look for to utilize routing in firewalld
:
First of all IP forwarding needs to be enabled as outlined in Section 16.2, “Masquerading Basics”.
To enable IPv4 masquerading, for example in the
internal
zone, issue the following command.
root #
firewall-cmd --zone=internal --add-masquerade
firewalld
can also enable port forwarding. The following command will
forward local TCP connections on port 80 to another host:
root #
firewall-cmd --zone=public \ --add-forward-port=port=80:proto=tcp:toport=80:toaddr=192.168.1.10
Some network services do not listen on predefined port numbers. Instead
they operate based on the portmapper
or
rpcbind
protocol. We will use the term
rpcbind
from here on. When one of these services
starts, it chooses a random local port and talks to
rpcbind
to make the port number known.
rpcbind
itself is listening on a well known port.
Remote systems can then query rpcbind
about the network
services it knows about and on which ports they are listening. Not many
programs use this approach anymore today. Popular examples are
Network Information Services (NIS; ypserv
and
ypbind
) and the Network File System (NFS) version 3.
The newer NFSv4 only requires the single well known
TCP port 2049. For protocol version 4.0 the kernel parameter
fs.nfs.nfs_callback_tcpport
may need to be set
to a static port (see Example 16.1, “Callback Port Configuration for the nfs
Kernel Module in /etc/modprobe.d/60-nfs.conf
”).
Starting with protocol version 4.1 this setting has also become
unnecessary.
The dynamic nature of the rpcbind
protocol makes
it difficult to make the affected services behind the firewall accessible.
firewalld
does not support these services by itself. For manual configuration,
see Section 16.4.2.1, “Configuring Static Ports”.
Alternatively, openSUSE Leap provides a helper script. For details, see
Section 16.4.2.2, “Using firewall-rpcbind-helper for Configuring Static Ports”.
One possibility is to configure all involved network services to use
fixed port numbers. Once this is done, the fixed ports can be opened in
firewalld
and everything should work. The actual port numbers used are
at your discretion but should not clash with any well known port numbers
assigned to other services. See Table 16.1, “Important Sysconfig Variables for Static Port Configuration”
for a list of the available configuration items for NIS and NFSv3
services. Note that depending on your actual NIS or NFS configuration,
not all of these ports may be required for your setup.
File Path |
Variable Name |
Example Value |
---|---|---|
/etc/sysconfig/nfs
| MOUNTD_PORT | 21001 |
STATD_PORT | 21002 | |
LOCKD_TCPPORT | 21003 | |
LOCKD_UDPPORT | 21003 | |
RQUOTAD_PORT | 21004 | |
/etc/sysconfig/ypbind
| YPBIND_OPTIONS | -p 24500 |
/etc/sysconfig/ypserv
| YPXFRD_ARGS | -p 24501 |
YPSERV_ARGS | -p 24502 | |
YPPASSWDD_ARGS | --port 24503 |
You will need to restart any related services that are affected by these
static port configurations for the changes to take effect. You can see
the currently assigned rpcbind ports by using the command
rpcinfo -p
. On success only the statically configured
ports should show up there.
Apart from the port configuration for network services running in
userspace there are also ports that are used by the Linux kernel directly
when it comes to NFS. One of these ports is
nfs_callback_tcpport
. It is only required for NFS
protocol versions older than 4.1. There is a sysctl named
fs.nfs.nfs_callback_tcpport
to configure this port.
This sysctl node only appears dynamically when NFS mounts are active.
Therefore it is best to configure the port via kernel module
parameters. This can be achieved by creating a file as shown in
Example 16.1, “Callback Port Configuration for the nfs
Kernel Module in /etc/modprobe.d/60-nfs.conf
”.
nfs
Kernel Module in /etc/modprobe.d/60-nfs.conf
#options nfs callback_tcpport=21005
To make this change effective it is easiest to reboot the machine.
Otherwise all NFS services need to be stopped and the
nfs
kernel module needs to be reloaded. To verify the
active NFS callback port, check the output of
cat /sys/module/nfs/parameters/callback_tcpport
.
For easy handling of the now statically configured RPC ports, it is useful
to create a new firewalld
service definition. This service definition
will group all related ports and, for example, makes it easy to make them
accessible in a specific zone. In
Example 16.2, “Commands to Define a new firewalld
RPC Service for NFS” this is done for the
NFS ports as they have been configured in the accompanying examples.
firewalld
RPC Service for NFS #root #
firewall-cmd --permanent --new-service=nfs-rpc
root #
firewall-cmd --permanent --service=nfs-rpc --set-description="NFS related, statically configured RPC ports"
# add UDP and TCP ports for the given sequenceroot #
for port in 21001 21002 21003 21004; do firewall-cmd --permanent --service=nfs-rpc --add-port ${port}/udp --add-port ${port}/tcp done
# the callback port is TCP onlyroot #
firewall-cmd --permanent --service=nfs-rpc --add-port 21005/tcp
# show the complete definition of the new custom serviceroot #
firewall-cmd --info-service=nfs-rpc --permanent -v
nfs-rpc summary: description: NFS and related, statically configured RPC ports ports: 4711/tcp 21001/udp 21001/tcp 21002/udp 21002/tcp 21003/udp 21003/tcp 21004/udp 21004/tcp protocols: source-ports: modules: destination: # reload firewalld to make the new service definition availableroot #
firewall-cmd --reload
# the new service definition can now be used to open the ports e.g. in the internal zoneroot #
firewall-cmd --add-service=nfs-rpc --zone=internal
The steps to configure static ports as shown in the previous section can
be simplified by using the SUSE helper tool
firewall-rpc-helper.py
. Install it with
zypper in firewalld-rpcbind-helper
.
The tool allows interactive configuration of the service patterns
discussed in the previous section. It can also display current port
assignments and can be used for scripting. For details, see
firewall-rpc-helper.py --help
.
The most up-to-date information and other documentation about the firewalld
package is found in /usr/share/doc/packages/firewalld
.
The home page of the netfilter and iptables project, http://www.netfilter.org, provides a large collection of
documents about iptables in general in many languages.
Today, Internet connections are cheap and available almost everywhere. However, not all connections are secure. Using a Virtual Private Network (VPN), you can create a secure network within an insecure network such as the Internet or Wi-Fi. It can be implemented in different ways and serves several purposes. In this chapter, we focus on the OpenVPN implementation to link branch offices via secure wide area networks (WANs).
This section defines some terms regarding VPN and gives a brief overview of some scenarios.
The two “ends” of a tunnel, the source or destination client.
A tap device simulates an Ethernet device (layer 2 packets in the OSI model, such as IP packets). A tap device is used for creating a network bridge. It works with Ethernet frames.
A tun device simulates a point-to-point network (layer 3 packets in the OSI model, such as Ethernet frames). A tun device is used with routing and works with IP frames.
Linking two locations through a primarily public network. From a more technical viewpoint, it is a connection between the client's device and the server's device. Usually a tunnel is encrypted, but it does need to be by definition.
Whenever you set up a VPN connection, your IP packets are transferred over a secured tunnel. A tunnel can use either a tun or tap device. They are virtual network kernel drivers which implement the transmission of Ethernet frames or IP frames/packets.
Any user space program, such as OpenVPN, can attach itself to a tun or tap device to receive packets sent by your operating system. The program is also able to write packets to the device.
There are many solutions to set up and build a VPN connection. This section focuses on the OpenVPN package. Compared to other VPN software, OpenVPN can be operated in two modes:
Routing is an easy solution to set up. It is more efficient and scales better than a bridged VPN. Furthermore, it allows the user to tune MTU (Maximum Transfer Unit) to raise efficiency. However, in a heterogeneous environment, if you do not have a Samba server on the gateway, NetBIOS broadcasts do not work. If you need IPv6, the drivers for the tun devices on both ends must support this protocol explicitly. This scenario is depicted in Figure 17.1, “Routed VPN”.
Bridging is a more complex solution. It is recommended when you need to browse Windows file shares across the VPN without setting up a Samba or WINS server. Bridged VPN is also needed to use non-IP protocols (such as IPX) or applications relying on network broadcasts. However, it is less efficient than routed VPN. Another disadvantage is that it does not scale well. This scenario is depicted in the following figures.
The major difference between bridging and routing is that a routed VPN cannot IP-broadcast while a bridged VPN can.
In the following example, we will create a point-to-point VPN tunnel. The
example demonstrates how to create a VPN tunnel between one client and a
server. It is assumed that your VPN server will use private IP addresses
like IP_OF_SERVER
and your client will use the IP address
IP_OF_CLIENT
.
Make sure you select addresses which do not conflict with other IP addresses.
This following scenario is provided as an example meant for familiarizing yourself with VPN technology. Do not use this as a real world scenario, as it can compromise the security and safety of your IT infrastructure!
To simplify working with OpenVPN configuration files, we recommend the following:
Place your OpenVPN configuration files in the directory
/etc/openvpn
.
Name your configuration files
MY_CONFIGURATION.conf
.
If there are multiple files that belong to the same configuration, place
them in a subdirectory like
/etc/openvpn/MY_CONFIGURATION
.
To configure a VPN server, proceed as follows:
Install the package openvpn
on the machine that will later become your VPN server.
Open a shell, become root
and create the VPN secret key:
root #
openvpn --genkey --secret /etc/openvpn/secret.key
Copy the secret key to your client:
root #
scp /etc/openvpn/secret.key root@IP_OF_CLIENT:/etc/openvpn/
Create the file /etc/openvpn/server.conf
with the
following content:
dev tun ifconfig IP_OF_SERVER IP_OF_CLIENT secret secret.key
Set up a tun device configuration by creating a file called
/etc/sysconfig/network/ifcfg-tun0
with the following
content:
STARTMODE='manual' BOOTPROTO='static' TUNNEL='tun' TUNNEL_SET_OWNER='nobody' TUNNEL_SET_GROUP='nobody' LINK_REQUIRED=no PRE_UP_SCRIPT='systemd:openvpn@server' PRE_DOWN_SCRIPT='systemd:openvpn@service'
The notation openvpn@server
points to the OpenVPN
server configuration file located at
/etc/openvpn/server.conf
. For more information, see
/usr/share/doc/packages/openvpn/README.SUSE
.
If you use a firewall, start YaST and open UDP port 1194 (
› › ).
Start the OpenVPN server service by setting the tun device to
up
:
tux >
sudo
wicked ifup tun0
You should see the confirmation:
tun0 up
To configure the VPN client, do the following:
Install the package openvpn
on your client VPN machine.
Create /etc/openvpn/client.conf
with the
following content:
remote DOMAIN_OR_PUBLIC_IP_OF_SERVER dev tun ifconfig IP_OF_CLIENT IP_OF_SERVER secret secret.key
Replace the placeholder IP_OF_CLIENT in the first line with either the domain name, or the public IP address of your server.
Set up a tun device configuration by creating a file called
/etc/sysconfig/network/ifcfg-tun0
with the following
content:
STARTMODE='manual' BOOTPROTO='static' TUNNEL='tun' TUNNEL_SET_OWNER='nobody' TUNNEL_SET_GROUP='nobody' LINK_REQUIRED=no PRE_UP_SCRIPT='systemd:openvpn@client' PRE_DOWN_SCRIPT='systemd:openvpn@client'
If you use a firewall, start YaST and open UDP port 1194 as described in Step 6 of Procedure 17.1, “VPN Server Configuration”.
Start the OpenVPN server service by setting the tun device to
up
:
tux >
sudo
wicked ifup tun0
You should see the confirmation:
tun0 up
After OpenVPN has successfully started, test the availability of the tun device with the following command:
ip addr show tun0
To verify the VPN connection, use ping
on both client
and server side to see if they can reach each other. Ping the server
from the client:
ping -I tun0 IP_OF_SERVER
Ping the client from the server:
ping -I tun0 IP_OF_CLIENT
The example in Section 17.2 is useful for testing, but not for daily work. This section explains how to build a VPN server that allows more than one connection at the same time. This is done with a public key infrastructure (PKI). A PKI consists of a pair of public and private keys for the server and each client, and a master certificate authority (CA), which is used to sign every server and client certificate.
This setup involves the following basic steps:
Before a VPN connection can be established, the client must authenticate the server certificate. Conversely, the server must also authenticate the client certificate. This is called mutual authentication. To create such certificates, use the YaST CA module. See Chapter 18, Managing X.509 Certification for more details.
To create a VPN root, server, and client CA, proceed as follows:
Prepare a common VPN Certificate Authority (CA):
Start the YaST CA module.
Click
.
Enter a VPN-Server-CA
.
Fill out the other boxes like e-mail addresses, organization, etc. and proceed with
.Enter your password twice and proceed with
.Review the summary. YaST displays the current settings for confirmation. Click
. The root CA is created and displayed in the overview.Create a VPN server certificate:
Select the root CA you created in Step 1 and click .
When prompted, enter the
.Click the
tab and click › .
Specify a openvpn.example.com
and proceed with .
Specify your password and confirm it. Then click
.Switch to the
› list and check one of the following sets:
digitalSignature
and
keyEncipherment
, or,
digitalSignature
and
keyAgreement
Switch to the serverAuth
for a server certificate.
If you are using the method remote-cert-tls server
or
remote-cert-tls client
to verify certificates, limit
the number of times a key can be used. This mitigates
man-in-the-middle attacks.
For more information, see http://openvpn.net/index.php/open-source/documentation/howto.html#mitm.
Finish with
and proceed with .Review the summary. YaST displays the current settings for confirmation. Click
. When the VPN server certificate is created, it is displayed in the tab.Create VPN client certificates:
Make sure you are on the
tab.Click
› .
Enter a client1.example.com
.
Enter the e-mail addresses for your client, for example,
user1@client1.example.com
,
and click . Proceed with
.
Enter your password twice and click
.Switch to
› list and check one of the following flags:
digitalSignature
or,
keyAgreement
or,
digitalSignature
and
keyAgreement
.
Switch to the clientAuth
for a server certificate.
Review the summary. YaST displays the current settings for confirmation. Click
. The VPN client certificate is created and is displayed in the tab.If you need certificates for more clients, repeat Step 3.
After you have successfully finished Procedure 17.3, “Creating a VPN Server Certificate” you have a VPN root CA, a VPN server CA, and one or more VPN client CAs. To finish the task, proceed with the following procedure:
Choose the
tab.Export the VPN server certificate in two formats: PEM and unencrypted key in PEM.
Export the VPN client certificates and choose an export format, PEM or PKCS12 (preferred). For each client:
Select your VPN client certificate
(client1.example.com
in our example) and choose › .
Select /etc/openvpn/client1.p12
.
Copy the files to your client (in our example,
client1.example.com
).
Export the VPN CA (in our example
VPN-Server-CA
):
Switch to the
tab.Select
› .
Mark /etc/openvpn/vpn_ca.pem
.
If desired, the client PKCS12 file can be converted into the PEM format using this command:
openssl pkcs12 -in client1.p12 -out client1.pem
Enter your client password to create the
client1.pem
file. The PEM file contains the client
certificate, client key, and the CA certificate. You can split this
combined file using a text editor and create three separate files. The
file names can be used for the ca
,
cert
, and key
options in the OpenVPN
configuration file (see Example 17.1, “VPN Server Configuration File”).
As the basis of your configuration file, copy
/usr/share/doc/packages/openvpn/sample-config-files/server.conf
to /etc/openvpn/
. Then customize it to your needs.
# /etc/openvpn/server.conf port 1194 1 proto udp 2 dev tun0 3 # Security 4 ca vpn_ca.pem cert server_crt.pem key server_key.pem # ns-cert-type server remote-cert-tls client 5 dh server/dh2048.pem 6 server 192.168.1.0 255.255.255.0 7 ifconfig-pool-persist /var/run/openvpn/ipp.txt 8 # Privileges 9 user nobody group nobody # Other configuration 10 keepalive 10 120 comp-lzo persist-key persist-tun # status /var/log/openvpn-status.tun0.log 11 # log-append /var/log/openvpn-server.log 12 verb 4
The TCP/UDP port on which OpenVPN listens. You need to open the port in the firewall, see Chapter 16, Masquerading and Firewalls. The standard port for VPN is 1194, so you can usually leave that as it is. | |
The protocol, either UDP or TCP. | |
The tun or tap device. For the difference between these, see Section 17.1.1, “Terminology”. | |
The following lines contain the relative or absolute path to the root
server CA certificate ( | |
Require that peer certificates have been signed with an explicit key usage and extended key usage based on RFC3280 TLS rules. There is a description of how to make a server use this explicit key in Procedure 17.3, “Creating a VPN Server Certificate”. | |
The Diffie-Hellman parameters. Create the required file with the following command: openssl dhparam -out /etc/openvpn/dh2048.pem 2048 | |
Supplies a VPN subnet. The server can be reached by
| |
Records a mapping of clients and its virtual IP address in the given file. Useful when the server goes down and (after the restart) the clients get their previously assigned IP address. | |
For security reasons, run the OpenVPN daemon with reduced privileges. To
do so, specify that it should use the group and user
| |
Several other configuration options—see the comment in the
example configuration file:
| |
Enable this option to write short status updates with statistical data (“operational status dump”) to the named file. By default, this is not enabled.
All output is written to the system journal which can be displayed with
| |
By default, log messages go to syslog. Overwrite this behavior by
removing the hash character. In that case, all messages go to
|
After having completed this configuration, you can see log messages of
your OpenVPN server under /var/log/openvpn.log
.
After having started it for the first time, it should finish with:
... Initialization Sequence Completed
If you do not see this message, check the log carefully for any hints of what is wrong in your configuration file.
As the basis of your configuration file, copy
/usr/share/doc/packages/openvpn/sample-config-files/client.conf
to /etc/openvpn/
. Then customize it to your needs.
# /etc/openvpn/client.conf client 1 dev tun 2 proto udp 3 remote IP_OR_HOST_NAME 1194 4 resolv-retry infinite nobind remote-cert-tls server 5 # Privileges 6 user nobody group nobody # Try to preserve some state across restarts. persist-key persist-tun # Security 7 pkcs12 client1.p12 comp-lzo 8
Specifies that this machine is a client. | |
The network device. Both clients and server must use the same device. | |
The protocol. Use the same settings as on the server. | |
This is security option for clients which ensures that the host they connect to is a designated server. | |
Replace the placeholder IP_OR_HOST_NAME
with the respective host name or IP address of your VPN server. After
the host name, the port of the server is given. You can have multiple
lines of | |
For security reasons, run the OpenVPN daemon with reduced privileges. To
do so, specify that it should use the group and user
| |
Contains the client files. For security reasons, use a separate pair of files for each client. | |
Turn on compression. Only use this parameter if compression is enabled on the server as well. |
You can also use YaST to set up a VPN server. However, the YaST module does not support OpenVPN. Instead, it provides support for the IPsec protocol (as implemented in the software StrongSwan). Like OpenVPN, IPsec is a widely supported VPN scheme.
To start the YaST VPN module, select
› .Under
, activate .To create a new VPN, click
, then enter a name for the connection.Under
, select .Then choose the scenario:
The scenarios
and are best suited to Linux client setups.The scenario
sets up a configuration that is natively supported by modern versions of Android, iOS, and macOS. It is based on a pre-shared key setup with an additional user name and password authentication.The scenario
is a configuration that is natively supported by Windows and BlackBerry devices. It is based on a certificate setup with an additional user name and password authentication.For this example, choose
.To specify the key, click
. Activate , then type the secret key. Confirm with .Choose whether and how to limit access within your VPN under https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing.
. To enable only certain IP ranges, specify these in CIDR format, separated by commas in . For more information about the CIDR format, seeUnder
, specify the format of IP addresses your VPN should provide to its clients.To finish, click
. The YaST VPN module will now automatically add and enable firewall rules to allow clients to connect to the new VPN.
To view the connection status,
in the following confirmation window, click systemctl status
for your VPN, which allows you to check
if the VPN is running and configured correctly.
For more information on setting up a VPN connection using NetworkManager, see Book “Reference”, Chapter 28 “Using NetworkManager”, Section 28.3.4 “NetworkManager and VPN”.
For more information about VPN in general, see:
http://www.openvpn.net: the OpenVPN home page
man
openvpn
/usr/share/doc/packages/openvpn/sample-config-files/
:
example configuration files for different scenarios.
/usr/src/linux/Documentation/networking/tuntap.txt
,
to install the kernel-source
package.
An increasing number of authentication mechanisms are based on cryptographic procedures. Digital certificates that assign cryptographic keys to their owners play an important role in this context. These certificates are used for communication and can also be found, for example, on company ID cards. The generation and administration of certificates is mostly handled by official institutions that offer this as a commercial service. In some cases, however, it may make sense to carry out these tasks yourself. For example, if a company does not want to pass personal data to third parties.
YaST provides two modules for certification, which offer basic management functions for digital X.509 certificates. The following sections explain the basics of digital certification and how to use YaST to create and administer certificates of this type.
Digital certification uses cryptographic processes to encrypt and protect data from access by unauthorized people. The user data is encrypted using a second data record, or key. The key is applied to the user data in a mathematical process, producing an altered data record in which the original content can no longer be identified. Asymmetrical encryption is now in general use (public key method). Keys always occur in pairs:
The private key must be kept safely by the key owner. Accidental publication of the private key compromises the key pair and renders it useless.
The key owner circulates the public key for use by third parties.
Because the public key process is in widespread use, there are many public keys in circulation. Successful use of this system requires that every user be sure that a public key actually belongs to the assumed owner. The assignment of users to public keys is confirmed by trustworthy organizations with public key certificates. Such certificates contain the name of the key owner, the corresponding public key, and the electronic signature of the person issuing the certificate.
Trustworthy organizations that issue and sign public key certificates are usually part of a certification infrastructure. This is responsible for the other aspects of certificate management, such as publication, withdrawal, and renewal of certificates. An infrastructure of this kind is generally called a public key infrastructure or PKI. One familiar PKI is the OpenPGP standard in which users publish their certificates themselves without central authorization points. These certificates become trustworthy when signed by other parties in the “web of trust.”
The X.509 Public Key Infrastructure (PKIX) is an alternative model defined by the IETF (Internet Engineering Task Force) that serves as a model for almost all publicly-used PKIs today. In this model, authentication is made by certificate authorities (CA) in a hierarchical tree structure. The root of the tree is the root CA, which certifies all sub-CAs. The lowest level of sub-CAs issue user certificates. The user certificates are trustworthy by certification that can be traced to the root CA.
The security of such a PKI depends on the trustworthiness of the CA certificates. To make certification practices clear to PKI customers, the PKI operator defines a certification practice statement (CPS) that defines the procedures for certificate management. This should ensure that the PKI only issues trustworthy certificates.
An X.509 certificate is a data structure with several fixed fields and, optionally, additional extensions. The fixed fields mainly contain the name of the key owner, the public key, and the data relating to the issuing CA (name and signature). For security reasons, a certificate should only have a limited period of validity, so a field is also provided for this date. The CA guarantees the validity of the certificate in the specified period. The CPS usually requires the PKI (the issuing CA) to create and distribute a new certificate before expiration.
The extensions can contain any additional information. An application is only required to be able to evaluate an extension if it is identified as critical. If an application does not recognize a critical extension, it must reject the certificate. Some extensions are only useful for a specific application, such as signature or encryption.
Table 18.1 shows the fields of a basic X.509 certificate in version 3.
Field |
Content |
---|---|
Version |
The version of the certificate, for example, v3 |
Serial Number |
Unique certificate ID (an integer) |
Signature |
The ID of the algorithm used to sign the certificate |
Issuer |
Unique name (DN) of the issuing authority (CA) |
Validity |
Period of validity |
Subject |
Unique name (DN) of the owner |
Subject Public Key Info |
Public key of the owner and the ID of the algorithm |
Issuer Unique ID |
Unique ID of the issuing CA (optional) |
Subject Unique ID |
Unique ID of the owner (optional) |
Extensions |
Optional additional information, such as “KeyUsage” or “BasicConstraints” |
If a certificate becomes untrustworthy before it has expired, it must be blocked immediately. This can become necessary if, for example, the private key has accidentally been made public. Blocking certificates is especially important if the private key belongs to a CA rather than a user certificate. In this case, all user certificates issued by the relevant CA must be blocked immediately. If a certificate is blocked, the PKI (the responsible CA) must make this information available to all those involved using a certificate revocation list (CRL).
These lists are supplied by the CA to public CRL distribution points (CDPs) at regular intervals. The CDP can optionally be named as an extension in the certificate, so a checker can fetch a current CRL for validation purposes. One way to do this is the online certificate status protocol (OCSP). The authenticity of the CRLs is ensured with the signature of the issuing CA. Table 18.2 shows the basic parts of a X.509 CRL.
Field |
Content |
---|---|
Version |
The version of the CRL, such as v2 |
Signature |
The ID of the algorithm used to sign the CRL |
Issuer |
Unique name (DN) of the publisher of the CRL (usually the issuing CA) |
This Update |
Time of publication (date, time) of this CRL |
Next Update |
Time of publication (date, time) of the next CRL |
List of revoked certificates |
Every entry contains the serial number of the certificate, the time of revocation, and optional extensions (CRL entry extensions) |
Extensions |
Optional CRL extensions |
The certificates and CRLs for a CA must be made publicly accessible using a repository. Because the signature protects the certificates and CRLs from being forged, the repository itself does not need to be secured in a special way. Instead, it tries to grant the simplest and fastest access possible. For this reason, certificates are often provided on an LDAP or HTTP server. Find explanations about LDAP in Chapter 5, LDAP—A Directory Service. Book “Reference”, Chapter 24 “The Apache HTTP Server” contains information about the HTTP server.
YaST contains modules for the basic management of X.509 certificates. This mainly involves the creation of CAs, sub-CAs, and their certificates. The services of a PKI go far beyond simply creating and distributing certificates and CRLs. The operation of a PKI requires a well-conceived administrative infrastructure allowing continuous update of certificates and CRLs. This infrastructure is provided by commercial PKI products and can also be partly automated. YaST provides tools for creating and distributing CAs and certificates, but cannot currently offer this background infrastructure. To set up a small PKI, you can use the available YaST modules. However, you should use commercial products to set up an “official” or commercial PKI.
YaST provides two modules for basic CA management. The primary management tasks with these modules are explained here.
The first step when setting up a PKI is to create a root CA. Do the following:
Start YaST and go to
› .Click
.Enter the basic data for the CA in the first dialog, shown in Figure 18.1. The text boxes have the following meanings:
Enter the technical name of the CA. Directory names, among other things, are derived from this name, which is why only the characters listed in the help can be used. The technical name is also displayed in the overview when the module is started.
Enter the name for use in referring to the CA.
Several e-mail addresses can be entered that can be seen by the CA user. This can be helpful for inquiries.
Select the country where the CA is operated.
Optional values
Proceed with
.Enter a password in the second dialog. This password is always required when using the CA—when creating a sub-CA or generating certificates. The text boxes have the following meaning:
contains a meaningful default and does not generally need to be changed unless an application cannot deal with this key length. The higher the number the more secure your password is.
The
in the case of a CA defaults to 3650 days (roughly ten years). This long period makes sense because the replacement of a deleted CA involves an enormous administrative effort.Clicking Figure 18.4, “YaST CA Module—Extended Settings”). These values have rational default settings and should only be changed if you are really sure of what you are doing. Proceed with .
opens a dialog for setting different attributes from the X.509 extensions (Review the summary. YaST displays the current settings for confirmation. Click
. The root CA is created then appears in the overview.In general, it is best not to allow user certificates to be issued by the root CA. It is better to create at least one sub-CA and create the user certificates from there. This has the advantage that the root CA can be kept isolated and secure, for example, on an isolated computer on secure premises. This makes it very difficult to attack the root CA.
If you need to change your password for your CA, proceed as follows:
Start YaST and open the CA module.
Select the required root CA and click
.Enter the password if you entered a CA the first time. YaST displays the CA key information in the Figure 18.2).
tab (seeClick
and select . A dialog opens.Enter the old and the new password.
Finish with
A sub-CA is created in the same way as a root CA.
The validity period for a sub-CA must be fully within the validity period of the “parent” CA. A sub-CA is always created after the “parent” CA, therefore, the default value leads to an error message. To avoid this, enter a permissible value for the period of validity.
Do the following:
Start YaST and open the CA module.
Select the required root CA and click
.Enter the password if you are entering a CA for the first time. YaST displays the CA key information in the tab Figure 18.2).
(seeClick
and select . This opens the same dialog as for creating a root CA.Proceed as described in Section 18.2.1, “Creating a Root CA”.
It is possible to use one password for all your CAs. Enable
to give your sub-CAs the same password as your root CA. This helps to reduce the amount of passwords for your CAs.Take into account that the valid period must be lower than the valid period in the root CA.
Select the Section 18.2.6, “Creating Certificate Revocation Lists (CRLs)”.
tab. Reset compromised or otherwise unwanted sub-CAs here, using . Revocation alone is not enough to deactivate a sub-CA. You must also publish revoked sub-CAs in a CRL. The creation of CRLs is described inFinish with
.Creating client and server certificates is very similar to creating CAs in Section 18.2.1, “Creating a Root CA”. The same principles apply here. In certificates intended for e-mail signature, the e-mail address of the sender (the private key owner) should be contained in the certificate to enable the e-mail program to assign the correct certificate.
For certificate assignment during encryption, it is necessary for the e-mail address of the recipient (the public key owner) to be included in the certificate. In the case of server and client certificates, the host name of the server must be entered in the
field. The default validity period for certificates is 365 days.To create client and server certificates, do the following:
Start YaST and open the CA module.
Select the required root CA and click
.Enter the password if you are entering a CA for the first time. YaST displays the CA key information in the
tab.Click Figure 18.3).
(seeClick
› and create a server certificate.Click
› and create a client certificate. Do not forget to enter an e-mail address.Finish with
To revoke compromised or otherwise unwanted certificates, do the following:
Start YaST and open the CA module.
Select the required root CA and click
.Enter the password if you are entering a CA for the first time. YaST displays the CA key information in the
tab.Select the certificate to revoke and click
.Choose a reason to revoke this certificate.
Finish with
.Revocation alone is not enough to deactivate a certificate. Also publish revoked certificates in a CRL. Section 18.2.6, “Creating Certificate Revocation Lists (CRLs)” explains how to create CRLs. Revoked certificates can be completely removed after publication in a CRL with .
The previous sections explained how to create sub-CAs, client certificates, and server certificates. Special settings are used in the extensions of the X.509 certificate. These settings have been given rational defaults for every certificate type and do not normally need to be changed. However, it may be that you have special requirements for these extensions. In this case, it may make sense to adjust the defaults. Otherwise, start from scratch every time you create a certificate.
Start YaST and open the CA module.
Enter the required root CA, as described in Section 18.2.3, “Creating or Revoking a Sub-CA”.
Click
› .Choose type of certificate to change and proceed with
.The dialog for changing the defaults as shown in Figure 18.4, “YaST CA Module—Extended Settings” opens.
Change the associated value on the right side and set or delete the critical setting with
.Click
to see a short summary.Finish your changes with
.All changes to the defaults only affect objects created after this point. Already-existing CAs and certificates remain unchanged.
If compromised or otherwise unwanted certificates need to be excluded from further use, they must first be revoked. The procedure for this is explained in Section 18.2.3, “Creating or Revoking a Sub-CA” (for sub-CAs) and Section 18.2.4, “Creating or Revoking User Certificates” (for user certificates). After this, a CRL must be created and published with this information.
The system maintains only one CRL for each CA. To create or update this CRL, do the following:
Start YaST and open the CA module.
Enter the required CA, as described in Section 18.2.3, “Creating or Revoking a Sub-CA”.
Click
. The dialog that opens displays a summary of the last CRL of this CA.Create a new CRL with
if you have revoked new sub-CAs or certificates since its creation.Specify the period of validity for the new CRL (default: 30 days).
Click
to create and display the CRL. Afterward, you must publish this CRL.Applications that evaluate CRLs reject every certificate if the CRL is not available or has expired. As a PKI provider, it is your duty always to create and publish a new CRL before the current CRL expires (period of validity). YaST does not provide a function for automating this procedure.
The executing computer should be configured with the YaST LDAP client for LDAP export. This provides LDAP server information at runtime that can be used when completing dialog fields. Otherwise (although export may be possible), all LDAP data must be entered manually. You must always enter several passwords (see Table 18.3, “Passwords during LDAP Export”).
Password |
Meaning |
---|---|
LDAP Password |
Authorizes the user to make entries in the LDAP tree. |
Certificate Password |
Authorizes the user to export the certificate. |
New Certificate Password |
The PKCS12 format is used during LDAP export. This format forces the assignment of a new password for the exported certificate. |
Certificates, CAs, and CRLs can be exported to LDAP.
To export a CA, enter the CA as described in Section 18.2.3, “Creating or Revoking a Sub-CA”. Select › in the subsequent dialog, which opens the dialog for entering LDAP data. If your system has been configured with the YaST LDAP client, the fields are already partly completed. Otherwise, enter all the data manually. Entries are made in LDAP in a separate tree with the attribute “caCertificate”.
Enter the CA containing the certificate to export then select “userCertificate” (PEM format) and “userPKCS12” (PKCS12 format).
. Select the required certificate from the certificate list in the upper part of the dialog and select › . The LDAP data is entered here in the same way as for CAs. The certificate is saved with the corresponding user object in the LDAP tree with the attributesEnter the CA containing the CRL to export and select
. If desired, create a new CRL and click . The dialog that opens displays the export parameters. You can export the CRL for this CA either once or in periodical time intervals. Activate the export by selecting and enter the respective LDAP data. To do this at regular intervals, select the radio button and change the interval, if appropriate.If you have set up a repository on the computer for administering CAs, you can use this option to create the CA objects directly as a file at the correct location. Different output formats are available, such as PEM, DER, and PKCS12. In the case of PEM, it is also possible to choose whether a certificate should be exported with or without key and whether the key should be encrypted. In the case of PKCS12, it is also possible to export the certification path.
Export a file in the same way for certificates, CAs as with LDAP, described in Section 18.2.7, “Exporting CA Objects to LDAP”, except you should select instead of . This then takes you to a dialog for selecting the required output format and entering the password and file name. The certificate is stored at the required location after clicking .
For CRLs click
, select , choose the export format (PEM or DER) and enter the path. Proceed with to save it to the respective location.
You can select any storage location in the file system. This option can
also be used to save CA objects on a transport medium, such as a flash
disk. The /media
directory generally holds any
type of drive except the hard disk of your system.
If you have exported a server certificate with YaST to your media on an isolated CA management computer, you can import this certificate on a server as a common server certificate. Do this during installation or at a later point with YaST.
You need one of the PKCS12 formats to import your certificate successfully.
The general server certificate is stored in
/etc/ssl/servercerts
and can be used there by any
CA-supported service. When this certificate expires, it can easily be
replaced using the same mechanisms. To get things functioning with the
replaced certificate, restart the participating services.
If you select
here, you can select the source in the file system. This option can also be used to import certificates from removable media, such as a flash disk.To import a common server certificate, do the following:
Start YaST and open
underView the data for the current certificate in the description field after YaST has been started.
Select
and the certificate file.Enter the password and click
. The certificate is imported then displayed in the description field.Close YaST with
.Many security vulnerabilities result from bugs in trusted programs. A trusted program runs with privileges that attackers want to possess. The program fails to keep that trust if there is a bug in the program that allows the attacker to acquire said privilege.
Prepare a successful deployment of AppArmor on your system by carefully considering the following items:
Effective hardening of a computer system requires minimizing the number of programs that mediate privilege, then securing the programs as much as possible. With AppArmor, you only need to profile the programs that are exposed to attack in your environment, which drastically reduces the amount of wor…
Building AppArmor profiles to confine an application is very straightforward and intuitive. AppArmor ships with several tools that assist in profile creation. It does not require you to do any programming or script handling. The only task that is required of the administrator is to determine a polic…
AppArmor ships with a set of profiles enabled by default. These are created by the AppArmor developers, and are stored in /etc/apparmor.d. In addition to these profiles, openSUSE Leap ships profiles for individual applications together with the relevant application. These profiles are not enabled by…
YaST provides a basic way to build profiles and manage AppArmor® profiles. It provides two interfaces: a graphical one and a text-based one. The text-based interface consumes less resources and bandwidth, making it a better choice for remote administration, or for times when a local graphical enviro…
AppArmor® provides the user the ability to use a command line interface rather than a graphical interface to manage and configure the system security. Track the status of AppArmor and create, delete, or modify AppArmor profiles using the AppArmor command line tools.
An AppArmor® profile represents the security policy for an individual program instance or process. It applies to an executable program, but if a portion of the program needs different access permissions than other portions, the program can “change hats” to use a different security context, distincti…
pam_apparmor
An AppArmor profile applies to an executable program; if a portion of the program needs different access permissions than other portions need, the program can change hats via change_hat to a different role, also known as a subprofile. The pam_apparmor PAM module allows applications to confine authen…
After creating profiles and immunizing your applications, openSUSE® Leap becomes more efficient and better protected as long as you perform AppArmor® profile maintenance (which involves analyzing log files, refining your profiles, backing up your set of profiles and keeping it up-to-date). You can d…
This chapter outlines maintenance-related tasks. Learn how to update AppArmor® and get a list of available man pages providing basic help for using the command line tools provided by AppArmor. Use the troubleshooting section to learn about some common problems encountered with AppArmor and their sol…
Many security vulnerabilities result from bugs in trusted programs. A trusted program runs with privileges that attackers want to possess. The program fails to keep that trust if there is a bug in the program that allows the attacker to acquire said privilege.
AppArmor® is an application security solution designed specifically to apply privilege confinement to suspect programs. AppArmor allows the administrator to specify the domain of activities the program can perform by developing a security profile. A security profile is a listing of files that the program may access and the operations the program may perform. AppArmor secures applications by enforcing good application behavior without relying on attack signatures, so it can prevent attacks even if previously unknown vulnerabilities are being exploited.
AppArmor consists of:
A library of AppArmor profiles for common Linux* applications, describing what files the program needs to access.
A library of AppArmor profile foundation classes (profile building blocks) needed for common application activities, such as DNS lookup and user authentication.
A tool suite for developing and enhancing AppArmor profiles, so that you can change the existing profiles to suit your needs and create new profiles for your own local and custom applications.
Several specially modified applications that are AppArmor enabled to provide enhanced security in the form of unique subprocess confinement (including Apache).
The AppArmor-related kernel code and associated control scripts to enforce AppArmor policies on your openSUSE® Leap system.
For more information about the science and security of AppArmor, refer to the following papers:
Describes the initial design and implementation of AppArmor. Published in the proceedings of the USENIX LISA Conference, December 2000, New Orleans, LA. This paper is now out of date, describing syntax and features that are different from the current AppArmor product. This paper should be used only for background, and not for technical documentation.
A good guide to strategic and tactical use of AppArmor to solve severe security problems in a very short period of time. Published in the Proceedings of the DARPA Information Survivability Conference and Expo (DISCEX III), April 2003, Washington, DC.
This document tries to convey a better understanding of the technical details of AppArmor. It is available at http://en.opensuse.org/SDB:AppArmor_geeks.
Prepare a successful deployment of AppArmor on your system by carefully considering the following items:
Determine the applications to profile. Read more on this in Section 20.3, “Choosing Applications to Profile”.
Build the needed profiles as roughly outlined in Section 20.4, “Building and Modifying Profiles”. Check the results and adjust the profiles when necessary.
Update your profiles whenever your environment changes or you need to react to security events logged by the reporting tool of AppArmor. Refer to Section 20.5, “Updating Your Profiles”.
AppArmor is installed and running on any installation of openSUSE® Leap by default, regardless of what patterns are installed. The packages listed below are needed for a fully-functional instance of AppArmor:
apparmor-docs
apparmor-parser
apparmor-profiles
apparmor-utils
audit
libapparmor1
perl-libapparmor
yast2-apparmor
If AppArmor is not installed on your system, install the pattern
apparmor
for a complete
AppArmor installation. Either use the YaST Software Management
module for installation, or use Zypper on the command line:
tux >
sudo
zypper in -t pattern apparmor
AppArmor is configured to run by default on any fresh installation of openSUSE Leap. There are two ways of toggling the status of AppArmor:
Disable or enable AppArmor by removing or adding its boot script to the sequence of scripts executed on system boot. Status changes are applied on reboot.
Toggle the status of AppArmor in a running system by switching it off or on using the YaST AppArmor Control Panel. Changes made here are applied instantaneously. The Control Panel triggers a stop or start event for AppArmor and removes or adds its boot script in the system's boot sequence.
To disable AppArmor permanently (by removing it from the sequence of scripts executed on system boot) proceed as follows:
Start YaST.
Select
› .
Mark apparmor
by clicking its row in the list of
services, then click in the lower
part of the window. Check that changed to
in the apparmor
row.
Confirm with
.AppArmor will not be initialized on reboot, and stays inactive until you re-enable it. Re-enabling a service using the YaST tool is similar to disabling it.
Toggle the status of AppArmor in a running system by using the AppArmor Configuration window. These changes take effect when you apply them and survive a reboot of the system. To toggle the status of AppArmor, proceed as follows:
Start YaST, select
, and click in the main window.Enable AppArmor by checking or disable AppArmor by deselecting it.
Click
in the window.You only need to protect the programs that are exposed to attacks in your particular setup, so only use profiles for those applications you actually run. Use the following list to determine the most likely candidates:
Network Agents |
Web Applications |
Cron Jobs |
To find out which processes are currently running with open network ports
and might need a profile to confine them, run
aa-unconfined
as root
.
aa-unconfined
#19848 /usr/sbin/cupsd not confined 19887 /usr/sbin/sshd not confined 19947 /usr/lib/postfix/master not confined 1328 /usr/sbin/smbd confined by '/usr/sbin/smbd (enforce)'
Each of the processes in the above example labeled not
confined
might need a custom profile to confine it. Those
labeled confined by
are already protected by AppArmor.
For more information about choosing the right applications to profile, refer to Section 21.2, “Determining Programs to Immunize”.
AppArmor on openSUSE Leap ships with a preconfigured set of profiles for the most important applications. In addition, you can use AppArmor to create your own profiles for any application you want.
There are two ways of managing profiles. One is to use the graphical front-end provided by the YaST AppArmor modules and the other is to use the command line tools provided by the AppArmor suite itself. The main difference is that YaST supports only basic functionality for AppArmor profiles, while the command line tools let you update/tune the profiles in a more fine-grained way.
For each application, perform the following steps to create a profile:
As root
, let AppArmor create a rough outline of the
application's profile by running aa-genprof
PROGRAM_NAME.
or
Outline the basic profile by running
› › › and specifying the complete path to the application you want to profile.A new basic profile is outlined and put into learning mode, which means that it logs any activity of the program you are executing, but does not yet restrict it.
Run the full range of the application's actions to let AppArmor get a very specific picture of its activities.
Let AppArmor analyze the log files generated in Step 2 by typing S in aa-genprof.
AppArmor scans the logs it recorded during the application's run and asks you to set the access rights for each event that was logged. Either set them for each file or use globbing.
Depending on the complexity of your application, it might be necessary to repeat Step 2 and Step 3. Confine the application, exercise it under the confined conditions, and process any new log events. To properly confine the full range of an application's capabilities, you might be required to repeat this procedure often.
When you finish aa-genprof
, your profile is set to
enforce mode. The profile is applied and AppArmor restricts the
application according to it.
If you started aa-genprof
on an application that had
an existing profile that was in complain mode, this profile remains in
learning mode upon exit of this learning cycle. For more information
about changing the mode of a profile, refer to
Section 25.7.3.2, “aa-complain—Entering Complain or Learning Mode”
and
Section 25.7.3.6, “aa-enforce—Entering Enforce Mode”.
Test your profile settings by performing every task you need with the application you confined. Normally, the confined program runs smoothly and you do not notice AppArmor activities. However, if you notice certain misbehavior with your application, check the system logs and see if AppArmor is too tightly confining your application. Depending on the log mechanism used on your system, there are several places to look for AppArmor log entries:
/var/log/audit/audit.log
|
The command journalctl | grep -i apparmor
|
The command dmesg -T
|
To adjust the profile, analyze the log messages relating to this application again as described in Section 25.7.3.9, “aa-logprof—Scanning the System Log”. Determine the access rights or restrictions when prompted.
For more information about profile building and modification, refer to Chapter 22, Profile Components and Syntax, Chapter 24, Building and Managing Profiles with YaST, and Chapter 25, Building Profiles from the Command Line.
Software and system configurations change over time. As a result, your
profile setup for AppArmor might need some fine-tuning from time to time.
AppArmor checks your system log for policy violations or other AppArmor
events and lets you adjust your profile set accordingly. Any application
behavior that is outside of any profile definition can be addressed by
aa-logprof
. For more information, see
Section 25.7.3.9, “aa-logprof—Scanning the System Log”.
Effective hardening of a computer system requires minimizing the number of programs that mediate privilege, then securing the programs as much as possible. With AppArmor, you only need to profile the programs that are exposed to attack in your environment, which drastically reduces the amount of work required to harden your computer. AppArmor profiles enforce policies to make sure that programs do what they are supposed to do, but nothing else.
AppArmor provides immunization technologies that protect applications from the inherent vulnerabilities they possess. After installing AppArmor, setting up AppArmor profiles, and rebooting the computer, your system becomes immunized because it begins to enforce the AppArmor security policies. Protecting programs with AppArmor is called immunizing.
Administrators need only concern themselves with the applications that are vulnerable to attacks, and generate profiles for these. Hardening a system thus comes down to building and maintaining the AppArmor profile set and monitoring any policy violations or exceptions logged by AppArmor's reporting facility.
Users should not notice AppArmor. It runs “behind the scenes” and does not require any user interaction. Performance is not noticeably affected by AppArmor. If some activity of the application is not covered by an AppArmor profile or if some activity of the application is prevented by AppArmor, the administrator needs to adjust the profile of this application.
AppArmor sets up a collection of default application profiles to protect standard Linux services. To protect other applications, use the AppArmor tools to create profiles for the applications that you want protected. This chapter introduces the philosophy of immunizing programs. Proceed to Chapter 22, Profile Components and Syntax, Chapter 24, Building and Managing Profiles with YaST, or Chapter 25, Building Profiles from the Command Line if you are ready to build and manage AppArmor profiles.
AppArmor provides streamlined access control for network services by specifying which files each program is allowed to read, write, and execute, and which type of network it is allowed to access. This ensures that each program does what it is supposed to do, and nothing else. AppArmor quarantines programs to protect the rest of the system from being damaged by a compromised process.
AppArmor is a host intrusion prevention or mandatory access control scheme. Previously, access control schemes were centered around users because they were built for large timeshare systems. Alternatively, modern network servers largely do not permit users to log in, but instead provide a variety of network services for users (such as Web, mail, file, and print servers). AppArmor controls the access given to network services and other programs to prevent weaknesses from being exploited.
To get a more in-depth overview of AppArmor and the overall concept behind it, refer to Section 19.2, “Background Information on AppArmor Profiling”.
This section provides a very basic understanding of what is happening “behind the scenes” (and under the hood of the YaST interface) when you run AppArmor.
An AppArmor profile is a plain text file containing path entries and access permissions. See Section 22.1, “Breaking an AppArmor Profile into Its Parts” for a detailed reference profile. The directives contained in this text file are then enforced by the AppArmor routines to quarantine the process or program.
The following tools interact in the building and enforcement of AppArmor profiles and policies:
aa-status
aa-status
reports various aspects of the current
state of the running AppArmor confinement.
aa-unconfined
aa-unconfined
detects any application running on
your system that listens for network connections and is not protected
by an AppArmor profile. Refer to
Section 25.7.3.12, “aa-unconfined—Identifying Unprotected Processes”
for detailed information about this tool.
aa-autodep
aa-autodep
creates a basic framework of a profile
that needs to be fleshed out before it is put to use in production.
The resulting profile is loaded and put into complain mode, reporting
any behavior of the application that is not (yet) covered by AppArmor
rules. Refer to
Section 25.7.3.1, “aa-autodep—Creating Approximate Profiles”
for detailed information about this tool.
aa-genprof
aa-genprof
generates a basic profile and asks you
to refine this profile by executing the application and generating log
events that need to be taken care of by AppArmor policies. You are
guided through a series of questions to deal with the log events that
have been triggered during the application's execution. After the
profile has been generated, it is loaded and put into enforce mode.
Refer to
Section 25.7.3.8, “aa-genprof—Generating Profiles”
for detailed information about this tool.
aa-logprof
aa-logprof
interactively scans and reviews the log
entries generated by an application that is confined by an AppArmor
profile in both complain and enforced modes. It assists you in
generating new entries in the profile concerned. Refer to
Section 25.7.3.9, “aa-logprof—Scanning the System Log”
for detailed information about this tool.
aa-easyprof
aa-easyprof
provides an easy-to-use interface for
AppArmor profile generation. aa-easyprof
supports
the use of templates and policy groups to quickly profile an
application. Note that while this tool can help with policy
generation, its utility is dependent on the quality of the templates,
policy groups and abstractions used. aa-easyprof
may create a profile that is less restricted than creating the profile
with aa-genprof
and aa-logprof
.
aa-complain
aa-complain
toggles the mode of an AppArmor profile
from enforce to complain. Violations to rules set in a profile are
logged, but the profile is not enforced. Refer to
Section 25.7.3.2, “aa-complain—Entering Complain or Learning Mode”
for detailed information about this tool.
aa-enforce
aa-enforce
toggles the mode of an AppArmor profile
from complain to enforce. Violations to rules set in a profile are
logged and not permitted—the profile is enforced. Refer to
Section 25.7.3.6, “aa-enforce—Entering Enforce Mode”
for detailed information about this tool.
aa-disable
aa-disable
disables the enforcement mode for one or
more AppArmor profiles. This command will unload the profile from the
kernel and prevent it from being loaded on AppArmor start-up. The
aa-enforce
and aa-complain
utilities may be used to change this behavior.
aa-exec
aa-exec
launches a program confined by the
specified AppArmor profile and/or namespace. If both a profile and
namespace are specified, the command will be confined by the profile
in the new policy namespace. If only a namespace is specified, the
profile name of the current confinement will be used. If neither a
profile or namespace is specified, the command will be run using
standard profile attachment—as if run without
aa-exec
.
aa-notify
aa-notify
is a handy utility that displays AppArmor
notifications in your desktop environment. You can also configure it
to display a summary of notifications for the specified number of
recent days. For more information, see
Section 25.7.3.13, “aa-notify”.
Now that you have familiarized yourself with AppArmor, start selecting the applications for which to build profiles. Programs that need profiling are those that mediate privilege. The following programs have access to resources that the person using the program does not have, so they grant the privilege to the user when used:
cron
Jobs
Programs that are run periodically by
cron
. Such programs read input
from a variety of sources and can run with special privileges,
sometimes with as much as root
privilege. For example,
cron
can run
/usr/sbin/logrotate
daily to rotate, compress, or
even mail system logs. For instructions for finding these types of
programs, refer to
Section 21.3, “Immunizing cron
Jobs”.
Programs that can be invoked through a Web browser, including CGI Perl scripts, PHP pages, and more complex Web applications. For instructions for finding these types of programs, refer to Section 21.4.1, “Immunizing Web Applications”.
Programs (servers and clients) that have open network ports. User clients, such as mail clients and Web browsers mediate privilege. These programs run with the privilege to write to the user's home directory and they process input from potentially hostile remote sources, such as hostile Web sites and e-mailed malicious code. For instructions for finding these types of programs, refer to Section 21.4.2, “Immunizing Network Agents”.
Conversely, unprivileged programs do not need to be profiled. For
example, a shell script might invoke the cp
program to copy a file. Because cp
does not by
default have its own profile or subprofile, it inherits the profile
of the parent shell script. Thus cp
can copy any
files that the parent shell script's profile can read and write.
cron
Jobs #
To find programs that are run by
cron
, inspect your local
cron
configuration.
Unfortunately, cron
configuration
is rather complex, so there are numerous files to inspect. Periodic
cron
jobs are run from these
files:
/etc/crontab /etc/cron.d/* /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/*
The crontab
command lists/edits the current user's
crontab. To manipulate root
's
cron
jobs, first become
root
, and then edit the tasks with crontab -e
or list them with crontab -l
.
An automated method for finding network server daemons that should be
profiled is to use the aa-unconfined
tool.
The aa-unconfined
tool uses the command
netstat -nlp
to inspect open ports from inside your
computer, detect the programs associated with those ports, and inspect
the set of AppArmor profiles that you have loaded.
aa-unconfined
then reports these programs along with
the AppArmor profile associated with each program, or reports
“none” (if the program is not confined).
If you create a new profile, you must restart the program that has been profiled to have it be effectively confined by AppArmor.
Below is a sample aa-unconfined
output:
37021 /usr/sbin/sshd2 confined by '/usr/sbin/sshd3 (enforce)' 4040 /usr/sbin/smbd confined by '/usr/sbin/smbd (enforce)' 4373 /usr/lib/postfix/master confined by '/usr/lib/postfix/master (enforce)' 4505 /usr/sbin/httpd2-prefork confined by '/usr/sbin/httpd2-prefork (enforce)' 646 /usr/lib/wicked/bin/wickedd-dhcp4 not confined 647 /usr/lib/wicked/bin/wickedd-dhcp6 not confined 5592 /usr/bin/ssh not confined 7146 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (complain)'
The first portion is a number. This number is the process ID number (PID) of the listening program. | |
The second portion is a string that represents the absolute path of the listening program | |
The final portion indicates the profile confining the program, if any. |
aa-unconfined
requires root
privileges and
should not be run from a shell that is confined by an AppArmor profile.
aa-unconfined
does not distinguish between one network
interface and another, so it reports all unconfined processes, even those
that might be listening to an internal LAN interface.
Finding user network client applications is dependent on your user
preferences. The aa-unconfined
tool detects and
reports network ports opened by client applications, but only those
client applications that are running at the time the
aa-unconfined
analysis is performed. This is a problem
because network services tend to be running all the time, while network
client applications tend only to be running when the user is interested
in them.
Applying AppArmor profiles to user network client applications is also dependent on user preferences. Therefore, we leave the profiling of user network client applications as an exercise for the user.
To aggressively confine desktop applications, the
aa-unconfined
command supports a
--paranoid
option, which reports all processes running
and the corresponding AppArmor profiles that might or might not be
associated with each process. The user can then decide whether each of
these programs needs an AppArmor profile.
If you have new or modified profiles, you can submit them to the <apparmor@lists.ubuntu.com> mailing list along with a use case for the application behavior that you exercised. The AppArmor team reviews and may submit the work into openSUSE Leap. We cannot guarantee that every profile will be included, but we make a sincere effort to include as much as possible.
To find Web applications, investigate your Web server configuration. The
Apache Web server is highly configurable and Web applications can be
stored in many directories, depending on your local configuration.
openSUSE Leap, by default, stores Web applications in
/srv/www/cgi-bin/
. To the maximum extent possible,
each Web application should have an AppArmor profile.
Once you find these programs, you can use the
aa-genprof
and aa-logprof
tools to
create or update their AppArmor profiles.
Because CGI programs are executed by the Apache Web server, the profile
for Apache itself, usr.sbin.httpd2-prefork
for
Apache2 on openSUSE Leap, must be modified to add execute permissions
to each of these programs. For example, adding the line
/srv/www/cgi-bin/my_hit_counter.pl rPx
grants Apache
permission to execute the Perl script
my_hit_counter.pl
and requires that there be a
dedicated profile for my_hit_counter.pl
. If
my_hit_counter.pl
does not have a dedicated profile
associated with it, the rule should say
/srv/www/cgi-bin/my_hit_counter.pl rix
to cause
my_hit_counter.pl
to inherit the
usr.sbin.httpd2-prefork
profile.
Some users might find it inconvenient to specify execute permission for
every CGI script that Apache might invoke. Instead, the administrator
can grant controlled access to collections of CGI scripts. For example,
adding the line /srv/www/cgi-bin/*.{pl,py,pyc} rix
allows Apache to execute all files in
/srv/www/cgi-bin/
ending in .pl
(Perl scripts) and .py
or .pyc
(Python scripts). As above, the ix
part of the rule
causes Python scripts to inherit the Apache profile, which is
appropriate if you do not want to write individual profiles for each CGI
script.
If you want the subprocess confinement module
(apache2-mod-apparmor
) functionality when Web
applications handle Apache modules (mod_perl
and
mod_php
), use the ChangeHat features when you add
a profile in YaST or at the command line. To take advantage of the
subprocess confinement, refer to
Section 26.2, “Managing ChangeHat-Aware Applications”.
Profiling Web applications that use mod_perl
and
mod_php
requires slightly different handling. In
this case, the “program” is a script interpreted directly
by the module within the Apache process, so no exec happens. Instead,
the AppArmor version of Apache calls change_hat()
using a subprofile (a “hat”) corresponding to the name of
the URI requested.
The name presented for the script to execute might not be the URI, depending on how Apache has been configured for where to look for module scripts. If you have configured your Apache to place scripts in a different place, the different names appear in the log file when AppArmor complains about access violations. See Chapter 28, Managing Profiled Applications.
For mod_perl
and mod_php
scripts, this is the name of the Perl script or the PHP page requested.
For example, adding this subprofile allows the
localtime.php
page to execute and access to the
local system time and locale files:
/usr/bin/httpd2-prefork { # ... ^/cgi-bin/localtime.php { /etc/localtime r, /srv/www/cgi-bin/localtime.php r, /usr/lib/locale/** r, } }
If no subprofile has been defined, the AppArmor version of Apache applies
the DEFAULT_URI
hat. This subprofile is
sufficient to display a Web page. The
DEFAULT_URI
hat that AppArmor provides by
default is the following:
^DEFAULT_URI { /usr/sbin/suexec2 mixr, /var/log/apache2/** rwl, @{HOME}/public_html r, @{HOME}/public_html/** r, /srv/www/htdocs r, /srv/www/htdocs/** r, /srv/www/icons/*.{gif,jpg,png} r, /srv/www/vhosts r, /srv/www/vhosts/** r, /usr/share/apache2/** r, /var/lib/php/sess_* rwl }
To use a single AppArmor profile for all Web pages and CGI scripts served
by Apache, a good approach is to edit the
DEFAULT_URI
subprofile. For more information on
confining Web applications with Apache, see
Chapter 26, Profiling Your Web Applications Using ChangeHat.
To find network server daemons and network clients (such as
fetchmail
or Firefox) that need to be profiled,
you should inspect the open ports on your machine. Also consider
the programs that are answering on those ports, and provide profiles
for as many of those programs as possible. If you provide profiles
for all programs with open network ports, an attacker cannot get to
the file system on your machine without passing through an AppArmor
profile policy.
Scan your server for open network ports manually from outside the
machine using a scanner (such as nmap), or from inside the machine using
the netstat --inet -n -p
command as root
.
Then, inspect the machine to determine which programs are answering on
the discovered open ports.
Refer to the man page of the netstat
command for a
detailed reference of all possible options.
Building AppArmor profiles to confine an application is very straightforward and intuitive. AppArmor ships with several tools that assist in profile creation. It does not require you to do any programming or script handling. The only task that is required of the administrator is to determine a policy of strictest access and execute permissions for each application that needs to be hardened.
Updates or modifications to the application profiles are only required if the software configuration or the desired range of activities changes. AppArmor offers intuitive tools to handle profile updates and modifications.
You are ready to build AppArmor profiles after you select the programs to profile. To do so, it is important to understand the components and syntax of profiles. AppArmor profiles contain several building blocks that help build simple and reusable profile code:
Include statements are used to pull in parts of other AppArmor profiles to simplify the structure of new profiles.
Abstractions are include statements grouped by common application tasks.
Program chunks are include statements that contain chunks of profiles that are specific to program suites.
Capability entries are profile entries for any of the POSIX.1e http://en.wikipedia.org/wiki/POSIX#POSIX.1 Linux capabilities allowing a fine-grained control over what a confined process is allowed to do through system calls that require privileges.
Network Access Control Entries mediate network access based on the address type and family.
Local variables define shortcuts for paths.
File Access Control Entries specify the set of files an application can access.
rlimit entries set and control an application's resource limits.
For help determining the programs to profile, refer to Section 21.2, “Determining Programs to Immunize”. To start building AppArmor profiles with YaST, proceed to Chapter 24, Building and Managing Profiles with YaST. To build profiles using the AppArmor command line interface, proceed to Chapter 25, Building Profiles from the Command Line.
For more details about creating AppArmor profiles, see
man 5 apparmor
.
The easiest way of explaining what a profile consists of and how to
create one is to show the details of a sample profile, in this case for a
hypothetical application called /usr/bin/foo
:
#include <tunables/global>1 # a comment naming the application to confine /usr/bin/foo2 {3 #include <abstractions/base>4 capability setgid5, network inet tcp6, link /etc/sysconfig/foo -> /etc/foo.conf,7 /bin/mount ux, /dev/{,u}8random r, /etc/ld.so.cache r, /etc/foo/* r, /lib/ld-*.so* mr, /lib/lib*.so* mr, /proc/[0-9]** r, /usr/lib/** mr, /tmp/ r,9 /tmp/foo.pid wr, /tmp/foo.* lrw, /@{HOME}10/.foo_file rw, /@{HOME}/.foo_lock kw, owner11 /shared/foo/** rw, /usr/bin/foobar Cx,12 /bin/** Px -> bin_generic,13 # a comment about foo's local (children) profile for /usr/bin/foobar. profile /usr/bin/foobar14 { /bin/bash rmix, /bin/cat rmix, /bin/more rmix, /var/log/foobar* rwl, /etc/foobar r, } # foo's hat, bar. ^bar15 { /lib/ld-*.so* mr, /usr/bin/bar px, /var/spool/* rwl, } }
This loads a file containing variable definitions. | |
The normalized path to the program that is confined. | |
The curly braces ( | |
This directive pulls in components of AppArmor profiles to simplify profiles. | |
Capability entry statements enable each of the 29 POSIX.1e draft capabilities. | |
A directive determining the kind of network access allowed to the application. For details, refer to Section 22.5, “Network Access Control”. | |
A link pair rule specifying the source and the target of a link. See Section 22.7.6, “Link Pair” for more information. | |
The curly braces ( | |
A path entry specifying what areas of the file system the program can
access. The first part of a path entry specifies the absolute path of a
file (including regular expression globbing) and the second part
indicates permissible access modes (for example | |
This variable expands to a value that can be changed without changing the entire profile. | |
An owner conditional rule, granting read and write permission on files owned by the user. Refer to Section 22.7.8, “Owner Conditional Rules” for more information. | |
This entry defines a transition to the local profile
| |
A named profile transition to the profile bin_generic located in the global scope. See Section 22.12.7, “Named Profile Transitions” for details. | |
The local profile | |
This section references a “hat” subprofile of the application. For more details on AppArmor's ChangeHat feature, refer to Chapter 26, Profiling Your Web Applications Using ChangeHat. |
When a profile is created for a program, the program can access only the files, modes, and POSIX capabilities specified in the profile. These restrictions are in addition to the native Linux access controls.
Example:
To gain the capability CAP_CHOWN
, the
program must have both access to CAP_CHOWN
under conventional Linux access controls (typically, be a
root
-owned process) and have the capability
chown
in its profile. Similarly, to be able
to write to the file /foo/bar
the program must
have both the correct user ID and mode bits set in the files
attributes and have /foo/bar w
in its profile.
Attempts to violate AppArmor rules are recorded in
/var/log/audit/audit.log
if the
audit
package is installed, or
in /var/log/messages
, or only in
journalctl
if no traditional syslog is
installed. Often AppArmor rules prevent an attack from working
because necessary files are not accessible and, in all cases, AppArmor
confinement restricts the damage that the attacker can do to the set of
files permitted by AppArmor.
AppArmor knows four different types of profiles: standard profiles,
unattached profiles, local profiles and hats. Standard and unattached
profiles are stand-alone profiles, each stored in a file under
/etc/apparmor.d/
. Local profiles and hats are
children profiles embedded inside of a parent profile used to provide
tighter or alternate confinement for a subtask of an application.
The default AppArmor profile is attached to a program by its name, so a profile name must match the path to the application it is to confine.
/usr/bin/foo { ... }
This profile will be automatically used whenever an unconfined process
executes /usr/bin/foo
.
Unattached profiles do not reside in the file system namespace and
therefore are not automatically attached to an application. The name of
an unattached profile is preceded by the keyword
profile
. You can freely choose a profile name, except
for the following limitations: the name must not begin with a
:
or .
character. If it contains a
whitespace, it must be quoted. If the name begins with a
/
, the profile is considered to be a standard
profile, so the following two profiles are identical:
profile /usr/bin/foo { ... } /usr/bin/foo { ... }
Unattached profiles are never used automatically, nor can they be
transitioned to through a Px
rule. They need to be
attached to a program by either using a named profile transition (see
Section 22.12.7, “Named Profile Transitions”) or with the
change_profile
rule (see
Section 22.2.5, “Change rules”).
Unattached profiles are useful for specialized profiles for system
utilities that generally should not be confined by a system-wide profile
(for example, /bin/bash
). They can also be used to
set up roles or to confine a user.
Local profiles provide a convenient way to provide specialized
confinement for utility programs launched by a confined application.
They are specified like standard profiles, except that they are embedded
in a parent profile and begin with the profile
keyword:
/parent/profile { ... profile /local/profile { ... } }
To transition to a local profile, either use a cx
rule (see Section 22.12.2, “Discrete Local Profile Execute Mode (Cx)”) or a named
profile transition (see
Section 22.12.7, “Named Profile Transitions”).
AppArmor "hats" are a local profiles with some additional restrictions
and an implicit rule allowing for change_hat
to be
used to transition to them. Refer to Chapter 26, Profiling Your Web Applications Using ChangeHat
for a detailed description.
AppArmor provides change_hat
and
change_profile
rules that control domain
transitioning. change_hat
are specified by defining
hats in a profile, while change_profile
rules refer
to another profile and start with the keyword
change_profile
:
change_profile -> /usr/bin/foobar,
Both change_hat
and change_profile
provide for an application directed profile transition, without having
to launch a separate application. change_profile
provides a generic one way transition between any of the loaded
profiles. change_hat
provides for a returnable parent
child transition where an application can switch from the parent profile
to the hat profile and if it provides the correct secret key return to
the parent profile at a later time.
change_profile
is best used in situations where an
application goes through a trusted setup phase and then can lower its
privilege level. Any resources mapped or opened during the start-up
phase may still be accessible after the profile change, but the new
profile will restrict the opening of new resources, and will even limit
some resources opened before the switch. Specifically, memory
resources will still be available while capability and file resources
(as long as they are not memory mapped) can be limited.
change_hat
is best used in situations where an
application runs a virtual machine or an interpreter that does not
provide direct access to the applications resources (for example
Apache's mod_php
). Since
change_hat
stores the return secret key in the
application's memory the phase of reduced privilege should not have
direct access to memory. It is also important that file access is
properly separated, since the hat can restrict accesses to a file handle
but does not close it. If an application does buffering and provides
access to the open files with buffering, the accesses to these files
might not be seen by the kernel and hence not restricted by the new
profile.
The change_hat
and change_profile
domain transitions are less secure than a domain transition done
through an exec because they do not affect a process's memory mappings,
nor do they close resources that have already been opened.
Include statements are directives that pull in components of other AppArmor profiles to simplify profiles. Include files retrieve access permissions for programs. By using an include, you can give the program access to directory paths or files that are also required by other programs. Using includes can reduce the size of a profile.
Include statements normally begin with a hash (#
)
sign. This is confusing because the same hash sign is used for comments
inside profile files. Because of this, #include
is
treated as an include only if there is no preceding #
(##include
is a comment) and there is no whitespace
between #
and include
(#
include
is a comment).
You can also use include
without the leading
#
.
include "/etc/apparmor.d/abstractions/foo"
is the same as using
#include "/etc/apparmor.d/abstractions/foo"
Note that because includes follow the C pre-processor syntax, they do not have a trailing ',' like most AppArmor rules.
By slight changes in syntax, you can modify the behavior of
include
. If you use ""
around the
including path, you instruct the parser to do an absolute or relative
path lookup.
include "/etc/apparmor.d/abstractions/foo" # absolute path include "abstractions/foo" # relative path to the directory of current file
Note that when using relative path includes, when the file is included,
it is considered the new current file for its includes. For example,
suppose you are in the /etc/apparmor.d/bar
file,
then
include "abstractions/foo"
includes the file /etc/apparmor.d/abstractions/foo
.
If then there is
include "example"
inside the /etc/apparmor.d/abstractions/foo
file, it
includes /etc/apparmor.d/abstractions/example
.
The use of <>
specifies to try the include
path (specified by -I
, defaults to the
/etc/apparmor.d
directory) in an ordered way. So
assuming the include path is
-I /etc/apparmor.d/ -I /usr/share/apparmor/
then the include statement
include <abstractions/foo>
will try /etc/apparmor.d/abstractions/foo
, and if
that file does not exist, the next try is
/usr/share/apparmor/abstractions/foo
.
The default include path can be overridden manually by passing
-I
to the apparmor_parser
, or by
setting the include paths in
/etc/apparmor/parser.conf
:
Include /usr/share/apparmor/ Include /etc/apparmor.d/
Multiple entries are allowed, and they are taken in the same order as
when they are when using -I
or
--Include
from the apparmor_parser
command line.
If an include ends with '/', this is considered a directory include, and all files within the directory are included.
To assist you in profiling your applications, AppArmor provides three classes of includes: abstractions, program chunks and tunables.
Abstractions are includes that are grouped by common application tasks.
These tasks include access to authentication mechanisms, access to name
service routines, common graphics requirements, and system accounting.
Files listed in these abstractions are specific to the named task.
Programs that require one of these files usually also require
other files listed in the abstraction file (depending on the local
configuration and the specific requirements of the program). Find
abstractions in /etc/apparmor.d/abstractions
.
The program-chunks directory
(/etc/apparmor.d/program-chunks
) contains some
chunks of profiles that are specific to program suites and not generally
useful outside of the suite, thus are never suggested for use in
profiles by the profile wizards (aa-logprof
and
aa-genprof
). Currently, program chunks are only
available for the postfix program suite.
The tunables directory (/etc/apparmor.d/tunables
)
contains global variable definitions. When used in a profile, these
variables expand to a value that can be changed without changing the
entire profile. Add all the tunables definitions that should be
available to every profile to
/etc/apparmor.d/tunables/global
.
Capability rules are simply the word capability
followed by the name of the POSIX.1e capability as defined in the
capabilities(7)
man page. You can list multiple
capabilities in a single rule, or grant all implemented capabilities with
the bare keyword capability
.
capability dac_override sys_admin, # multiple capabilities capability, # grant all capabilities
AppArmor allows mediation of network access based on the address type and family. The following illustrates the network access rule syntax:
network [[<domain>1][<type2>][<protocol3>]]
Supported domains: | |
Supported types: | |
Supported protocols: |
The AppArmor tools support only family and type specification. The AppArmor
module emits only network DOMAIN
TYPE
in “ACCESS DENIED”
messages. And only these are output by the profile generation tools, both
YaST and command line.
The following examples illustrate possible network-related rules to be used in AppArmor profiles. Note that the syntax of the last two are not currently supported by the AppArmor tools.
network1, network inet2, network inet63, network inet stream4, network inet tcp5, network tcp6,
Allow all networking. No restrictions applied with regard to domain, type, or protocol. | |
Allow general use of IPv4 networking. | |
Allow general use of IPv6 networking. | |
Allow the use of IPv4 TCP networking. | |
Allow the use of IPv4 TCP networking, paraphrasing the rule above. | |
Allow the use of both IPv4 and IPv6 TCP networking. |
A profile is usually attached to a program by specifying a full path to the program's executable. For example in the case of a standard profile (see Section 22.2.1, “Standard Profiles”), the profile is defined by
/usr/bin/foo { ... }
The following sections describe several useful techniques that can be applied when naming a profile or putting a profile in the context of other existing ones, or specifying file paths.
AppArmor explicitly distinguishes directory path names from file path
names. Use a trailing /
for any directory path that
needs to be explicitly distinguished:
/some/random/example/* r
Allow read access to files in the
/some/random/example
directory.
/some/random/example/ r
Allow read access to the directory only.
/some/**/ r
Give read access to any directories below /some
(but not /some/ itself).
/some/random/example/** r
Give read access to files and directories under
/some/random/example
(but not
/some/random/example/ itself).
/some/random/example/**[^/] r
Give read access to files under
/some/random/example
. Explicitly exclude
directories ([^/]
).
Globbing (or regular expression matching) is when you modify the directory path using wild cards to include a group of files or subdirectories. File resources can be specified with a globbing syntax similar to that used by popular shells, such as csh, Bash, and zsh.
|
Substitutes for any number of any characters, except
Example: An arbitrary number of file path elements. |
|
Substitutes for any number of characters, including
Example: An arbitrary number of path elements, including entire directories. |
|
Substitutes for any single character, except |
|
Substitutes for the single character
Example: a rule that matches |
|
Substitutes for the single character |
|
Expands to one rule to match
Example: a rule that matches |
|
Substitutes for any character except |
Profile flags control the behavior of the related profile. You can add profile flags to the profile definition by editing it manually, see the following syntax:
/path/to/profiled/binary flags=(list_of_flags) { [...] }
You can use multiple flags separated by a comma ',' or space ' '. There are three basic types of profile flags: mode, relative, and attach flags.
Mode flag is complain
(illegal
accesses are allowed and logged). If it is omitted, the profile is in
enforce
mode (enforces the policy).
A more flexible way of setting the whole profile into complain mode is
to create a symbolic link from the profile file inside the
/etc/apparmor.d/force-complain/
directory.
ln -s /etc/apparmor.d/bin.ping /etc/apparmor.d/force-complain/bin.ping
Relative flags are
chroot_relative
(states that the profile is relative
to the chroot instead of namespace) or
namespace_relative
(the default, with the path being
relative to outside the chroot). They are mutually exclusive.
Attach flags consist of two pairs of mutually
exclusive flags: attach_disconnected
or
no_attach_disconnected
(determine if path names
resolved to be outside of the namespace are attached to the root, which
means they have the '/' character at the beginning), and
chroot_attach
or chroot_no_attach
(control path name generation when in a chroot environment while a file
is accessed that is external to the chroot but within the namespace).
AppArmor allows to use variables holding paths in profiles. Use global variables to make your profiles portable and local variables to create shortcuts for paths.
A typical example of when global variables come in handy are network
scenarios in which user home directories are mounted in different
locations. Instead of rewriting paths to home directories in all
affected profiles, you only need to change the value of a variable.
Global variables are defined under
/etc/apparmor.d/tunables
and need to be made
available via an include statement. Find the variable definitions for
this use case (@{HOME}
and @{HOMEDIRS}
) in
the /etc/apparmor.d/tunables/home
file.
Local variables are defined at the head of a profile. This is useful to provide the base of for a chrooted path, for example:
@{CHROOT_BASE}=/tmp/foo /sbin/rsyslogd { ... # chrooted applications @{CHROOT_BASE}/var/lib/*/dev/log w, @{CHROOT_BASE}/var/log/** w, ... }
In the following example, while @{HOMEDIRS} lists where all the user home directories are stored, @{HOME} is a space-separated list of home directories. Later on, @{HOMEDIRS} is expanded by two new specific places where user home directories are stored.
@{HOMEDIRS}=/home/ @{HOME}=@{HOMEDIRS}/*/ /root/ [...] @{HOMEDIRS}+=/srv/nfs/home/ /mnt/home/
With the current AppArmor tools, variables can only be used when manually editing and maintaining a profile.
Profile names can contain globbing expressions allowing the profile to match against multiple binaries.
The following example is valid for systems where the
foo
binary resides either in
/usr/bin
or /bin
.
/{usr/,}bin/foo { ... }
In the following example, when matching against the executable
/bin/foo
, the /bin/foo
profile
is an exact match so it is chosen. For the executable
/bin/fat
, the profile /bin/foo
does not match, and because the /bin/f*
profile is
more specific (less general) than /bin/**
, the
/bin/f*
profile is chosen.
/bin/foo { ... } /bin/f* { ... } /bin/** { ... }
For more information on profile name globbing examples, see the man page
of AppArmor, man 5 apparmor.d,
, section
Globbing
.
Namespaces are used to provide different profiles sets. Say one for the
system, another for a chroot environment or container. Namespaces are
hierarchical—a namespace can see its children but a child
cannot see its parent. Namespace names start with a colon
:
followed by an alphanumeric string, a trailing
colon :
and an optional double slash
//
, such as
:childNameSpace://
Profiles loaded to a child namespace will be prefixed with their namespace name (viewed from a parent's perspective):
:childNameSpace://apache
Namespaces can be entered via the change_profile
API,
or named profile transitions:
/path/to/executable px -> :childNameSpace://apache
Profiles can have a name, and an attachment specification. This allows for profiles with a logical name that can be more meaningful to users/administrators than a profile name that contains pattern matching (see Section 22.6.3, “Pattern Matching”). For example, the default profile
/** { ... }
can be named
profile default /** { ... }
Also, a profile with pattern matching can be named. For example:
/usr/lib/firefox-3.*/firefox-*bin { ... }
can be named
profile firefox /usr/lib/firefox-3.*/firefox-*bin { ... }
Alias rules provide an alternative way to manipulate profile path mappings to site specific layouts. They are an alternative form of path rewriting to using variables, and are done post variable resolution. The alias rule says to treat rules that have the same source prefix as if the rules are at target prefix.
alias /home/ -> /usr/home/
All the rules that have a prefix match to /home/
will provide access to /usr/home/
. For example
/home/username/** r,
allows as well access to
/usr/home/username/** r,
Aliases provide a quick way of remapping rules without the need to
rewrite them. They keep the source path still accessible—in our
example, the alias rule keeps the paths under
/home/
still accessible.
With the alias
rule, you can point to multiple
targets at the same time.
alias /home/ -> /usr/home/ alias /home/ -> /mnt/home/
With the current AppArmor tools, alias rules can only be used when manually editing and maintaining a profile.
Insert global alias definitions in the file
/etc/apparmor.d/tunables/alias
.
File permission access modes consist of combinations of the following modes:
|
Read mode |
|
Write mode (mutually exclusive to |
|
Append mode (mutually exclusive to |
|
File locking mode |
|
Link mode |
|
Link pair rule (cannot be combined with other access modes) |
Allows the program to have read access to the resource. Read access is required for shell scripts and other interpreted content and determines if an executing process can core dump.
Allows the program to have write access to the resource. Files must have this permission if they are to be unlinked (removed).
Allows a program to write to the end of a file. In contrast to the
w
mode, the append mode does not include the ability
to overwrite data, to rename, or to remove a file. The append permission
is typically used with applications who need to be able to write to log
files, but which should not be able to manipulate any existing data in
the log files. As the append permission is a subset of the permissions
associated with the write mode, the w
and
a
permission flags cannot be used together and are
mutually exclusive.
The application can take file locks. Former versions of AppArmor allowed files to be locked if an application had access to them. By using a separate file locking mode, AppArmor makes sure locking is restricted only to those files which need file locking and tightens security as locking can be used in several denial of service attack scenarios.
The link mode mediates access to hard links. When a link is created, the target file must have the same access permissions as the link created (but the destination does not need link access).
The link mode grants permission to link to arbitrary files, provided the link has a subset of the permissions granted by the target (subset permission test).
/srv/www/htdocs/index.html rl,
By specifying origin and destination, the link pair rule provides greater control over how hard links are created. Link pair rules by default do not enforce the link subset permission test that the standard rules link permission requires.
link /srv/www/htdocs/index.html -> /var/www/index.html
To force the rule to require the test, the subset
keyword is used. The following rules are equivalent:
/var/www/index.html l, link subset /var/www/index.html -> /**,
Currently link pair rules are not supported by YaST and the command line tools. Manually edit your profiles to use them. Updating such profiles using the tools is safe, because the link pair entries will not be touched.
allow
and file
Rules #
The allow
prefix is optional, and it is idiomatically
implied if not specified and the deny
(see
Section 22.7.9, “Deny Rules”) keyword is not used.
allow file /example r, allow /example r, allow network,
You can also use the optional file
keyword. If you
omit it and there are no other rule types that start with a keyword,
such as network
or mount
, it is
automatically implied.
file /example/rule r,
is equivalent to
/example/rule r,
The following rule grants access to all files:
file,
which is equal to
/** rwmlk,
File rules can use leading or trailing permissions. The permissions should not be specified as a trailing permission, but rather used at the start of the rule. This is important in that it makes file rules behave like any other rule types.
/path rw, # old style rw /path, # leading permission file rw /path, # with explicit 'file' keyword allow file rw /path, # optional 'allow' keyword added
The file rules can be extended so that they can be conditional upon
the user being the owner of the file (the fsuid needs to match the
file's uid). For this purpose the owner
keyword
is put in front of the rule. Owner conditional rules accumulate like
regular file rules do.
owner /home/*/** rw
When using file ownership conditions with link rules the ownership test is done against the target file so the user must own the file to be able to link to it.
Owner conditional rules are considered a subset of regular file rules. If a regular file rule overlaps with an owner conditional file rule, the rules are merged. Consider the following example.
/foo r, owner /foo rw, # or w,
The rules are merged—it results in r
for
everybody, and w
for the owner only.
To address everybody but the owner of the file,
use the keyword other
.
owner /foo rw, other /foo r,
Deny rules can be used to annotate or quiet known rejects. The
profile generating tools will not ask about a known reject treated
with a deny rule. Such a reject will also not show up in the audit
logs when denied, keeping the log files lean. If this is not
desired, put the keyword audit
in front of the
deny entry.
It is also possible to use deny rules in combination with allow rules.
This allows you to specify a broad allow rule, and then subtract a few
known files that should not be allowed. Deny rules can also be combined
with owner rules, to deny files owned by the user. The following example
allows read/write access to everything in a users directory except write
access to the .ssh/
files:
deny /home/*/.ssh/** w, owner /home/*/** rw,
The extensive use of deny rules is generally not encouraged, because it makes it much harder to understand what a profile does. However a judicious use of deny rules can simplify profiles. Therefore the tools only generate profiles denying specific files and will not use globbing in deny rules. Manually edit your profiles to add deny rules using globbing. Updating such profiles using the tools is safe, because the deny entries will not be touched.
AppArmor can limit mount and unmount operations, including file system
types and mount flags. The rule syntax is based on the
mount
command syntax and starts with one of the
keywords mount
, remount
, or
umount
. Conditions are optional and unspecified
conditionals are assumed to match all entries. For example, not
specifying a file system means that all file systems are matched.
Conditionals can be specified by specifying conditionals with
options=
or options in
.
options=
specifies conditionals that have to be met
exactly. The rule
mount options=ro /dev/foo -E /mnt/,
matches
root #
mount -o ro /dev/foo /mnt
but does not match
root #
mount -o ro,atime /dev/foo /mnt
root #
mount -o rw /dev/foo /mnt
options in
requires that at least one of the
listed mount options is used. The rule
mount options in (ro,atime) /dev/foo -> /mnt/,
matches
root #
mount -o ro /dev/foo /mnt
root #
mount -o ro,atime /dev/foo /mnt
root #
mount -o atime /dev/foo /mnt
but does not match
root #
mount -o ro,sync /dev/foo /mnt
root #
mount -o ro,atime,sync /dev/foo /mnt
root #
mount -o rw /dev/foo /mnt
root #
mount -o rw,noatime /dev/foo /mnt
root #
mount /dev/foo /mnt
With multiple conditionals, the rule grants permission for each set of options. The rule
mount options=ro options=atime
matches
root #
mount -o ro /dev/foo /mnt
root #
mount -o atime /dev/foo /mnt
but does not match
root #
mount -o ro,atime /dev/foo /mnt
Separate mount rules are distinct and the options do not accumulate. The rules
mount options=ro, mount options=atime,
are not equivalent to
mount options=(ro,atime), mount options in (ro,atime),
The following rule allows mounting /dev/foo
on
/mnt/
read only and using inode access times or
allows mounting /dev/foo
on
/mnt/
with some combination of 'nodev' and
'user'.
mount options=(ro, atime) options in (nodev, user) /dev/foo -> /mnt/,
allows
root #
mount -o ro,atime /dev/foo /mnt
root #
mount -o nodev /dev/foo /mnt
root #
mount -o user /dev/foo /mnt
root #
mount -o nodev,user /dev/foo /mnt
AppArmor can limit changing the root file system. The syntax is
pivot_root [oldroot=OLD_ROOT] NEW_ROOT
The paths specified in 'pivot_root' rules must end with '/' since they are directories.
# Allow any pivot pivot_root, # Allow pivoting to any new root directory and putting the old root # directory at /mnt/root/old/ pivot_root oldroot=/mnt/root/old/, # Allow pivoting the root directory to /mnt/root/ pivot_root /mnt/root/, # Allow pivoting to /mnt/root/ and putting the old root directory at # /mnt/root/old/ pivot_root oldroot=/mnt/root/old/ /mnt/root/, # Allow pivoting to /mnt/root/, putting the old root directory at # /mnt/root/old/ and transition to the /mnt/root/sbin/init profile pivot_root oldroot=/mnt/root/old/ /mnt/root/ -> /mnt/root/sbin/init,
AppArmor supports limiting ptrace system calls. ptrace rules are accumulated so that the granted ptrace permissions are the union of all the listed ptrace rule permissions. If a rule does not specify an access list, permissions are implicitly granted.
The trace
and tracedby
permissions control ptrace(2); read
and
readby
control proc(5) file system access,
kcmp(2), futexes (get_robust_list(2)) and perf trace events.
For a ptrace operation to be allowed, the tracing and traced
processes need the correct permissions. This means that the tracing
process needs the trace
permission and the traced
process needs the tracedby
permission.
Example AppArmor PTrace rules:
# Allow all PTrace access ptrace, # Explicitly allow all PTrace access, ptrace (read, readby, trace, tracedby), # Explicitly deny use of ptrace(2) deny ptrace (trace), # Allow unconfined processes (eg, a debugger) to ptrace us ptrace (readby, tracedby) peer=unconfined, # Allow ptrace of a process running under the /usr/bin/foo profile ptrace (trace) peer=/usr/bin/foo,
AppArmor supports limiting inter-process signals. AppArmor signal rules are accumulated so that the granted signal permissions are the union of all the listed signal rule permissions. AppArmor signal permissions are implied when a rule does not explicitly state an access list.
The sending and receiving process must both have the correct permissions.
Example signal rules:
# Allow all signal access signal, # Explicitly deny sending the HUP and INT signals deny signal (send) set=(hup, int), # Allow unconfined processes to send us signals signal (receive) peer=unconfined, # Allow sending of signals to a process running under the /usr/bin/foo # profile signal (send) peer=/usr/bin/foo, # Allow checking for PID existence signal (receive, send) set=("exists"), # Allow us to signal ourselves using the built-in @{profile_name} variable signal peer=@{profile_name}, # Allow two real-time signals signal set=(rtmin+0 rtmin+32),
Execute modes, also named profile transitions, consist of the following modes:
|
Discrete profile execute mode |
|
Discrete local profile execute mode |
|
Unconfined execute mode |
|
Inherit execute mode |
|
Allow |
This mode requires that a discrete security profile is defined for a resource executed at an AppArmor domain transition. If there is no profile defined, the access is denied.
Incompatible with Ux
, ux
,
px
, and ix
.
As Px
, but instead of searching the global profile
set, Cx
only searches the local profiles of the
current profile. This profile transition provides a way for an
application to have alternate profiles for helper applications.
Currently, Cx transitions are limited to top level profiles and cannot be used in hats and children profiles. This restriction will be removed in the future.
Incompatible with Ux
, ux
,
Px
, px
, cx
, and
ix
.
Allows the program to execute the resource without any AppArmor profile
applied to the executed resource. This mode is useful when a confined
program needs to be able to perform a privileged operation, such as
rebooting the machine. By placing the privileged section in another
executable and granting unconfined execution rights, it is possible to
bypass the mandatory constraints imposed on all confined processes.
Allowing a root process to go unconfined means it can change AppArmor
policy itself. For more information about what is constrained, see the
apparmor(7)
man page.
This mode is incompatible with ux
,
px
, Px
, and ix
.
Use the lowercase versions of exec modes—px
,
cx
, ux
—only in very
special cases. They do not scrub the environment of variables such as
LD_PRELOAD
. As a result, the calling domain may have an
undue amount of influence over the called resource. Use these modes only
if the child absolutely must be run unconfined and
LD_PRELOAD
must be used. Any profile using such modes
provides negligible security. Use at your own risk.
ix
prevents the normal AppArmor domain transition on
execve(2)
when the profiled program executes the
named program. Instead, the executed resource inherits the current
profile.
This mode is useful when a confined program needs to call another
confined program without gaining the permissions of the target's profile
or losing the permissions of the current profile. There is no version to
scrub the environment because ix
executions do not
change privileges.
Incompatible with cx
, ux
, and
px
. Implies m
.
This mode allows a file to be mapped into memory using
mmap(2)
's PROT_EXEC
flag. This flag
marks the pages executable. It is used on some architectures to provide
non executable data pages, which can complicate exploit attempts.
AppArmor uses this mode to limit which files a well-behaved program (or
all programs on architectures that enforce non executable memory access
controls) may use as libraries, to limit the effect of invalid
-L
flags given to ld(1)
and
LD_PRELOAD
, LD_LIBRARY_PATH
, given to
ld.so(8)
.
By default, the px
and cx
(and
their clean exec variants, too) transition to a profile whose name
matches the executable name. With named profile transitions, you can
specify a profile to be transitioned to. This is useful if multiple
binaries need to share a single profile, or if they need to use a
different profile than their name would specify. Named profile
transitions can be used with cx
,
Cx
, px
and Px
.
Currently there is a limit of twelve named profile transitions per
profile.
Named profile transitions use ->
to indicate the
name of the profile that needs to be transitioned to:
/usr/bin/foo { /bin/** px -> shared_profile, ... /usr/*bash cx -> local_profile, ... profile local_profile { ... } }
When used with globbing, normal transitions provide a “one to
many” relationship—/bin/** px
will
transition to /bin/ping
,
/bin/cat
, etc, depending on the program being run.
Named transitions provide a “many to one” relationship—all programs that match the rule regardless of their name will transition to the specified profile.
Named profile transitions show up in the log as having the mode
Nx
. The name of the profile to be changed to is
listed in the name2
field.
The px
and cx
transitions specify
a hard dependency—if the specified profile does not exist, the
exec will fail. With the inheritance fallback, the execution will
succeed but inherit the current profile. To specify inheritance
fallback, ix
is combined with cx
,
Cx
, px
and Px
into the modes cix
, Cix
,
pix
and Pix
.
/path Cix -> profile_name,
or
Cix /path -> profile_name,
where -> profile_name
is optional.
The same applies if you add the unconfined ux
mode,
where the resulting modes are cux
,
CUx
, pux
and
PUx
. These modes allow falling back to
“unconfined” when the specified profile is not found.
/path PUx -> profile_name,
or
PUx /path -> profile_name,
where -> profile_name
is optional.
The fallback modes can be used with named profile transitions, too.
When choosing one of the Px, Cx or Ux execution modes, take into account that the following environment variables are removed from the environment before the child process inherits it. As a consequence, applications or processes relying on any of these variables do not work anymore if the profile applied to them carries Px, Cx or Ux flags:
GCONV_PATH
GETCONF_DIR
HOSTALIASES
LD_AUDIT
LD_DEBUG
LD_DEBUG_OUTPUT
LD_DYNAMIC_WEAK
LD_LIBRARY_PATH
LD_ORIGIN_PATH
LD_PRELOAD
LD_PROFILE
LD_SHOW_AUXV
LD_USE_LOAD_BIAS
LOCALDOMAIN
LOCPATH
MALLOC_TRACE
NLSPATH
RESOLV_HOST_CONF
RES_OPTIONS
TMPDIR
TZDIR
safe
and unsafe
Keywords #
You can use the safe
and unsafe
keywords for rules instead of using the case modifier of execution
modes. For example
/example_rule Px,
is the same as any of the following
safe /example_rule px, safe /example_rule Px, safe px /example_rule, safe Px /example_rule,
and the rule
/example_rule px,
is the same as any of
unsafe /example_rule px, unsafe /example_rule Px, unsafe px /example_rule, unsafe Px /example_rule,
The safe
/unsafe
keywords are
mutually exclusive and can be used in a file rule after the
owner
keyword, so the order of rule keywords is
[audit] [deny] [owner] [safe|unsafe] file_rule
AppArmor can set and control an application's resource
limits (rlimits, also known as ulimits). By default, AppArmor does not
control application's rlimits, and it will only control those limits
specified in the confining profile. For more information about resource
limits, refer to the setrlimit(2)
,
ulimit(1)
, or ulimit(3)
man pages.
AppArmor leverages the system's rlimits and as such does not provide an additional auditing that would normally occur. It also cannot raise rlimits set by the system, AppArmor rlimits can only reduce an application's current resource limits.
The values will be inherited by the children of a process and will remain even if a new profile is transitioned to or the application becomes unconfined. So when an application transitions to a new profile, that profile can further reduce the application's rlimits.
AppArmor's rlimit rules will also provide mediation of setting an application's hard limits, should it try to raise them. The application cannot raise its hard limits any further than specified in the profile. The mediation of raising hard limits is not inherited as the set value is, so that when the application transitions to a new profile it is free to raise its limits as specified in the profile.
AppArmor's rlimit control does not affect an application's soft limits beyond ensuring that they are less than or equal to the application's hard limits.
AppArmor's hard limit rules have the general form of:
set rlimit RESOURCE <= value,
where RESOURCE and VALUE are to be replaced with the following values:
cpu
CPU time limit in seconds.
fsize
, data
, stack
,
core
, rss
, as
,
memlock
, msgqueue
a number in bytes, or a number with a suffix where the suffix can be K/KB (kilobytes), M/MB (megabytes), G/GB (gigabytes), for example
rlimit data <= 100M,
fsize
, nofile
, locks
,
sigpending
, nproc
*,
rtprio
a number greater or equal to 0
nice
a value between -20 and 19
*The nproc rlimit is handled different than all the other rlimits. Instead of indicating the standard process rlimit it controls the maximum number of processes that can be running under the profile at any time. When the limit is exceeded the creation of new processes under the profile will fail until the number of currently running processes is reduced.
Currently the tools cannot be used to add rlimit rules to profiles. The only way to add rlimit controls to a profile is to manually edit the profile with a text editor. The tools will still work with profiles containing rlimit rules and will not remove them, so it is safe to use the tools to update profiles containing them.
AppArmor provides the ability to audit given rules so that when they are
matched an audit message will appear in the audit log. To enable audit
messages for a given rule, the audit
keyword is
put in front of the rule:
audit /etc/foo/* rw,
If it is desirable to audit only a given permission the rule can be split into two rules. The following example will result in audit messages when files are opened for writing, but not when they are opened for reading:
audit /etc/foo/* w, /etc/foo/* r,
Audit messages are not generated for every read or write of a file but only when a file is opened for reading or writing.
Audit control can be combined with
owner
/other
conditional file rules
to provide auditing when users access files they own/do not own:
audit owner /home/*/.ssh/** rw, audit other /home/*/.ssh/** r,
AppArmor ships with a set of profiles enabled by default. These are created
by the AppArmor developers, and are stored in
/etc/apparmor.d
. In addition to these profiles,
openSUSE Leap ships profiles for individual applications together with
the relevant application. These profiles are not enabled by default, and
reside under another directory than the standard AppArmor profiles,
/etc/apparmor/profiles/extras
.
The AppArmor tools (YaST, aa-genprof
and
aa-logprof
) support the use of a local repository.
Whenever you start to create a new profile from scratch, and there
already is an inactive profile in your local repository, you are asked
whether you want to use the existing inactive one from
/etc/apparmor/profiles/extras
and whether you want
to base your efforts on it. If you decide to use this profile, it gets
copied over to the directory of profiles enabled by default
(/etc/apparmor.d
) and loaded whenever AppArmor is
started. Any further adjustments will be done to the active profile under
/etc/apparmor.d
.
YaST provides a basic way to build profiles and manage AppArmor® profiles. It provides two interfaces: a graphical one and a text-based one. The text-based interface consumes less resources and bandwidth, making it a better choice for remote administration, or for times when a local graphical environment is inconvenient. Although the interfaces have differing appearances, they offer the same functionality in similar ways. Another alternative is to use AppArmor commands, which can control AppArmor from a terminal window or through remote connections. The command line tools are described in Chapter 25, Building Profiles from the Command Line.
Start YaST from the main menu and enter your root
password
when prompted for it. Alternatively, start YaST by opening a terminal
window, logging in as root
, and entering yast2
for the graphical mode or yast
for the text-based mode.
In the AppArmor YaST module.
section, there is an icon. Click it to launch theAppArmor enables you to create an AppArmor profile by manually adding entries into the profile. Select the application for which to create a profile, then add entries.
Start YaST, select
, and click in the main window.Browse your system to find the application for which to create a profile.
When you find the application, select it and click
. A basic, empty profile appears in the window.In AppArmor profile entries by clicking the corresponding buttons and referring to Section 24.2.1, “Adding an Entry”, Section 24.2.2, “Editing an Entry”, or Section 24.2.3, “Deleting an Entry”.
, add, edit, or deleteWhen finished, click
.
YaST offers basic manipulation for AppArmor profiles, such
as creating or editing. However, the most straightforward way
to edit an AppArmor
profile is to use a text editor such as vi
:
tux >
sudo
vi /etc/apparmor.d/usr.sbin.httpd2-prefork
The vi
editor also includes syntax (error)
highlighting and syntax error highlighting, which visually warns you
when the syntax of the edited AppArmor profile is wrong.
AppArmor enables you to edit AppArmor profiles manually by adding, editing, or deleting entries. To edit a profile, proceed as follows:
Start YaST, select
, and click in the main window.From the list of profiled applications, select the profile to edit.
Click
. The window displays the profile.In the AppArmor profile entries by clicking the corresponding buttons and referring to Section 24.2.1, “Adding an Entry”, Section 24.2.2, “Editing an Entry”, or Section 24.2.3, “Deleting an Entry”.
window, add, edit, or deleteWhen you are finished, click
.In the pop-up that appears, click AppArmor profile set.
to confirm your changes to the profile and reload the
AppArmor contains a syntax check that notifies you of any syntax errors
in profiles you are trying to process with the YaST AppArmor tools.
If an error occurs, edit the profile manually as root
and
reload the profile set with systemctl reload
apparmor
.
The AppArmor profile.
button in the lists types of entries you can add to theFrom the list, select one of the following:
In the pop-up window, specify the absolute path of a file, including the type of access permitted. When finished, click
.You can use globbing if necessary. For globbing information, refer to Section 22.6, “Profile Names, Flags, Paths, and Globbing”. For file access permission information, refer to Section 22.7, “File Permission Access Modes”.
In the pop-up window, specify the absolute path of a directory, including the type of access permitted. You can use globbing if necessary. When finished, click
.For globbing information, refer to Section 22.6, “Profile Names, Flags, Paths, and Globbing”. For file access permission information, refer to Section 22.7, “File Permission Access Modes”.
In the pop-up window, select the appropriate network family and the socket type. For more information, refer to Section 22.5, “Network Access Control”.
In the pop-up window, select the appropriate capabilities. These are statements that enable each of the 32 POSIX.1e capabilities. Refer to Section 22.4, “Capability Entries (POSIX.1e)” for more information about capabilities. When finished making your selections, click .
In the pop-up window, browse to the files to use as includes. Includes are directives that pull in components of other AppArmor profiles to simplify profiles. For more information, refer to Section 22.3, “Include Statements”.
In the pop-up window, specify the name of the subprofile (hat) to add to your current profile and click . For more information, refer to Chapter 26, Profiling Your Web Applications Using ChangeHat.
When you select
, a pop-up window opens. From here, edit the selected entry.In the pop-up window, edit the entry you need to modify. You can use globbing if necessary. When finished, click
.For globbing information, refer to Section 22.6, “Profile Names, Flags, Paths, and Globbing”. For access permission information, refer to Section 22.7, “File Permission Access Modes”.
To delete an entry in a given profile, select AppArmor removes the selected profile entry.
.AppArmor enables you to delete an AppArmor profile manually. Simply select the application for which to delete a profile then delete it as follows:
Start YaST, select
, and click in the main window.Select the profile to delete.
Click
.In the pop-up that opens, click AppArmor profile set.
to delete the profile and reload theYou can change the status of AppArmor by enabling or disabling it. Enabling AppArmor protects your system from potential program exploitation. Disabling AppArmor, even if your profiles have been set up, removes protection from your system. To change the status of AppArmor, start YaST, select , and click in the main window.
To change the status of AppArmor, continue as described in Section 24.4.1, “Changing AppArmor Status”. To change the mode of individual profiles, continue as described in Section 24.4.2, “Changing the Mode of Individual Profiles”.
When you change the status of AppArmor, set it to enabled or disabled. When AppArmor is enabled, it is installed, running, and enforcing the AppArmor security policies.
Start YaST, select
, and click in the main window.Enable AppArmor by checking or disable AppArmor by deselecting it.
Click
in the window.You always need to restart running programs to apply the profiles to them.
AppArmor can apply profiles in two different modes. In
complain mode, violations of AppArmor profile rules,
such as the profiled program accessing files not permitted by the
profile, are detected. The violations are permitted, but also logged.
This mode is convenient for developing profiles and is used by the
AppArmor tools for generating profiles. Loading a profile in
enforce mode enforces the policy defined in the
profile, and reports policy violation attempts to
rsyslogd
(or
auditd
or
journalctl
, depending on system
configuration).
The AppArmor profiles. This feature is useful for determining the status of your system during profile development. During systemic profiling (see Section 25.7.2, “Systemic Profiling”), you can use this tool to adjust and monitor the scope of the profiles for which you are learning behavior.
dialog allows you to view and edit the mode of currently loadedTo edit an application's profile mode, proceed as follows:
Start YaST, select
, and click in the main window.In the
section, select .Select the profile for which to change the mode.
Select complain mode or to enforce mode.
to set this profile toApply your settings and leave YaST with
.To change the mode of all profiles, use
or .By default, only active profiles are listed (any profile that has a matching application installed on your system). To set up a profile before installing the respective application, click
and select the profile to configure from the list that appears.AppArmor® provides the user the ability to use a command line interface rather than a graphical interface to manage and configure the system security. Track the status of AppArmor and create, delete, or modify AppArmor profiles using the AppArmor command line tools.
Before starting to manage your profiles using the AppArmor command line tools, check out the general introduction to AppArmor given in Chapter 21, Immunizing Programs and Chapter 22, Profile Components and Syntax.
AppArmor can be in any one of three states:
AppArmor is not activated in the kernel.
AppArmor is activated in the kernel and is enforcing AppArmor program policies.
AppArmor is activated in the kernel, but no policies are enforced.
Detect the state of AppArmor by inspecting
/sys/kernel/security/apparmor/profiles
. If
cat /sys/kernel/security/apparmor/profiles
reports a
list of profiles, AppArmor is running. If it is empty and returns nothing,
AppArmor is stopped. If the file does not exist, AppArmor is unloaded.
Manage AppArmor with systemctl
. It lets you perform the
following operations:
sudo systemctl start apparmor
Behavior depends on the state of AppArmor. If it is not activated,
start
activates and starts it, putting it in the
running state. If it is stopped, start
causes the
re-scan of AppArmor profiles usually found in
/etc/apparmor.d
and puts AppArmor in the running
state. If AppArmor is already running, start
reports a
warning and takes no action.
Already running processes need to be restarted to apply the AppArmor profiles on them.
sudo systemctl stop apparmor
Stops AppArmor if it is running by removing all profiles from kernel
memory, effectively disabling all access controls, and putting AppArmor
into the stopped state. If the AppArmor is already stopped,
stop
tries to unload the profiles again, but nothing
happens.
sudo systemctl reload apparmor
Causes the AppArmor module to re-scan the profiles in
/etc/apparmor.d
without unconfining running
processes. Freshly created profiles are enforced and recently deleted
ones are removed from the /etc/apparmor.d
directory.
The AppArmor module profile definitions are stored in the
/etc/apparmor.d
directory as plain text files. For a
detailed description of the syntax of these files, refer to
Chapter 22, Profile Components and Syntax.
All files in the /etc/apparmor.d
directory are
interpreted as profiles and are loaded as such. Renaming files in that
directory is not an effective way of preventing profiles from being
loaded. You must remove profiles from this directory to prevent them from
being read and evaluated effectively, or call
aa-disable
on the profile, which will create a
symbolic link in /etc/apparmor.d/disabled/
.
You can use a text editor, such as vi
, to access and
make changes to these profiles. The following sections contain detailed
steps for building profiles:
Refer to Section 25.3, “Adding or Creating an AppArmor Profile”
To add or create an AppArmor profile for an application, you can use a systemic or stand-alone profiling method, depending on your needs. Learn more about these two approaches in Section 25.7, “Two Methods of Profiling”.
The following steps describe the procedure for editing an AppArmor profile:
If you are not currently logged in as root
, enter
su
in a terminal window.
Enter the root
password when prompted.
Go to the profile directory with cd
/etc/apparmor.d/
.
Enter ls
to view all profiles currently installed.
Open the profile to edit in a text editor, such as vim.
Make the necessary changes, then save the profile.
Restart AppArmor by entering systemctl reload
apparmor
in a terminal window.
aa-remove-unknown
will unload all profiles that
are not stored in /etc/apparmor.d
, for example
automatically generated LXD profiles. This may compromise the
security of the system. Use the -n
parameter to
list all profiles that will be unloaded.
To unload all profiles that are no longer in
/etc/apparmor.d/
AppArmor profiles, run:
tux >
sudo
aa-remove-unknown
You can print a list of profiles that will be removed:
tux >
sudo
aa-remove-unknown -n
The following steps describe the procedure for deleting an AppArmor profile.
Remove the AppArmor definition from the kernel:
tux >
sudo
apparmor_parser -R /etc/apparmor.d/PROFILE
Remove the definition file:
tux >
sudo
rm /etc/apparmor.d/PROFILE
tux >
sudo
rm /var/lib/apparmor/cache/PROFILE
Given the syntax for AppArmor profiles in Chapter 22, Profile Components and Syntax, you could create profiles without using the tools. However, the effort involved would be substantial. To avoid such a situation, use the AppArmor tools to automate the creation and refinement of profiles.
There are two ways to approach AppArmor profile creation. Tools are available for both methods.
A method suitable for profiling small applications that have a finite runtime, such as user client applications like mail clients. For more information, refer to Section 25.7.1, “Stand-Alone Profiling”.
A method suitable for profiling many programs at once and for profiling applications that may run for days, weeks, or continuously across reboots, such as network server applications like Web servers and mail servers. For more information, refer to Section 25.7.2, “Systemic Profiling”.
Automated profile development becomes more manageable with the AppArmor tools:
Decide which profiling method suits your needs.
Perform a static analysis. Run either aa-genprof
or
aa-autodep
, depending on the profiling method
chosen.
Enable dynamic learning. Activate learning mode for all profiled programs.
Stand-alone profile generation and improvement is managed by a program
called aa-genprof
. This method is easy because
aa-genprof
takes care of everything, but is limited
because it requires aa-genprof
to run for the entire
duration of the test run of your program (you cannot reboot the machine
while you are still developing your profile).
To use aa-genprof
for the stand-alone method of
profiling, refer to
Section 25.7.3.8, “aa-genprof—Generating Profiles”.
This method is called systemic profiling because it
updates all of the profiles on the system at once, rather than focusing
on the one or few targeted by aa-genprof
or
stand-alone profiling. With systemic profiling, profile construction and
improvement are somewhat less automated, but more flexible. This method
is suitable for profiling long-running applications whose behavior
continues after rebooting, or many programs at once.
Build an AppArmor profile for a group of applications as follows:
Create profiles for the individual programs that make up your application.
Although this approach is systemic, AppArmor only monitors those
programs with profiles and their children. To get AppArmor to consider
a program, you must at least have aa-autodep
create
an approximate profile for it. To create this approximate profile,
refer to
Section 25.7.3.1, “aa-autodep—Creating Approximate Profiles”.
Put relevant profiles into learning or complain mode.
Activate learning or complain mode for all profiled programs by entering
tux >
sudo
aa-complain /etc/apparmor.d/*
in a terminal window while logged in as root
. This
functionality is also available through the YaST Profile Mode
module, described in
Section 24.4.2, “Changing the Mode of Individual Profiles”.
When in learning mode, access requests are not blocked, even if the profile dictates that they should be. This enables you to run through several tests (as shown in Step 3) and learn the access needs of the program so it runs properly. With this information, you can decide how secure to make the profile.
Refer to Section 25.7.3.2, “aa-complain—Entering Complain or Learning Mode” for more detailed instructions for using learning or complain mode.
Exercise your application.
Run your application and exercise its functionality. How much to
exercise the program is up to you, but you need the program to access
each file representing its access needs. Because the execution is not
being supervised by aa-genprof
, this step can go on
for days or weeks and can span complete system reboots.
Analyze the log.
In systemic profiling, run aa-logprof
directly
instead of letting aa-genprof
run it (as in
stand-alone profiling). The general form of
aa-logprof
is:
tux >
sudo
aa-logprof [ -d /path/to/profiles ] [ -f /path/to/logfile ]
Refer to
Section 25.7.3.9, “aa-logprof—Scanning the System Log”
for more information about using aa-logprof
.
This generates optimal profiles. An iterative approach captures smaller data sets that can be trained and reloaded into the policy engine. Subsequent iterations generate fewer messages and run faster.
Edit the profiles.
You should review the profiles that have been generated. You
can open and edit the profiles in
/etc/apparmor.d/
using a text editor.
Return to enforce mode.
This is when the system goes back to enforcing the rules of the
profiles, not only logging information. This can be done manually by
removing the flags=(complain)
text from the
profiles or automatically by using the aa-enforce
command, which works identically to the aa-complain
command, except it sets the profiles to enforce mode. This
functionality is also available through the YaST Profile Mode
module, described in
Section 24.4.2, “Changing the Mode of Individual Profiles”.
To ensure that all profiles are taken out of complain mode and put
into enforce mode, enter aa-enforce
/etc/apparmor.d/*
.
Re-scan all profiles.
To have AppArmor re-scan all of the profiles and change the enforcement
mode in the kernel, enter systemctl reload
apparmor
.
All of the AppArmor profiling utilities are provided by the
apparmor-utils
RPM package and are stored in
/usr/sbin
. Each tool has a different purpose.
This creates an approximate profile for the program or application
selected. You can generate approximate profiles for binary executables
and interpreted script programs. The resulting profile is called
“approximate” because it does not necessarily contain all
of the profile entries that the program needs to be properly confined
by AppArmor. The minimum aa-autodep
approximate
profile has, at minimum, a base include directive, which contains basic
profile entries needed by most programs. For certain types of programs,
aa-autodep
generates a more expanded profile. The
profile is generated by recursively calling ldd(1)
on the executables listed on the command line.
To generate an approximate profile, use the
aa-autodep
program. The program argument can be
either the simple name of the program, which
aa-autodep
finds by searching your shell's path
variable, or it can be a fully qualified path. The program itself can
be of any type (ELF binary, shell script, Perl script, etc.).
aa-autodep
generates an approximate profile to
improve through the dynamic profiling that follows.
The resulting approximate profile is written to the
/etc/apparmor.d
directory using the AppArmor
profile naming convention of naming the profile after the absolute path
of the program, replacing the forward slash (/
)
characters in the path with period (.
) characters.
The general syntax of aa-autodep
is to enter the
following in a terminal window:
tux >
sudo
aa-autodep [ -d /PATH/TO/PROFILES ] [PROGRAM1 PROGRAM2...]
If you do not enter the program name or names, you are prompted for
them. /path/to/profiles overrides the
default location of /etc/apparmor.d
, should you
keep profiles in a location other than the default.
To begin profiling, you must create profiles for each main executable service that is part of your application (anything that might start without being a child of another program that already has a profile). Finding all such programs depends on the application in question. Here are several strategies for finding such programs:
If all the programs to profile are in one directory and there are no
other programs in that directory, the simple command
aa-autodep
/path/to/your/programs/* creates basic
profiles for all programs in that directory.
You can run your application and use the standard Linux
pstree
command to find all processes running.
Then manually hunt down the location of these programs and run the
aa-autodep
for each one. If the programs are in
your path, aa-autodep
finds them for you. If they
are not in your path, the standard Linux command
find
might be helpful in finding your programs.
Execute find / -name '
MY_APPLICATION' -print to determine an
application's path (MY_APPLICATION being
an example application). You may use wild cards if appropriate.
The complain or learning mode tool (aa-complain
)
detects violations of AppArmor profile rules, such as the profiled
program accessing files not permitted by the profile. The violations
are permitted, but also logged. To improve the profile, turn complain
mode on, run the program through a suite of tests to generate log
events that characterize the program's access needs, then postprocess
the log with the AppArmor tools to transform log events into improved
profiles.
Manually activating complain mode (using the command line) adds a flag
to the top of the profile so that /bin/foo
becomes
/bin/foo flags=(complain)
. To use complain mode,
open a terminal window and enter one of the following lines as
root
:
If the example program (PROGRAM1) is in your path, use:
tux >
sudo
aa-complain [PROGRAM1 PROGRAM2 ...]
If the program is not in your path, specify the entire path as follows:
tux >
sudo
aa-complain /sbin/PROGRAM1
If the profiles are not in /etc/apparmor.d
, use
the following to override the default location:
tux >
sudo
aa-complain /path/to/profiles/PROGRAM1
Specify the profile for /sbin/program1 as follows:
tux >
sudo
aa-complain /etc/apparmor.d/sbin.PROGRAM1
Each of the above commands activates the complain mode for the profiles
or programs listed. If the program name does not include its entire
path, aa-complain
searches $PATH
for
the program. For example, aa-complain /usr/sbin/*
finds profiles associated with all of the programs in
/usr/sbin
and puts them into complain mode.
aa-complain /etc/apparmor.d/*
puts all of the
profiles in /etc/apparmor.d
into complain mode.
YaST offers a graphical front-end for toggling complain and enforce mode. See Section 24.4.2, “Changing the Mode of Individual Profiles” for information.
aa-decode
will decode hex-encoded strings in the
AppArmor log output. It can also process the audit log on standard
input, convert any hex-encoded AppArmor log entries, and display them on
standard output.
Use aa-disable
to disable the enforcement mode for
one or more AppArmor profiles. This command will unload the profile from
the kernel, and prevent the profile from being loaded on AppArmor
start-up. Use aa-enforce
or
aa-complain
utilities to change this behavior.
aa-easyprof
provides an easy-to-use interface for
AppArmor profile generation. aa-easyprof
supports the
use of templates and profile groups to quickly profile an application.
While aa-easyprof
can help with profile generation,
its utility is dependent on the quality of the templates, profile
groups and abstractions used. Also, this tool may create a profile that
is less restricted than when creating a profile manually or with
aa-genprof
and aa-logprof
.
For more information, see the man page of
aa-easyprof
(8).
The enforce mode detects violations of AppArmor profile rules, such as the profiled program accessing files not permitted by the profile. The violations are logged and not permitted. The default is for enforce mode to be enabled. To log the violations only, but still permit them, use complain mode.
Manually activating enforce mode (using the command line) removes the
complain flag from the top of the profile so that /bin/foo
flags=(complain)
becomes /bin/foo
. To use
enforce mode, open a terminal window and enter one of the following
lines.
If the example program (PROGRAM1) is in your path, use:
tux >
sudo
aa-enforce [PROGRAM1 PROGRAM2 ...]
If the program is not in your path, specify the entire path, as follows:
tux >
sudo
aa-enforce /sbin/PROGRAM1
If the profiles are not in /etc/apparmor.d, use the following to override the default location:
tux >
sudo
aa-enforce -d /path/to/profiles/ program1
Specify the profile for /sbin/program1 as follows:
tux >
sudo
aa-enforce /etc/apparmor.d/sbin.PROGRAM1
Each of the above commands activates the enforce mode for the profiles and programs listed.
If you do not enter the program or profile names, you are prompted to
enter one. /path/to/profiles overrides the
default location of /etc/apparmor.d
.
The argument can be either a list of programs or a list of profiles. If
the program name does not include its entire path,
aa-enforce
searches $PATH
for the
program.
YaST offers a graphical front-end for toggling complain and enforce mode. See Section 24.4.2, “Changing the Mode of Individual Profiles” for information.
Use aa-exec
to launch a program confined by a
specified profile and/or profile namespace. If both a profile and
namespace are specified, the program will be confined by the profile in
the new namespace. If only a profile namespace is specified, the
profile name of the current confinement will be used. If neither a
profile nor namespace is specified, the command will be run using the
standard profile attachment—as if you did not use the
aa-exec
command.
For more information on the command's options, see its manual page
man 8 aa-exec
.
aa-genprof
is AppArmor's profile generating utility.
It runs aa-autodep
on the specified program,
creating an approximate profile (if a profile does not already exist
for it), sets it to complain mode, reloads it into AppArmor, marks the
log, and prompts the user to execute the program and exercise its
functionality. Its syntax is as follows:
tux >
sudo
aa-genprof [ -d /path/to/profiles ] PROGRAM
To create a profile for the Apache Web server program httpd2-prefork,
do the following as root
:
Enter systemctl stop apache2
.
Next, enter aa-genprof httpd2-prefork
.
Now aa-genprof
does the following:
Resolves the full path of httpd2-prefork using your shell's path
variables. You can also specify a full path. On openSUSE Leap,
the default full path is
/usr/sbin/httpd2-prefork
.
Checks to see if there is an existing profile for httpd2-prefork.
If there is one, it updates it. If not, it creates one using the
aa-autodep
as described in
Section 25.7.3, “Summary of Profiling Tools”.
Puts the profile for this program into learning or complain mode so
that profile violations are logged, but are permitted to proceed. A
log event looks like this (see
/var/log/audit/audit.log
):
type=APPARMOR_ALLOWED msg=audit(1189682639.184:20816): \ apparmor="DENIED" operation="file_mmap" parent=2692 \ profile="/usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT" \ name="/var/log/apache2/access_log-20140116" pid=28730 comm="httpd2-prefork" \ requested_mask="::r" denied_mask="::r" fsuid=30 ouid=0
If you are not running the audit daemon, the AppArmor events are
logged directly to systemd
journal (see
Book “Reference”, Chapter 11 “journalctl
: Query the systemd
Journal”):
Sep 13 13:20:30 K23 kernel: audit(1189682430.672:20810): \ apparmor="DENIED" operation="file_mmap" parent=2692 \ profile="/usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT" \ name="/var/log/apache2/access_log-20140116" pid=28730 comm="httpd2-prefork" \ requested_mask="::r" denied_mask="::r" fsuid=30 ouid=0
They also can be viewed using the dmesg
command:
audit(1189682430.672:20810): apparmor="DENIED" \ operation="file_mmap" parent=2692 \ profile="/usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT" \ name="/var/log/apache2/access_log-20140116" pid=28730 comm="httpd2-prefork" \ requested_mask="::r" denied_mask="::r" fsuid=30 ouid=0
Marks the log with a beginning marker of log events to consider. For example:
Sep 13 17:48:52 figwit root: GenProf: e2ff78636296f16d0b5301209a04430d
When prompted by the tool, run the application to profile in another
terminal window and perform as many of the application functions as
possible. Thus, the learning mode can log the files and directories
to which the program requires access to function properly.
For example, in a new terminal window, enter systemctl start
apache2
.
Select from the following options that are available in the
aa-genprof
terminal window after you have executed
the program function:
S runs aa-genprof
on the system
log from where it was marked when aa-genprof
was
started and reloads the profile. If system events exist in the log,
AppArmor parses the learning mode log files. This generates a series
of questions that you must answer to guide
aa-genprof
in generating the security profile.
F exits the tool.
If requests to add hats appear, proceed to Chapter 26, Profiling Your Web Applications Using ChangeHat.
Answer two types of questions:
A resource is requested by a profiled program that is not in the profile (see Example 25.1, “Learning Mode Exception: Controlling Access to Specific Resources”).
A program is executed by the profiled program and the security domain transition has not been defined (see Example 25.2, “Learning Mode Exception: Defining Permissions for an Entry”).
Each of these categories results in a series of questions that you must answer to add the resource or program to the profile. Example 25.1, “Learning Mode Exception: Controlling Access to Specific Resources” and Example 25.2, “Learning Mode Exception: Defining Permissions for an Entry” provide examples of each one. Subsequent steps describe your options in answering these questions.
Dealing with execute accesses is complex. You must decide how to proceed with this entry regarding which execute permission type to grant to this entry:
Reading log entries from /var/log/audit/audit.log. Updating AppArmor profiles in /etc/apparmor.d. Profile: /usr/sbin/cupsd Program: cupsd Execute: /usr/lib/cups/daemon/cups-lpd Severity: unknown (I)nherit / (P)rofile / (C)hild / (N)ame / (U)nconfined / (X)ix / (D)eny / Abo(r)t / (F)inish
The child inherits the parent's profile, running with the same
access controls as the parent. This mode is useful when a
confined program needs to call another confined program without
gaining the permissions of the target's profile or losing the
permissions of the current profile. This mode is often used when
the child program is a helper application,
such as the /usr/bin/mail
client using
less
as a pager.
The child runs using its own profile, which must be loaded into the kernel. If the profile is not present, attempts to execute the child fail with permission denied. This is most useful if the parent program is invoking a global service, such as DNS lookups or sending mail with your system's MTA.
Choose the
(Px) option to scrub the environment of environment variables that could modify execution behavior when passed to the child process.Sets up a transition to a subprofile. It is like px/Px transition, except to a child profile.
Choose the
(Cx) option to scrub the environment of environment variables that could modify execution behavior when passed to the child process.The child runs completely unconfined without any AppArmor profile applied to the executed resource.
Choose the AppArmor. Only use it as a last resort.
(Ux) option to scrub the environment of environment variables that could modify execution behavior when passed to the child process. Note that running unconfined profiles introduces a security vulnerability that could be used to evade
This permission denotes that the program running under the
profile can access the resource using the mmap system call with
the flag PROT_EXEC
. This means that the data
mapped in it can be executed. You are prompted to include this
permission if it is requested during a profiling run.
Adds a deny
rule to the profile, and
permanently prevents the program from accessing the specified
directory path entries. AppArmor then continues to the next
event.
Aborts aa-logprof
, losing all rule changes
entered so far and leaving all profiles unmodified.
Closes aa-logprof
, saving all rule changes
entered so far and modifying all profiles.
Example 25.2, “Learning Mode Exception: Defining Permissions for an Entry”
shows AppArmor suggest allowing a globbing pattern
/var/run/nscd/*
for reading, then using an
abstraction to cover common Apache-related access rules.
Profile: /usr/sbin/httpd2-prefork Path: /var/run/nscd/dbSz9CTr Mode: r Severity: 3 1 - /var/run/nscd/dbSz9CTr [2 - /var/run/nscd/*] (A)llow / [(D)eny] / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish / (O)pts Adding /var/run/nscd/* r to profile. Profile: /usr/sbin/httpd2-prefork Path: /proc/11769/attr/current Mode: w Severity: 9 [1 - #include <abstractions/apache2-common>] 2 - /proc/11769/attr/current 3 - /proc/*/attr/current (A)llow / [(D)eny] / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish / (O)pts Adding #include <abstractions/apache2-common> to profile.
AppArmor provides one or more paths or includes. By entering the option number, select the desired options then proceed to the next step.
Not all of these options are always presented in the AppArmor menu.
#include
This is the section of an AppArmor profile that refers to an include file, which procures access permissions for programs. By using an include, you can give the program access to directory paths or files that are also required by other programs. Using includes can reduce the size of a profile. It is good practice to select includes when suggested.
This is accessed by selecting Section 22.6, “Profile Names, Flags, Paths, and Globbing”.
as described in the next step. For information about globbing syntax, refer toThis is the literal path to which the program needs access so that it can run properly.
After you select the path or include, process it as an entry into the AppArmor profile by selecting or . If you are not satisfied with the directory path entry as it is displayed, you can also it.
The following options are available to process the learning mode entries and build the profile:
Allows access to the selected directory path.
Allows access to the specified directory path entries. AppArmor suggests file permission access. For more information, refer to Section 22.7, “File Permission Access Modes”.
Prevents the program from accessing the specified directory path entries. AppArmor then continues to the next event.
Prompts you to enter your own rule for this event, allowing you to specify a regular expression. If the expression does not actually satisfy the event that prompted the question in the first place, AppArmor asks for confirmation and lets you reenter the expression.
Select a specific path or create a general rule using wild cards that match a broader set of paths. To select any of the offered paths, enter the number that is printed in front of the path then decide how to proceed with the selected item.
For more information about globbing syntax, refer to Section 22.6, “Profile Names, Flags, Paths, and Globbing”.
This modifies the original directory path while retaining the
file name extension. For example,
/etc/apache2/file.ext
becomes
/etc/apache2/*.ext
, adding the wild card
(asterisk) in place of the file name. This allows the program to
access all files in the suggested directory that end with the
.ext
extension.
Aborts aa-logprof
, losing all rule changes
entered so far and leaving all profiles unmodified.
Closes aa-logprof
, saving all rule changes
entered so far and modifying all profiles.
To view and edit your profile using vi
, enter
vi /etc/apparmor.d/
PROFILENAME in a terminal window. To
enable syntax highlighting when editing an AppArmor profile in vim,
use the commands :syntax on
then :set
syntax=apparmor
. For more information about vim and syntax
highlighting, refer to
Section 25.7.3.14, “apparmor.vim”.
Restart AppArmor and reload the profile set including the newly
created one using the systemctl reload
apparmor
command.
Like the graphical front-end for building AppArmor profiles, the
YaST Add Profile Wizard, aa-genprof
also
supports the use of the local profile repository under
/etc/apparmor/profiles/extras
and the remote AppArmor profile repository.
To use a profile from the local repository, proceed as follows:
Start aa-genprof
as described above.
If aa-genprof
finds an inactive local profile, the
following lines appear on your terminal window:
Profile: /usr/bin/opera [1 - Inactive local profile for /usr/bin/opera] [(V)iew Profile] / (U)se Profile / (C)reate New Profile / Abo(r)t / (F)inish
To use this profile, press U ( ) and follow the profile generation procedure outlined above.
To examine the profile before activating it, press V ( ).
To ignore the existing profile, press C ( ) and follow the profile generation procedure outlined above to create the profile from scratch.
Leave aa-genprof
by pressing F
( ) when you are done and save your changes.
aa-logprof
is an interactive tool used to review the
complain and enforce mode events found in the log entries in
/var/log/audit/audit.log
, or directly in the
systemd
journal (see Book “Reference”, Chapter 11 “journalctl
: Query the systemd
Journal”), and
generate new entries in AppArmor security profiles.
When you run aa-logprof
, it begins to scan the log
files produced in complain and enforce mode and, if there are new
security events that are not covered by the existing profile set, it
gives suggestions for modifying the profile.
aa-logprof
uses this information to observe program
behavior.
If a confined program forks and executes another program,
aa-logprof
sees this and asks the user which
execution mode should be used when launching the child process. The
execution modes ix, px,
Px, ux,
Ux, cx,
Cx, and named profiles, are options for starting
the child process. If a separate profile exists for the child process,
the default selection is Px. If one does not
exist, the profile defaults to ix. Child processes
with separate profiles have aa-autodep
run on them
and are loaded into AppArmor, if it is running.
When aa-logprof
exits, profiles are updated with the
changes. If AppArmor is active, the updated profiles are reloaded and,
if any processes that generated security events are still running in
the null-XXXX profiles (unique profiles temporarily created in complain
mode), those processes are set to run under their proper profiles.
To run aa-logprof
, enter
aa-logprof
into a terminal window while logged in as
root
. The following options can be used for
aa-logprof
:
aa-logprof -d
/path/to/profile/directory/
Specifies the full path to the location of the profiles if the
profiles are not located in the standard directory,
/etc/apparmor.d/
.
aa-logprof -f
/path/to/logfile/
Specifies the full path to the location of the log file if the log
file is not located in the default directory or
/var/log/audit/audit.log
.
aa-logprof -m "string marker in logfile"
Marks the starting point for aa-logprof
to look
in the system log. aa-logprof
ignores all events
in the system log before the specified mark. If the mark contains
spaces, it must be surrounded by quotes to work correctly. For
example:
root #
aa-logprof -m "17:04:21"
or
root #
aa-logprof -m e2ff78636296f16d0b5301209a04430d
aa-logprof
scans the log, asking you how to handle
each logged event. Each question presents a numbered list of AppArmor
rules that can be added by pressing the number of the item on the list.
By default, aa-logprof
looks for profiles in
/etc/apparmor.d/
. Often running
aa-logprof
as root
is enough to update the
profile. However, there might be times when you need to search archived
log files, such as if the program exercise period exceeds the log
rotation window (when the log file is archived and a new log file is
started). If this is the case, you can enter zcat -f `ls
-1tr
/path/to/logfile*` |
aa-logprof -f -.
The following is an example of how aa-logprof
addresses httpd2-prefork accessing the file
/etc/group
. []
indicates the
default option.
In this example, the access to /etc/group
is part of
httpd2-prefork accessing name services. The appropriate response is
1
, which includes a predefined set of AppArmor rules.
Selecting 1
to #include
the name
service package resolves all of the future questions pertaining to DNS
lookups and makes the profile less brittle in that any changes to
DNS configuration and the associated name service profile package can
be made once, rather than needing to revise many profiles.
Profile: /usr/sbin/httpd2-prefork Path: /etc/group New Mode: r [1 - #include <abstractions/nameservice>] 2 - /etc/group [(A)llow] / (D)eny / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish
Select one of the following responses:
Triggers the default action, which is, in this example, allowing access to the specified directory path entry.
Allows access to the specified directory path entries. AppArmor suggests file permission access. For more information about this, refer to Section 22.7, “File Permission Access Modes”.
Permanently prevents the program from accessing the specified directory path entries. AppArmor then continues to the next event.
Prompts you to enter your own rule for this event, allowing you to specify whatever form of regular expression you want. If the expression entered does not actually satisfy the event that prompted the question in the first place, AppArmor asks for confirmation and lets you reenter the expression.
Select either a specific path or create a general rule using wild cards that matches on a broader set of paths. To select any of the offered paths, enter the number that is printed in front of the paths then decide how to proceed with the selected item.
For more information about globbing syntax, refer to Section 22.6, “Profile Names, Flags, Paths, and Globbing”.
This modifies the original directory path while retaining the file
name extension. For example,
/etc/apache2/file.ext
becomes
/etc/apache2/*.ext
, adding the wild card
(asterisk) in place of the file name. This allows the program to
access all files in the suggested directory that end with the
.ext
extension.
Aborts aa-logprof
, losing all rule changes
entered so far and leaving all profiles unmodified.
Closes aa-logprof
, saving all rule changes
entered so far and modifying all profiles.
For example, when profiling vsftpd, see this question:
Profile: /usr/sbin/vsftpd Path: /y2k.jpg New Mode: r [1 - /y2k.jpg] (A)llow / [(D)eny] / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish
Several items of interest appear in this question. First, note that
vsftpd is asking for a path entry at the top of the tree, even though
vsftpd on openSUSE Leap
serves FTP files from /srv/ftp
by default. This is
because vsftpd uses chroot and, for the portion of the code inside the
chroot jail, AppArmor sees file accesses in terms of the chroot
environment rather than the global absolute path.
The second item of interest is that you should grant FTP read
access to all JPEG files in the directory, so you could use
/*.jpg
. Doing so collapses all previous rules
granting access to individual .jpg
files and
forestalls any future questions pertaining to access to
.jpg
files.
Finally, you should grant more general access to FTP files. If
you select aa-logprof
replaces the suggested path of
/y2k.jpg
with /*
.
Alternatively, you should grant even more access to the entire
directory tree, in which case you could use the
path option and enter /**.jpg
(which would grant
access to all .jpg
files in the entire directory
tree) or /**
(which would grant access to all
files in the directory tree).
These items deal with read accesses. Write accesses are similar, except that it is good policy to be more conservative in your use of regular expressions for write accesses. Dealing with execute accesses is more complex. Find an example in Example 25.1, “Learning Mode Exception: Controlling Access to Specific Resources”.
In the following example, the /usr/bin/mail
mail
client is being profiled and aa-logprof
has
discovered that /usr/bin/mail
executes
/usr/bin/less
as a helper application to
“page” long mail messages. Consequently, it presents this
prompt:
/usr/bin/nail -> /usr/bin/less (I)nherit / (P)rofile / (C)hild / (N)ame / (U)nconfined / (X)ix / (D)eny
The actual executable file for /usr/bin/mail
turns out to be /usr/bin/nail
, which is not a
typographical error.
The program /usr/bin/less
appears to be a
simple one for scrolling through text that is more than one screen
long and that is in fact what /usr/bin/mail
is
using it for. However, less
is actually a large
and powerful program that uses many other helper applications, such
as tar
and rpm
.
Run less
on a tar file or an RPM file and it shows
you the inventory of these containers.
You do not want to run rpm
automatically when
reading mail messages (that leads directly to a Microsoft*
Outlook–style virus attack, because RPM has the power to
install and modify system programs), so, in this case, the best choice
is to use . This results in the less program
executed from this context running under the profile for
/usr/bin/mail
. This has two consequences:
You need to add all of the basic file accesses for
/usr/bin/less
to the profile for
/usr/bin/mail
.
You can avoid adding the helper applications, such as
tar
and rpm
, to the
/usr/bin/mail
profile so that when
/usr/bin/mail
runs
/usr/bin/less
in this context, the less program
is far less dangerous than it would be without AppArmor protection.
Another option is to use the Cx execute modes. For more information
on execute modes, see Section 22.12, “Execute Modes”.
In other circumstances, you might instead want to use the
aa-logprof
:
The rule written into the profile uses px/Px, which forces the transition to the child's own profile.
aa-logprof
constructs a profile for the child and
starts building it, in the same way that it built the parent profile,
by assigning events for the child process to the child's profile and
asking the aa-logprof
user questions. The profile
will also be applied if you run the child as a stand-alone program.
If a confined program forks and executes another program,
aa-logprof
sees this and asks the user which
execution mode should be used when launching the child process. The
execution modes of inherit, profile, unconfined, child, named profile,
or an option to deny the execution are presented.
If a separate profile exists for the child process, the default
selection is profile. If a profile does not exist, the default is
inherit. The inherit option, or ix
, is described in
Section 22.7, “File Permission Access Modes”.
The profile option indicates that the child program should run in its
own profile. A secondary question asks whether to sanitize the
environment that the child program inherits from the parent. If you
choose to sanitize the environment, this places the execution modifier
Px
in your AppArmor profile. If you select not to
sanitize, px
is placed in the profile and no
environment sanitizing occurs. The default for the execution mode is
Px
if you select profile execution mode.
The unconfined execution mode is not recommended and should only be
used in cases where there is no other option to generate a profile for
a program reliably. Selecting unconfined opens a warning dialog asking
for confirmation of the choice. If you are sure and choose
Ux
in your
profile, select . To use the execution mode
ux
in your profile instead, select
. The default value selected is
Ux
for unconfined execution mode.
Selecting ux or Ux
is very dangerous and provides
no enforcement of policy (from a security perspective) of the
resulting execution behavior of the child program.
The aa-unconfined
command examines open network
ports on your system, compares that to the set of profiles loaded on
your system, and reports network services that do not have AppArmor
profiles. It requires root
privileges and that it not be
confined by an AppArmor profile.
aa-unconfined
must be run as root
to
retrieve the process executable link from the
/proc
file system. This program is susceptible to
the following race conditions:
An unlinked executable is mishandled
A process that dies between netstat(8)
and further
checks is mishandled
This program lists processes using TCP and UDP only. In short, this program is unsuitable for forensics use and is provided only as an aid to profiling all network-accessible processes in the lab.
aa-notify
is a handy utility that displays AppArmor
notifications in your desktop environment. This is very convenient if
you do not want to inspect the AppArmor log file, but rather let the
desktop inform you about events that violate the policy. To enable
AppArmor desktop notifications, run aa-notify
:
tux >
sudo
aa-notify -p -u USERNAME --display DISPLAY_NUMBER
where USERNAME is your user name under which
you are logged in, and DISPLAY_NUMBER is the
X Window display number you are currently using, such as
:0
. The process is run in the background, and shows
a notification each time a deny event happens.
The active X Window display number is saved in the
$DISPLAY
variable, so you can use
--display $DISPLAY
to avoid finding out the current
display number.
aa-notify Message in GNOME
#
With the -s DAYS
option,
you can also configure aa-notify
to display a
summary of notifications for the specified number of past days. For
more information on aa-notify
, see its man page
man 8 aa-notify
.
A syntax highlighting file for the vim text editor highlights various features of an AppArmor profile with colors. Using vim and the AppArmor syntax mode for vim, you can see the semantic implications of your profiles with color highlighting. Use vim to view and edit your profile by typing vim at a terminal window.
To enable the syntax coloring when you edit an AppArmor profile in vim,
use the commands :syntax on
then :set
syntax=apparmor
. To make sure vim recognizes the edited file
type correctly as an AppArmor profile, add
# vim:ft=apparmor
at the end of the profile.
vim
comes with AppArmor highlighting automatically
enabled for files in /etc/apparmor.d/
.
When you enable this feature, vim colors the lines of the profile for you:
Comments
Ordinary read access lines
Capability statements and complain flags
Lines that grant write access
Lines that grant execute permission (either ix or px)
Lines that grant unconfined access (ux)
Syntax errors that will not load properly into the AppArmor modules
Use the apparmor.vim
and
vim
man pages and the :help
syntax
from within the vim editor for further vim help about
syntax highlighting. The AppArmor syntax is stored in
/usr/share/vim/current/syntax/apparmor.vim.
The following list contains the most important files and directories used by the AppArmor framework. If you intend to manage and troubleshoot your profiles manually, make sure that you know about these files and directories:
/sys/kernel/security/apparmor/profiles
Virtualized file representing the currently loaded set of profiles.
/etc/apparmor/
Location of AppArmor configuration files.
/etc/apparmor/profiles/extras/
A local repository of profiles shipped with AppArmor, but not enabled by default.
/etc/apparmor.d/
Location of profiles, named with the convention of replacing the
/
in paths with .
(not for the
root /
) so profiles are easier to manage. For
example, the profile for the program
/usr/sbin/smbd
is named
usr.sbin.smbd
.
/etc/apparmor.d/abstractions/
Location of abstractions.
/etc/apparmor.d/program-chunks/
Location of program chunks.
/proc/*/attr/current
Check this file to review the confinement status of a process and the
profile that is used to confine the process. The ps
auxZ
command retrieves this information
automatically.
An AppArmor® profile represents the security policy for an individual program instance or process. It applies to an executable program, but if a portion of the program needs different access permissions than other portions, the program can “change hats” to use a different security context, distinctive from the access of the main program. This is known as a hat or subprofile.
ChangeHat enables programs to change to or from a hat within an AppArmor profile. It enables you to define security at a finer level than the process. This feature requires that each application be made “ChangeHat-aware”, meaning that it is modified to make a request to the AppArmor module to switch security domains at specific times during the application execution. One example of a ChangeHat-aware application is the Apache Web server.
A profile can have an arbitrary number of subprofiles, but there are only
two levels: a subprofile cannot have further child profiles. A subprofile
is written as a separate profile. Its name consists of the name of the
containing profile followed by the subprofile name, separated by a
^
.
Subprofiles are either stored in the same file as the parent profile, or in a separate file. The latter case is recommended on sites with many hats—it allows the policy caching to handle changes at the per hat level. If all the hats are in the same file as the parent profile, then the parent profile and all hats must be recompiled.
An external subprofile that is going to be used as a hat, must begin with
the word hat
or the ^
character.
The following two subprofiles cannot be used as a hat:
/foo//bar { }
or
profile /foo//bar { }
While the following two are treated as hats:
^/foo//bar { }
or
hat /foo//bar { } # this syntax is not highlighted in vim
Note that the security of hats is considerably weaker than that of full profiles. Using certain types of bugs in a program, an attacker may be able to escape from a hat into the containing profile. This is because the security of hats is determined by a secret key handled by the containing process, and the code running in the hat must not have access to the key. Thus, change_hat is most useful with application servers, where a language interpreter (such as PERL, PHP, or Java) is isolating pieces of code such that they do not have direct access to the memory of the containing process.
The rest of this chapter describes using change_hat with
Apache, to contain Web server components run using mod_perl
and mod_php
.
Similar approaches can be used with any application server by providing an
application module similar to the mod_apparmor
described next in
Section 26.1.2, “Location and Directory Directives”.
For more information, see the change_hat
man page.
mod_apparmor
#
AppArmor provides a mod_apparmor
module (package apache2-mod-apparmor
) for the Apache
program. This module
makes the Apache Web server ChangeHat aware. Install it along with Apache.
When Apache is ChangeHat-aware, it checks for the following customized AppArmor security profiles in the order given for every URI request that it receives.
URI-specific hat. For example,
^www_app_name/templates/classic/images/bar_left.gif
DEFAULT_URI
HANDLING_UNTRUSTED_INPUT
If you install
apache2-mod-apparmor
, make
sure the module is enabled, and then restart Apache by executing the
following command:
tux >
a2enmod apparmor && sudo systemctl reload apache2
Apache is configured by placing directives in plain text configuration
files. The main configuration file is usually
/etc/apache2/httpd.conf
. When you compile Apache,
you can indicate the location of this file. Directives can be placed in
any of these configuration files to alter the way Apache behaves. When
you make changes to the main configuration files, you need to reload
Apache with sudo systemctl reload apache2
, so
the changes are recognized.
<VirtualHost> and </VirtualHost> directives are used to enclose a group of directives that will apply only to a particular virtual host. For more information on Apache virtual host directives, refer to http://httpd.apache.org/docs/2.4/en/mod/core.html#virtualhost.
The ChangeHat-specific configuration keyword is
AADefaultHatName
. It is used similarly to
AAHatName
, for example, AADefaultHatName
My_Funky_Default_Hat
.
It allows you to specify a default hat to be used for virtual hosts and
other Apache server directives, so that you can have different defaults
for different virtual hosts. This can be overridden by the
AAHatName
directive and is checked for only if there
is not a matching AAHatName
or hat named by the URI.
If the AADefaultHatName
hat does not exist, it falls
back to the DEFAULT_URI
hat if it exists/
If none of those are matched, it goes back to the “parent” Apache hat.
Location and directory directives specify hat names in the program configuration file so the Apache calls the hat regarding its security. For Apache, you can find documentation about the location and directory directives at http://httpd.apache.org/docs/2.4/en/sections.html.
The location directive example below specifies that, for a given
location, mod_apparmor
should use a specific hat:
<Location /foo/> AAHatName MY_HAT_NAME </Location>
This tries to use MY_HAT_NAME
for any URI beginning
with /foo/
(/foo/
,
/foo/bar
,
/foo/cgi/path/blah_blah/blah
, etc.).
The directory directive works similarly to the location directive, except it refers to a path in the file system as in the following example:
<Directory "/srv/www/www.example.org/docs"> # Note lack of trailing slash AAHatName example.org </Directory>
In the previous section you learned about mod_apparmor
and the way it helps you to secure a specific Web application. This
section walks you through a real-life example of creating a hat for a Web
application, and using AppArmor's change_hat feature to secure it.
Note that this chapter focuses on AppArmor's command line tools, as
YaST's AppArmor module has limited functionality.
For illustration purposes, let us choose the Web application called Adminer (http://www.adminer.org/en/). It is a full-featured SQL database management tool written in PHP, yet consisting of a single PHP file. For Adminer to work, you need to set up an Apache Web server, PHP and its Apache module, and one of the database drivers available for PHP—MariaDB in this example. You can install the required packages with
zypper in apache2 apache2-mod_apparmor apache2-mod_php5 php5 php5-mysql
To set up the Web environment for running Adminer, follow these steps:
Make sure apparmor
and php5
modules are enabled for Apache. To enable the modules in any case, use:
tux >
a2enmod apparmor php5
and then restart Apache with
tux >
sudo
systemctl restart apache2
Make sure MariaDB is running. If unsure, restart it with
tux >
sudo
systemctl restart mysql
Download Adminer from http://www.adminer.org, copy
it to /srv/www/htdocs/adminer/
, and rename it to
adminer.php
, so that its full path is
/srv/www/htdocs/adminer/adminer.php
.
Test Adminer in your Web browser by entering
http://localhost/adminer/adminer.php
in its URI
address field. If you installed Adminer to a remote server, replace
localhost
with the real host name of the server.
If you encounter problems viewing the Adminer login page,
try to look for help in the Apache error log
/var/log/apache2/error.log
. Another
reason you cannot access the Web page may be
that your Apache is already under AppArmor control and its AppArmor
profile is too tight to permit viewing Adminer. Check it
with aa-status
, and if needed, set Apache
temporarily in complain mode with
root #
sudo aa-complain usr.sbin.httpd2-prefork
After the Web environment for Adminer is ready, you need to configure
Apache's mod_apparmor
, so that AppArmor can detect accesses to Adminer and
change to the specific “hat”.
mod_apparmor
#
Apache has several configuration files under
/etc/apache2/
and
/etc/apache2/conf.d/
. Choose your preferred one
and open it in a text editor. In this example, the
vim
editor is used to create a new configuration
file /etc/apache2/conf.d/apparmor.conf
.
tux >
sudo
vim /etc/apache2/conf.d/apparmor.conf
Copy the following snippet into the edited file.
<Directory /srv/www/htdocs/adminer> AAHatName adminer </Directory>
It tells Apache to let AppArmor know about a change_hat event when the
Web user accesses the directory /adminer
(and any
file/directory inside) in Apache's document root. Remember, we placed
the adminer.php
application there.
Save the file, close the editor, and restart Apache with
tux >
sudo
systemctl restart apache2
Apache now knows about our Adminer and changing a “hat” for
it. It is time to create the related hat for Adminer in the AppArmor
configuration. If you do not have an AppArmor profile yet, create one
before proceeding. Remember that if your Apache's main binary is
/usr/sbin/httpd2-prefork
, then the related profile
is named /etc/apparmor.d/usr.sbin.httpd2-prefork
.
Open (or create one if it does not exist) the file
/etc/apparmor.d/usr.sbin.httpd2-prefork
in a text
editor. Its contents should be similar to the following:
#include <tunables/global> /usr/sbin/httpd2-prefork { #include <abstractions/apache2-common> #include <abstractions/base> #include <abstractions/php5> capability kill, capability setgid, capability setuid, /etc/apache2/** r, /run/httpd.pid rw, /usr/lib{,32,64}/apache2*/** mr, /var/log/apache2/** rw, ^DEFAULT_URI { #include <abstractions/apache2-common> /var/log/apache2/** rw, } ^HANDLING_UNTRUSTED_INPUT { #include <abstractions/apache2-common> /var/log/apache2/** w, } }
Before the last closing curly bracket (}
), insert
the following section:
^adminer flags=(complain) { }
Note the (complain)
addition after the hat
name—it tells AppArmor to leave the
adminer
hat in complain mode. That is because
we need to learn the hat profile by accessing Adminer later on.
Save the file, and then restart AppArmor, then Apache.
tux >
sudo
systemctl reload apparmor apache2
Check if the adminer
hat really is in complain
mode.
tux >
sudo
aa-status apparmor module is loaded. 39 profiles are loaded. 37 profiles are in enforce mode. [...] /usr/sbin/httpd2-prefork /usr/sbin/httpd2-prefork//DEFAULT_URI /usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT [...] 2 profiles are in complain mode. /usr/bin/getopt /usr/sbin/httpd2-prefork//adminer [...]
As we can see, the httpd2-prefork//adminer
is loaded
in complain mode.
Our last task is to find out the right set of rules for the
adminer
hat. That is why we set the
adminer
hat into complain mode—the
logging facility collects useful information about the access
requirements of adminer.php
as we use it via the Web
browser. aa-logprof
then helps us with creating the
hat's profile.
adminer
Hat #
Open Adminer in the Web browser. If you installed it locally, then the
URI is http://localhost/adminer/adminer.php
.
Choose the database engine you want to use (MariaDB in our case), and log in to Adminer using the existing database user name and password. You do not need to specify the database name as you can do so after logging in. Perform any operations with Adminer you like—create a new database, create a new table for it, set user privileges, and so on.
After the short testing of Adminer's user interface, switch back to console and examine the log for collected data.
tux >
sudo
aa-logprof Reading log entries from /var/log/audit/audit.log. Updating AppArmor profiles in /etc/apparmor.d. Complain-mode changes: Profile: /usr/sbin/httpd2-prefork^adminer Path: /dev/urandom Mode: r Severity: 3 1 - #include <abstractions/apache2-common> [...] [8 - /dev/urandom] [(A)llow] / (D)eny / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish / (O)pts
From the aa-logprof
message, it is clear that our
new adminer
hat was correctly detected:
Profile: /usr/sbin/httpd2-prefork^adminer
The aa-logprof
command will ask you to pick the
right rule for each discovered AppArmor event. Specify the one you want
to use, and confirm with . For more information
on working with the aa-genprof
and
aa-logprof
interface, see
Section 25.7.3.8, “aa-genprof—Generating Profiles”.
aa-logprof
usually offers several valid rules for
the examined event. Some are
abstractions—predefined sets of rules
affecting a specific common group of targets. Sometimes it is useful
to include such an abstraction instead of a direct URI rule:
1 - #include <abstractions/php5> [2 - /var/lib/php5/sess_3jdmii9cacj1e3jnahbtopajl7p064ai242]
In the example above, it is recommended hitting
and confirming with to allow the abstraction.After the last change, you will be asked to save the changed profile.
The following local profiles were changed. Would you like to save them? [1 - /usr/sbin/httpd2-prefork] (S)ave Changes / [(V)iew Changes] / Abo(r)t
Hit
to save the changes.
Set the profile to enforce mode with aa-enforce
tux >
sudo
aa-enforce usr.sbin.httpd2-prefork
and check its status with aa-status
tux >
sudo
aa-status apparmor module is loaded. 39 profiles are loaded. 38 profiles are in enforce mode. [...] /usr/sbin/httpd2-prefork /usr/sbin/httpd2-prefork//DEFAULT_URI /usr/sbin/httpd2-prefork//HANDLING_UNTRUSTED_INPUT /usr/sbin/httpd2-prefork//adminer [...]
As you can see, the //adminer
hat jumped from
complain to enforce mode.
Try to run Adminer in the Web browser, and if you encounter problems
running it, switch it to the complain mode, repeat the steps that
previously did not work well, and update the profile with
aa-logprof
until you are satisfied with the
application's functionality.
The profile ^adminer
is only available in the
context of a process running under the parent profile
usr.sbin.httpd2-prefork
.
When you use the Section 24.2, “Editing Profiles”) or when you add a new profile using (for instructions, refer to Section 24.1, “Manually Adding a Profile”), you are given the option of adding hats (subprofiles) to your AppArmor profiles. Add a ChangeHat subprofile from the window as in the following.
dialog (for instructions, refer topam_apparmor
#
An AppArmor profile applies to an executable program; if a portion of the
program needs different access permissions than other portions need, the
program can change hats via change_hat to a different role, also known as
a subprofile. The pam_apparmor
PAM module allows
applications to confine authenticated users into subprofiles based on
group names, user names, or a default profile. To accomplish this,
pam_apparmor
needs to be registered as a PAM
session module.
The package pam_apparmor
is not installed by
default, you can install it using YaST or zypper
.
Details about how to set up and configure
pam_apparmor
can be found in
/usr/share/doc/packages/pam_apparmor/README
after the
package has been installed. For details on PAM, refer to
Chapter 2, Authentication with PAM.
After creating profiles and immunizing your applications, openSUSE® Leap becomes more efficient and better protected as long as you perform AppArmor® profile maintenance (which involves analyzing log files, refining your profiles, backing up your set of profiles and keeping it up-to-date). You can deal with these issues before they become a problem by setting up event notification by e-mail, updating profiles from system log entries by running the aa-logprof tool, and dealing with maintenance issues.
When you receive a security event rejection, examine the access violation
and determine if that event indicated a threat or was part of normal
application behavior. Application-specific knowledge is required to make
the determination. If the rejected action is part of normal application
behavior, run aa-logprof
at the command line.
If the rejected action is not part of normal application behavior, this access should be considered a possible intrusion attempt (that was prevented) and this notification should be passed to the person responsible for security within your organization.
In a production environment, you should plan on maintaining profiles for all of the deployed applications. The security policies are an integral part of your deployment. You should plan on taking steps to back up and restore security policy files, plan for software changes, and allow any needed modification of security policies that your environment dictates.
Backing up profiles might save you from having to re-profile all your programs after a disk crash. Also, if profiles are changed, you can easily restore previous settings by using the backed up files.
Back up profiles by copying the profile files to a specified directory.
You should first archive the files into one file. To do this, open a
terminal window and enter the following as root
:
tux >
sudo
tar zclpf profiles.tgz /etc/apparmor.d
The simplest method to ensure that your security policy files are
regularly backed up is to include the directory
/etc/apparmor.d
in the list of directories that
your backup system archives.
You can also use scp
or a file manager like
Nautilus to store the files on some kind of storage media, the
network, or another computer.
Maintenance of security profiles includes changing them if you decide that your system requires more or less security for its applications. To change your profiles in AppArmor, refer to Section 24.2, “Editing Profiles”.
When you add a new application version or patch to your system, you should always update the profile to fit your needs. You have several options, depending on your company's software deployment strategy. You can deploy your patches and upgrades into a test or production environment. The following explains how to do this with each method.
If you intend to deploy a patch or upgrade in a test environment, the
best method for updating your profiles is to run
aa-logprof
in a terminal as root
. For
detailed instructions, refer to
Section 25.7.3.9, “aa-logprof—Scanning the System Log”.
If you intend to deploy a patch or upgrade directly into a production
environment, the best method for updating your profiles is to monitor
the system frequently to determine if any new rejections should be added
to the profile and update as needed using aa-logprof
.
For detailed instructions, refer to
Section 25.7.3.9, “aa-logprof—Scanning the System Log”.