Publication Date 14 Jul 2015
Copyright © 2006–2015 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 and Novell trademarks, see the Novell Trademark and Service Mark list http://www.novell.com/company/legal/trademarks/tmlist.html. All other third party trademarks are the property of their respective owners. A trademark symbol (®, ™ etc.) denotes a SUSE or Novell trademark; an asterisk (*) denotes a third party trademark.
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.
Contents
#include
Statementspam_apparmor
List of Figures
List of Tables
List of Examples
/etc/pam.d/sshd
)auth
Section (common-auth
)account
Section (common-account
)password
Section (common-password
)session
Section (common-session
)/etc/PolicyKit/PolicyKit.conf
fileapache.fc
file/etc/audit/audit.log
-s
-l
This manual introduces the basic concepts of system security on SUSE Linux Enterprise Server. It covers extensive documentation about the authentication mechanisms available on Linux, such as NIS or LDAP. It also deals with aspects of local security like access control lists, encryption and intrusion detection. In the network security part you learn how to secure your computers with firewalls and masquerading, and how to set up virtual private networks (VPN). This manual also shows you how to make use of the product's inherent security software like AppArmor (which lets you specify per program which files the program may read, write, and execute) or the auditing system that reliably collects information about any security-relevant events.
Many chapters in this manual contain links to additional documentation resources. These include additional documentation that is available on the system, as well as documentation available on the Internet.
For an overview of the documentation available for your product and the latest documentation updates, refer to http://www.suse.com/doc or to the following section.
We provide HTML and PDF versions of our books in different languages. The following manuals for users and administrators are available for this product:
Shows how to install single or multiple systems and how to exploit the product inherent capabilities for a deployment infrastructure. Choose from various approaches, ranging from a local installation or a network installation server to a mass deployment using a remote-controlled, highly-customized, and automated installation technique.
Covers system administration tasks like maintaining, monitoring, and customizing an initially installed system.
Introduces basic concepts of system security, covering both local and network security aspects. Shows how to make use of the product inherent security software like AppArmor (which lets you specify per program which files the program may read, write, and execute), and the auditing system that reliably collects information about any security-relevant events.
Deals with the particulars of installing and setting up a secure SUSE Linux Enterprise Server, and additional post-installation processes required to further secure and harden that installation. Supports the administrator with security-related choices and decisions.
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.
Offers an introduction to virtualization technology of your product. It features an overview of the various fields of application and installation types of each of the platforms supported by SUSE Linux Enterprise Server as well as a short description of the installation procedure.
Offers an introduction to setting up and managing virtualization with KVM (Kernel-based Virtual Machine) on SUSE Linux Enterprise Server. Learn how to manage KVM with libvirt or QEMU. The guide also contains detailed information about requirements, limitations, and support status.
AutoYaST is a system for installing one or more SUSE Linux Enterprise systems automatically and without user intervention, using an AutoYaST profile that contains installation and configuration data. The manual guides you through the basic steps of auto-installation: preparation, installation, and configuration.
Provides information about how to manage storage devices on a SUSE Linux Enterprise Server.
In addition to the comprehensive manuals, several quick start guides are available:
Lists the system requirements and guides you step-by-step through the installation of SUSE Linux Enterprise Server from DVD, or from an ISO image.
Gives a short overview how to enable and configure the auditing system and how to execute key tasks such as setting up audit rules, generating reports, and analyzing the log files.
Helps you understand the main concepts behind AppArmor®.
Gives a short introduction to LXC (a lightweight “virtualization” method) and shows how to set up an LXC host and LXC containers.
Find HTML versions of most product manuals in your installed system under
/usr/share/doc/manual
or in the help centers of your
desktop. Find the latest documentation updates at
http://www.suse.com/doc where you can download PDF or HTML
versions of the manuals for your product.
Several feedback channels are available:
For services and support options available for your product, refer to http://www.suse.com/support/.
To report bugs for a product component, log in to the Novell Customer Center from http://www.suse.com/support/ and select + .
We want to hear your comments about and suggestions for this manual and the other documentation included with this product. Use the User Comments feature at the bottom of each page in the online documentation or go to http://www.suse.com/doc/feedback.html and enter your comments there.
For feedback on the documentation of this product, you can also send a
mail to doc-team@suse.de
. 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 typographical conventions are used in this manual:
/etc/passwd
: directory names and filenames
placeholder
: replace
placeholder
with the actual value
PATH
: the environment variable PATH
ls, --help
: commands, options, and
parameters
user
: users or groups
Alt, Alt+F1: a key to press or a key combination; keys are shown in uppercase as on a keyboard
, + : menu items, buttons
►amd64 em64t ipf:
This paragraph is only relevant for the architectures
amd64
, em64t
, and
ipf
. The arrows mark the beginning and the end of the
text block.
◄
►ipseries zseries:
This paragraph is only relevant for the architectures
System z
and ipseries
. The arrows
mark the beginning and the end of the text block.
◄
Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.
Contents
One of the main characteristics of a Linux or UNIX system is its ability to handle several users at the same time (multiuser) and to allow these users to perform several tasks (multitasking) on the same computer simultaneously. Moreover, the operating system is network transparent. The users often do not know whether the data and applications they are using are provided locally from their machine or made available over the network.
With the multiuser capability, the data of different users must be stored separately, and security and privacy need to be guaranteed. Data security was already an important issue, even before computers could be linked through networks. Just like today, the most important concern was the ability to keep data available in spite of a lost or otherwise damaged data medium (a hard disk in most cases).
This section is primarily focused on confidentiality issues and on ways to protect the privacy of users, but it cannot be stressed enough that a comprehensive security concept should always include procedures to have a regularly updated, workable, and tested backup in place. Without this, you could have a very hard time getting your data back—not only in the case of some hardware defect, but also in the case that someone has gained unauthorized access and tampered with files.
There are several ways of accessing data:
personal communication with people who have the desired information or access to the data on a computer
directly through physical access from the console of a computer
over a serial line
using a network link
In all these cases, a user should be authenticated before accessing the resources or data in question. A Web server might be less restrictive in this respect, but you still would not want it to disclose your personal data to an anonymous user.
In the list above, the first case is the one where the highest amount of human interaction is involved (such as when you are contacting a bank employee and are required to prove that you are the person owning that bank account). Then, you are asked to provide a signature, a PIN, or a password to prove that you are the person you claim to be. In some cases, it might be possible to elicit some intelligence from an informed person just by mentioning known bits and pieces to win the confidence of that person. The victim could be led to reveal gradually more information, maybe without even being aware of it. Among hackers, this is called social engineering. You can only guard against this by educating people and by dealing with language and information in a conscious way. Before breaking into computer systems, attackers often try to target receptionists, service people working with the company, or even family members. In many cases, such an attack based on social engineering is only discovered at a much later time.
A person wanting to obtain unauthorized access to your data could also use the traditional way and try to get at your hardware directly. Therefore, the machine should be protected against any tampering so that no one can remove, replace, or cripple its components. This also applies to backups and even any network cables or power cords. Also secure the boot procedure, because there are some well-known key combinations that might provoke unusual behavior. Protect yourself against this by setting passwords for the BIOS and the boot loader.
Serial terminals connected to serial ports are still used in many places. Unlike network interfaces, they do not rely on network protocols to communicate with the host. A simple cable or an infrared port is used to send plain characters back and forth between the devices. The cable itself is the weakest point of such a system: with an older printer connected to it, it is easy to record any data being transferred thusly. What can be achieved with a printer can also be accomplished in other ways, depending on the effort that goes into the attack.
Reading a file locally on a host requires additional access rules than opening a network connection with a server on a different host. There is a distinction between local security and network security. The line is drawn where data must be put into packets to be sent somewhere else.
Local security starts with the physical environment at the location in
which computer is running. Set up your machine in a place where security
is in line with your expectations and needs. The main goal of local
security is to keep users separate from each other, so no user can
assume the permissions or the identity of another. This is a general
rule to be observed, but it is especially true for the user
root
, who holds system
administration privileges.
root
can take on the identity
of any other local user and read any locally-stored file without being
prompted for the password.
On a Linux system, passwords are not stored as plain text and the entered text string is not simply matched with the saved pattern. If this were the case, all accounts on your system would be compromised as soon as someone got access to the corresponding file. Instead, the stored password is encrypted and, each time it is entered, is encrypted again and the two encrypted strings are compared. This only provides more security if the encrypted password cannot be reverse-computed into the original text string.
This is actually achieved by a special kind of algorithm, also called trapdoor algorithm, because it only works in one direction. An attacker who has obtained the encrypted string is not able to get your password by simply applying the same algorithm again. Instead, it would be necessary to test all the possible character combinations until a combination is found that looks like your password when encrypted. With passwords eight characters long, there are quite a number of possible combinations to calculate.
In the seventies, it was argued that this method would be more secure
than others due to the relative slowness of the algorithm used, which
took a few seconds to encrypt just one password. In the meantime,
however, PCs have become powerful enough to do several hundred thousand
or even millions of encryptions per second. Because of this, encrypted
passwords should not be visible to regular users
(/etc/shadow
cannot be read by normal users). It
is even more important that passwords are not easy to guess, in case
the password file becomes visible due to some error. Consequently, it
is not really useful to “translate” a password like
“tantalize” into “t@nt@1lz3”.
Replacing some letters of a word with similar looking numbers (like writing the password “tantalize” as “t@nt@1lz3”) is not sufficient. Password cracking programs that use dictionaries to guess words also play with substitutions like that. A better way is to make up a word with no common meaning, something that only makes sense to you personally, like the first letters of the words of a sentence or the title of a book, such as “The Name of the Rose” by Umberto Eco. This would give the following safe password: “TNotRbUE9”. In contrast, passwords like “beerbuddy” or “jasmine76” are easily guessed even by someone who has only some casual knowledge about you.
Configure your system so it cannot be booted from a floppy or from a
CD, either by removing the drives entirely or by setting a BIOS
password and configuring the BIOS to allow booting from a hard disk
only. Normally, a Linux system is started by a boot loader, allowing
you to pass additional options to the booted kernel. Prevent others
from using such parameters during boot by setting an additional
password in /boot/grub/menu.lst
(see
Chapter 11, The Boot Loader GRUB (↑Administration Guide)). This is crucial to your system's 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.
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 when it was started. By following the above rule, minimize the
possible damage.
The permissions of all files included in the SUSE Linux Enterprise Server distribution
are carefully chosen. A system administrator who installs additional
software or other files should take great care when doing so,
especially when setting the permission bits. Experienced and
security-conscious system administrators always use the
-l
option with the command ls to
get an extensive file list, which allows them to detect any incorrect
file permissions immediately. An incorrect file attribute does not only
mean that files could be changed or deleted. These modified files could
be executed by root
or,
in the case of configuration files, programs could use such files with
the permissions of root
. This
significantly increases the possibilities of an attack. Attacks like
these are called cuckoo eggs, because the program (the egg) is executed
(hatched) by a different user (bird), just like a cuckoo tricks other
birds into hatching its eggs.
An SUSE® Linux Enterprise Server 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 has launched it, but with the
permissions of the file owner, in most cases
root
). An administrator
can use the file /etc/permissions.local
to add his
own settings.
To define which of the above files is used by SUSE Linux Enterprise Server's
configuration programs to set permissions, select in the section
of YaST. To learn more about the topic, read the comments in
/etc/permissions
or consult the manual page of
chmod
(man chmod
).
Special care must be taken whenever a program needs to process data that could be changed by a user, but this is more of an issue for the programmer of an application than for regular users. The programmer must make sure that his application interprets data in the correct way, without writing it into memory areas that are too small to hold it. Also, the program should hand over data in a consistent manner, using interfaces defined for that purpose.
A buffer overflow can happen if the actual size of a memory buffer is not taken into account when writing to that buffer. There are cases where this data (as generated by the user) uses up more space than what is available in the buffer. As a result, data is written beyond the end of that buffer area, which, under certain circumstances, makes it possible for a program to execute program sequences influenced by the user (and not by the programmer), rather than just processing user data. A bug of this kind may have serious consequences, especially if the program is being executed with special privileges (see Section 1.1.1.3, “File Permissions”).
Format string bugs work in a slightly different way, but again it is the user input that could lead the program astray. In most cases, these programming errors are exploited with programs executed with special permissions—setuid and setgid programs—which also means that you can protect your data and your system from such bugs by removing the corresponding execution privileges from programs. Again, the best way is to apply a policy of using the lowest possible privileges (see Section 1.1.1.3, “File Permissions”).
Given that buffer overflows and format string bugs are bugs related to the handling of user data, they are not only exploitable if access has been given to a local account. Many of the bugs that have been reported can also be exploited over a network link. Accordingly, buffer overflows and format string bugs should be classified as being relevant for both local and network security.
Contrary to popular opinion, there are viruses that run on Linux. However, the viruses that are known were released by their authors as a proof of concept that the technique works as intended. None of these viruses have been spotted in the wild so far.
Viruses cannot survive and spread without a host on which to live. In
this case, the host would be a program or an important storage area of
the system, such as the master boot record, which needs to be writable
for the program code of the virus. Owing to its multiuser capability,
Linux can restrict write access to certain files (this is especially
important with system files). Therefore, if you did your normal work
with root
permissions,
you would increase the chance of the system being infected by a virus.
In contrast, if you follow the principle of using the lowest possible
privileges as mentioned above, chances of getting a virus are slim.
Apart from that, you should never rush into executing a program from some Internet site that you do not really know. SUSE Linux Enterprise Server's RPM packages carry a cryptographic signature, as a digital label that the necessary care was taken to build them. Viruses are a typical sign that the administrator or the user lacks the required security awareness, putting at risk even a system that should be highly secure by its very design.
Viruses should not be confused with worms, which belong entirely to the world of networks. Worms do not need a host to spread.
Network security is important for protecting from an attack that is started outside the network. The typical login procedure requiring a username and a password for user authentication is still a local security issue. In the particular case of logging in over a network, differentiate between the two security aspects. What happens until the actual authentication is network security and anything that happens afterwards is local security.
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 make use of this feature in an impressive way. With X, it is basically no problem to log in at 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—just like someone stealing 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, just 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 would not be able to open any new
windows or X clients.
SSH (secure shell) can be used to encrypt a network connection completely and forward it to an X server transparently, without the encryption mechanism being perceived by the user. 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 14, SSH: Secure Network Operations.
![]() | |
If you do not consider the host where you log in to be a secure host, do not use X forwarding. With X forwarding enabled, an attacker could authenticate via your SSH connection to intrude on your X server and perpetrate various actions (reading, or sniffing, your keyboard input, for instance). |
As discussed in
Section 1.1.1.4, “Buffer Overflows and Format String Bugs”, buffer
overflows and format string bugs should be classified as issues
applying to both local and network security. As with the local variants
of such bugs, buffer overflows in network programs, when successfully
exploited, are mostly used to obtain
root
permissions. Even if
that is not the case, an attacker could use the bug to gain access to
an unprivileged local account to exploit other vulnerabilities that
might exist on the system.
Buffer overflows and format string bugs exploitable over a network link are certainly the most frequent form of remote attacks, in general. Exploits for these—programs to exploit these newly-found security holes—are often posted on security mailing lists. They can be used to target the vulnerability without knowing the details of the code. Over the years, experience has shown that the availability of exploit codes has contributed to more secure operating systems, obviously due to the fact that operating system makers were forced to fix the problems in their software. With free software, anyone has access to the source code (SUSE Linux Enterprise Server comes with all available source codes) and anyone who finds a vulnerability and its exploit code can submit a patch to fix the corresponding bug.
The purpose of a denial of service (DoS) attack is to block a server program or even an entire system, something that could be achieved by various means: overloading the server, keeping it busy with garbage packets, or exploiting a remote buffer overflow. Often, a DoS attack is made with the sole purpose of making the service disappear. However, once a given service has become unavailable, communications could become vulnerable to man-in-the-middle attacks (sniffing, TCP connection hijacking, spoofing) and DNS poisoning.
In general, any remote attack performed by an attacker who puts himself between the communicating hosts is called a man-in-the-middle attack. What almost all types of man-in-the-middle attacks have in common is that the victim is usually not aware that there is something happening. There are many possible variants. For example, the attacker could pick up a connection request and forward that to the target machine. Now the victim has unwittingly established a connection with the wrong host, because the other end is posing as the legitimate destination machine.
The simplest form of a man-in-the-middle attack is called sniffer (the attacker is “just” listening to the network traffic passing by). As a more complex attack, the “man in the middle” could try to take over an already established connection (hijacking). To do so, the attacker would need to analyze the packets for some time to be able to predict the TCP sequence numbers belonging to the connection. When the attacker finally seizes the role of the target host, the victims notice this, because they get an error message saying the connection was terminated due to a failure. The fact that there are protocols not secured against hijacking through encryption (which only perform a simple authentication procedure upon establishing the connection) makes it easier for attackers.
Spoofing is an attack where packets are modified
to contain counterfeit source data, usually the IP address. Most active
forms of attack rely on sending out such fake packets (something that,
on a Linux machine, can only be done by the superuser
(root
)).
Many of the attacks mentioned are carried out in combination with a DoS. If an attacker sees an opportunity to bring down a certain host abruptly, even if only for a short time, it makes it easier for him to push the active attack, because the host will not be able to interfere with the attack for some time.
DNS poisoning means that the attacker corrupts the cache of a DNS server by replying to it with spoofed DNS reply packets, trying to get the server to send certain data to a victim who is requesting information from that server. Many servers maintain a trust relationship with other hosts, based on IP addresses or hostnames. The attacker needs a good understanding of the actual structure of the trust relationships among hosts to disguise itself as one of the trusted hosts. Usually, the attacker analyzes some packets received from the server to get the necessary information. The attacker often needs to target a well-timed DoS attack at the name server as well. Protect yourself by using encrypted connections that are able to verify the identity of the hosts to which to connect.
Worms are often confused with viruses, but there is a clear difference between the two. Unlike viruses, worms do not need to infect a host program to live. Instead, they are specialized to spread as quickly as possible on network structures. The worms that appeared in the past, such as Ramen, Lion, or Adore, make use of well-known security holes in server programs like bind8 or lprNG. Protection against worms is relatively easy. Given that some time elapses between the discovery of a security hole and the moment the worm hits your server, there is a good chance that an updated version of the affected program is available on time. That is only useful if the administrator actually installs the security updates on the systems in question.
To handle security competently, it is important to observe some recommendations. You may find the following list of rules useful in dealing with basic security concerns:
Get and install the updated packages recommended by security announcements as quickly as possible.
Stay informed about the latest security issues:
http://lists.opensuse.org/opensuse-security-announce/ is the SUSE mailinglist for security announcements. It is a first-hand source of information regarding updated packages and includes members of SUSE's security team among its active contributors. You can subscribe to this list on page http://en.opensuse.org/openSUSE:Mailing_lists.
Find SUSE security advisories as a news feed at http://www.novell.com/linux/security/suse_security.xml.
bugtraq@securityfocus.com
is one of the best-known
security mailing lists worldwide. Reading this list, which receives
between 15 and 20 postings per day, is recommended. More information
can be found at http://www.securityfocus.com.
Discuss any security issues of interest on our mailinglist
opensuse-security@opensuse.org
.
According to the rule of using the most restrictive set of permissions
possible for every job, avoid doing your regular jobs as
root
. This reduces the risk
of getting a cuckoo egg or a virus and protects you from your own
mistakes.
If possible, always try to use encrypted connections to work on a remote machine. Using ssh (secure shell) to replace telnet, ftp, rsh, and rlogin should be standard practice.
Avoid using authentication methods based solely on IP addresses.
Try to keep the most important network-related packages up-to-date and subscribe to the corresponding mailing lists to receive announcements on new versions of such programs (bind, postfix, ssh, etc.). The same should apply to software relevant to local security.
Change the /etc/permissions
file to optimize the
permissions of files crucial to your system's security. If you remove
the setuid bit from a program, it might well be that it cannot do its
job anymore in the intended way. On the other hand, consider that, in
most cases, the program will also have ceased to be a potential
security risk. You might take a similar approach with world-writable
directories and files.
Disable any network services you do not absolutely require for your
server to work properly. This makes your system safer. Open ports, with
the socket state LISTEN, can be found with the program
netstat
. As for the options, it is recommended to
use netstat -ap
or
netstat -anp
. The
-p
option allows you to see which process is occupying
a port under which name.
Compare the netstat
results with those of a thorough
port scan done from outside your host. An excellent program for this
job is nmap
, which not only checks out the ports of
your machine, but also draws some conclusions as to which services are
waiting behind them. However, port scanning may be interpreted as an
aggressive act, so do not do this on a host without the explicit
approval of the administrator. Finally, remember that it is important
not only to scan TCP ports, but also UDP ports (options
-sS
and -sU
).
To monitor the integrity of the files of your system in a reliable way,
use the program AIDE
(Advanced Intrusion Detection
Environment), available on SUSE Linux Enterprise Server. Encrypt the database created
by AIDE to prevent someone from tampering with it. Furthermore, keep a
backup of this database available outside your machine, stored on an
external data medium not connected to it by a network link.
Take proper care when installing any third-party software. There have been cases where a hacker had built a trojan horse into the tar archive of a security software package, which was fortunately discovered very quickly. If you install a binary package, have no doubts about the site from which you downloaded it.
SUSE's RPM packages are gpg-signed. The key used by SUSE for signing is:
ID:9C800ACA 2000-10-19 SUSE Package Signing Key <build@suse.de> Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA
The command rpm --checksig
package.rpm
shows whether the checksum and the signature of an
uninstalled package are correct. Find the key on the first CD of the
distribution and on most key servers worldwide.
Check backups of user and system files regularly. Consider that if you do not test whether the backup works, it might actually be worthless.
Check your log files. Whenever possible, write a small script to search for suspicious entries. Admittedly, this is not exactly a trivial task. In the end, only you can know which entries are unusual and which are not.
Use tcp_wrapper
to restrict access to the individual
services running on your machine, so you have explicit control over
which IP addresses can connect to a service. For further information
regarding tcp_wrapper
, consult the manual pages of
tcpd and hosts_access (man 8
tcpd
,
man hosts_access
).
Use SuSEfirewall to enhance the security provided by
tcpd
(tcp_wrapper
).
Design your security measures to be redundant: a message seen twice is much better than no message at all.
If you use suspend to disk, consider configuring the suspend image
encryption using the configure-suspend-encryption.sh
script. The program creates the key, copies it to
/etc/suspend.key
, and modifies
/etc/suspend.conf
to use encryption for suspend
images.
If you discover a security-related problem (please check the available
update packages first), write an e-mail to
security@suse.de
. Please include a detailed description of
the problem and the version number of the package concerned. SUSE will
try to send a reply as soon as possible. You are encouraged to
pgp-encrypt your e-mail messages. SUSE's pgp key is:
ID:3D25D3D9 1999-03-06 SUSE Security Team <security@suse.de> Key fingerprint = 73 5F 2E 99 DF DB 94 C4 8F 5A A3 AE AF 22 F2 D5
This key is also available for download from http://www.suse.com/support/security/contact.html.
Contents
Contents
Abstract
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 systemwide 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. This process, however, is rather 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
SUSE Linux Enterprise Server.
/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:
TYPE
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 the help of 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 username of an expired account.
password
The purpose of this type of module is to enable the change of an authentication token. In most cases, 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.).
CONTROL
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, just 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.
MODULE_PATH
Contains a full filename 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 SUSE® Linux Enterprise Server, the directory is
/lib64/security
).
MODULE_ARGS
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 facilitate 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.
![]() | 64-Bit and 32-Bit Mixed Installations |
---|---|
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 install both versions of the PAM modules. |
Consider the PAM configuration of sshd as an example:
Example 2.1. PAM Configuration for sshd (/etc/pam.d/sshd
)¶
#%PAM-1.0auth requisite pam_nologin.so
auth include common-auth
account requisite pam_nologin.so
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
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. |
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 had 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_unix2.so
. See
Example 2.2, “Default Configuration for the auth
Section (common-auth
)”.
Example 2.2. Default Configuration for the auth
Section (common-auth
)¶
| |
|
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.
As soon as 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 just one module,
pam_unix2
. If pam_unix2
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
)”.
Example 2.3. Default Configuration for the account
Section (common-account
)¶
account required pam_unix2.so
Example 2.4. Default Configuration for the password
Section (common-password
)¶
password requisite pam_pwcheck.so nullok cracklib password required pam_unix2.so nullok use_authtok
Again, the PAM configuration of sshd involves just 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_pwcheck
module.
The pam_unix2
module used afterwards carries over
any old and new passwords from pam_pwcheck
, 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_pwcheck
. Whenever the
account
or the auth
type are
configured to complain about expired passwords, the
password
modules should also be used.
Example 2.5. Default Configuration for the session
Section (common-session
)¶
session required pam_limits.so session required pam_unix2.so session optional pam_umask.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_unix2
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 of the 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
]
VARIABLE
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”.
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 of
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
+ + to add the file server; see Section “Configuring Clients” (Chapter 28, Samba, ↑Administration Guide).
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 at all, 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-*-pc
) as well
as 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
/var/log/messages
.
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, you need to 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-
files.
pam-config only modifies the
*
-pccommon-
configuration
files. Removing these symbolic links effectively disables pam-config,
because pam-config only operates on the
*
-pccommon-
files and
these files are not put into effect without the symbolic links.
*
-pc
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 as well as the individual modules come with manual pages that provide a good overview of the functionality of all the components.
Abstract
As soon as 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 Chapter 29, Sharing File Systems with NFS (↑Administration Guide).
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 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 in conjunction 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 hostnames 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 hostname 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 Chapter 26, DHCP (↑Administration Guide).
Enter your NIS servers and separate their addresses by spaces. If you do not know your NIS server, click on
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.Contents
Abstract
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 and how to manage LDAP data with YaST.
In a network environment it is crucial to keep important information structured and to serve it quickly. A directory service—like the common yellow pages, keeps information available in a well-structured and readily-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 different 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 such 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 due to 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 (from 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, sendmail)
Address books for mail clients, like Mozilla, Evolution, and Outlook
Administration of zone descriptions for a BIND9 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 eases the administration of large amounts of data, as it can be searched more easily.
To get background knowledge on how a 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 respect to LDAP. Skip this introductory section if you already have some LDAP background knowledge and just want to learn how to set up an LDAP environment in SUSE Linux Enterprise Server. Read on at Section 4.3, “Configuring an LDAP Server with YaST” or Section 4.7, “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 4.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 e.g., RFC4519). Additionally there are Schemas available for many other use cases (e.g., Samba, NIS replacement, etc.). 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 4.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 and valid attribute values.
Table 4.1. Commonly Used Object Classes and Attributes¶
Object Class |
Meaning |
Example Entry |
Required Attributes |
---|---|---|---|
dcObject |
domainComponent (name components of the domain) |
example |
dc |
organizationalUnit |
organizationalUnit (organizational unit) |
doc |
ou |
inetOrgPerson |
inetOrgPerson (person-related data for the intranet or Internet) |
Geeko Linux |
sn and cn |
Example 4.1, “Excerpt from schema.core” shows an excerpt from a Schema directive with explanations.
Example 4.1. Excerpt from schema.core¶
attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName')DESC 'RFC2256: organizational unit this object belongs to'
SUP name )
objectclass ( 2.5.6.5 NAME 'organizationalUnit'
DESC 'RFC2256: an organizational unit'
SUP top STRUCTURAL
MUST ou
MAY (userPassword $ searchGuide $ seeAlso $ businessCategory
$ 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 |
An introduction to the use of Schemas can be found in the
OpenLDAP documentation. When installed, find it in
/usr/share/doc/packages/openldap2/guide/admin/guide.html
.
Use YaST to set up an LDAP server. Typical use cases for LDAP servers include the management of user account data and the configuration of mail, DNS, and DHCP servers.
To set up an LDAP server for user account data, make sure the
yast2-ldap-server
and
openldap2
packages are installed. Then proceed
as follows:
Start YaST as root
and select + to
invoke the configuration wizard.
Configure the Figure 4.2, “YaST LDAP 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: stand-alone server, master server in a replication setup, or replication (slave) server.
Select security options (
).It is strongly recommended to Step 4.
. For more information, see![]() | Password Encryption |
---|---|
Enabling TLS ensures passwords are sent encrypted over the network. When this option is not enabled, passwords are sent unencrypted. |
Also consider to use LDAP over SSL and certificates.
Check the
and click to exit the configuration wizard.For changes or additional configuration start the LDAP server module again and in the left pane expand Figure 4.4, “YaST LDAP 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 the 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 (DN or password). Enabling this option, however, 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 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.Enter the requested data:
Enter the base DN 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.
![]() | Locked Accounts in Security Sensitive Environments |
---|---|
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 the |
Enter 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 will be able to 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 LDAP server configuration by selecting
, you are ready to go with a basic working configuration for your LDAP server. To fine-tune this setup, make use of 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 LDAP server module (the
yast2-ldap-server
package) or an LDAP client
such as ldapmodify or
ldapsearch. Find more LDAP-related configuration
and system data in /etc/sysconfig/ldap
and
/var/lib/ldap
.
For more information on the dynamic configuration of OpenLDAP, see the OpenLDAP Administration Guide.
YaST includes a module to set up LDAP-based user management. If you did not enable this feature during the installation, start the module by selecting Section 4.4.1, “Configuring Basic Settings”.
+ . YaST automatically enables any PAM and NSS-related changes as required by LDAP and installs the necessary files. Simply connect your client to the server and let YaST manage users over LDAP. This basic setup is described inUse the YaST LDAP client to further configure the YaST group and user configuration modules. This includes manipulating the default settings for new users and groups and the number and nature of the attributes assigned to a user or group. LDAP user management allows you to assign far more and different attributes to users and groups than traditional user or group management solutions. This is described in Section 4.4.2, “Configuring the YaST Group and User Administration Modules”.
The basic LDAP client configuration dialog (Figure 4.6, “YaST: LDAP Client Configuration”) opens during installation if you choose LDAP user management or when you select + in the YaST Control Center in the installed system.
To authenticate users of your machine against an OpenLDAP server and to enable user management via OpenLDAP, proceed as follows:
Click
to enable the use of LDAP. Select instead if you want to use LDAP for authentication, but do not want other users to log in to this client.Enter the IP address of the LDAP server to use.
Enter the
to select the search base on the LDAP server. To retrieve the base DN automatically, click . YaST then checks for any LDAP database on the server address specified above. Choose the appropriate base DN from the search results given by YaST.If TLS or SSL-protected communication with the server is required, select
. Click to download a certificate in PEM format from a URL.
Select /home
.
Select
to have a user's home automatically created on the first user login.Click
to apply your settings.To modify data on the server as administrator, click Figure 4.7, “YaST: Advanced Configuration”.
. The following dialog is split into two tabs. SeeIn the
tab, adjust the following settings according to your needs:If the search base for users, passwords, and groups differs from the global search base specified in the
, enter these different naming contexts in , , and .
Specify the password change protocol. The standard method to use
whenever a password is changed is crypt
,
meaning that password hashes generated by crypt
are used. For details on this and other options, refer to the
pam_ldap
man page.
Specify the LDAP group to use with member
.
If a secure connection requires certificate checking, specify where your
in PEM format is located. Or specify a directory with certificates.If the LDAP server still uses LDAPv2, enable the use of this protocol version by selecting
.In
, adjust the following settings:Set the base for storing your user management data via
.
Enter the appropriate value for rootdn
value
specified in /etc/openldap/slapd.conf
to enable
this particular user to manipulate data stored on the LDAP server.
Enter the full DN (such as
cn=Administrator,dc=example,dc=com
) or activate
to have the base DN added
automatically when you enter cn=Administrator
.
Check
to create the basic configuration objects on the server to enable user management via LDAP.If your client machine needs to act as a file server for home directories across your network, check
.Use the
section to select, add, delete, or modify the password policy settings to use. The configuration of password policies with YaST is part of the LDAP server setup.Click
to leave the , then to apply your settings.Use Section 4.4.2, “Configuring the YaST Group and User Administration Modules”.
to edit entries on the LDAP server. Access to the configuration modules on the server is then granted according to the ACLs and ACIs stored on the server. Follow the procedures outlined inUse the YaST LDAP client to adapt the YaST modules for user and group administration and to extend them as needed. Define templates with default values for the individual attributes to simplify the data registration. The presets created here are stored as LDAP objects in the LDAP directory. The registration of user data is still done with the regular YaST modules for user and group management. The registered data is stored as LDAP objects on the server.
The dialog for module configuration (Figure 4.8, “YaST: Module Configuration”) allows the creation of new modules, selection and modification of existing configuration modules, and design and modification of templates for such modules.
To create a new configuration module, proceed as follows:
In the
click , then open the tab. Click and enter the LDAP server credentials.
Click suseUserConfiguration
and for a group configuration
choose suseGroupConfiguration
.
Choose a name for the new template (e.g.,
userConfig
). The content view shows a table listing
all attributes allowed in this module and their assigned values.
Accept the preset values or adjust the defaults to use in group and
user configurations by selecting the relevant attribute, pressing
cn
attribute of the module.
Clicking deletes the currently selected
module.
After you click
, the new module is added to the selection menu.The YaST modules for group and user administration embed templates with standard values. To edit a template associated with a configuration module, start the object template configuration (Figure 4.9, “YaST: Configuration of an Object Template”).
In the
dialog, click .Determine the values of the general attributes assigned to this template according to your needs or leave them empty. Empty attributes are deleted on the LDAP server.
Modify, delete, or add new default values for new objects (user or group configuration objects in the LDAP tree).
Connect the template to its module by setting the
susedefaulttemplate
attribute value of the module to
the DN of the adapted template.
![]() | |
The default values for an attribute can be created from other
attributes by using a variable instead of an absolute value. For
example, when creating a new user, |
Once all modules and templates are configured correctly and ready to run, new groups and users can be registered in the usual way with YaST.
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 username, login, and password in the
tab.Check the Section 4.4.2, “Configuring the YaST Group and User Administration Modules”.
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. The default values (as well as those of the password settings) can be defined with the procedure described inModify or accept the default
.Enter the Figure 4.10, “YaST: Additional LDAP Settings”).
tab, select the LDAP plug-in, and click to configure additional LDAP attributes assigned to the new user (seeClick
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 .To conveniently browse the LDAP directory tree and all its entries, use the YaST LDAP Browser:
Log in as root
.
Start
+ + .Enter the address of the LDAP server, the Administrator DN, and the password for the Root DN of this server (if you need both to read and write the data stored on the server).
Alternatively, choose
and do not provide the password to gain read access to the directory.The
tab displays the content of the LDAP directory to which your machine connected. Click to expand each item's submenu.To view any entry in detail, select it in the
view and open the tab.All attributes and values associated with this entry are displayed.
To change the value of any of these attributes, select the attribute, click
, enter the new value, click , and provide the Root DN password when prompted.Leave the LDAP browser with
.
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.
![]() | Upgrading an Old OpenLDAP Installation |
---|---|
YaST does not use |
To conveniently access the configuration back-end, you use SASL external
authentication. For example, the following ldapsearch
command executed as root
can be used to show the
complete slapd configuration:
ldapsearch -Y external -H ldapi:/// -b cn=config
Once the LDAP server is fully configured and all desired entries have
been made according to the pattern described in
Section 4.8, “Manually Administering LDAP Data”, start the LDAP server as
root
by entering
rcldap start
. To stop the server
manually, enter the command rcldap
stop
. Query the status of the running LDAP
server with rcldap status
.
Use the YaST runlevel editor, described in Section “Configuring System Services (Runlevel) with YaST” (Chapter 10, Booting and Configuring a Linux System, ↑Administration Guide), to have the server started and stopped automatically on system bootup and shutdown. It is also possible to create the corresponding links to the start and stop scripts with the insserv command from a command prompt as described in Section “Init Scripts” (Chapter 10, Booting and Configuring a Linux System, ↑Administration Guide).
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 is
able to 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 4.1, “Structure of an LDAP Directory” would look like the one in
Example 4.2, “An LDIF File”.
![]() | Encoding of LDIF Files |
---|---|
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. |
Example 4.2. An LDIF File¶
# 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:
ldapadd -x -Ddn_of_the_administrator
-W -ffile
.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 just like 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 filename. See the details of
running ldapadd in
Example 4.3, “ldapadd with example.ldif”.
Example 4.3. ldapadd with example.ldif¶
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 4.4, “LDIF Data for Tux” adds
Tux
to the new LDAP directory.
Example 4.4. LDIF Data for Tux¶
# 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 4.5, “Modified LDIF File tux.ldif”.
Example 4.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:
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:
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:
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:
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.
Contents
Active Directory* (AD) is a directory-service based on LDAP, Kerberos, and other services that is used by Microsoft Windows to manage resources, services, and people. In an MS Windows network, AD provides information about these objects, restricts access to them, and enforces policies. SUSE® Linux Enterprise Server lets you join existing AD 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 SUSE Linux Enterprise Server Linux client:
Both Nautilus (the GNOME file manager) and Dolphin or Konqueror (its KDE counterparts) support browsing shared resources through SMB.
Both Nautilus, Dolphin, and Konqueror support sharing folders and files as in Windows.
Through Nautilus and Konqueror, users are able to access their Windows user data and can edit, create, and delete files and folders on the Windows server. Users can access their data without having to enter their password multiple times.
Users are able to log in and access their local data on the Linux machine even if they are offline or the AD server is unavailable for other reasons.
This port of AD 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 applications of both desktops 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.
A brief technical background for most of these features is given in the following section.
Many system components need to interact flawlessly in order to integrate a Linux client into an existing Windows Active Directory domain. Figure 5.1, “Active Directory Authentication Schema” highlights the most prominent ones. The following sections focus on the underlying processes of the key events in AD 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 AD 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 4, 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.
The following client components process account and authentication data:
The most central part of this solution is the winbind daemon that is a part of the Samba project and handles all communication with the AD server.
NSS routines provide name service information. Naming service for both
users and groups is provided by nss_winbind
. This
module directly interacts with the winbind daemon.
User authentication for AD users is done by the
pam_winbind
module. The creation of user homes
for the AD users on the Linux client is handled by
pam_mkhomedir
. The
pam_winbind
module directly interacts with
winbindd. To learn more about PAM in general, refer to
Chapter 2, Authentication with PAM.
Applications that are PAM-aware, like the login routines and the GNOME and KDE display managers, 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 Window 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 managers of GNOME and KDE (GDM and KDM) have been extended to allow the handling of AD 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 a number of PAM modules as described
in Section 5.2, “Background Information for Linux AD Support”. The
pam_winbind
module used to authenticate clients
against Active Directory or NT4 domains is fully aware of Windows error
conditions that might prohibit a user's login. The Windows error codes
are translated into appropriate user-readable error messages that PAM
gives at login through any of the supported methods (GDM, KDM, 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 SUSE Linux Enterprise Server 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, pam_winbind
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.
SUSE Linux Enterprise Server supports local home directories for AD users. If configured through YaST as described in Section 5.3, “Configuring a Linux Client for Active Directory”, user homes are created at the first login of a Windows (AD) user into the Linux client. These home directories look and feel entirely the same as standard Linux user home directories and work independently of the AD domain controller. Using a local user home, it is possible to access a user's data on this machine (even when the AD 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 AD 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 AD 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, SUSE Linux Enterprise Server acquires a new Kerberos ticket as soon as the user has locked and unlocked the desktop (for example, using a desktop screen saver).
Before your client can join an AD 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 AD DNS server. Alternatively, configure your machine to use the AD 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 5.1, “Joining an AD Domain”.
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, just check the option, and leave the firewall module
with + .
You cannot log in to an AD domain unless the AD administrator has provided you with a valid user account for that domain. Use the AD username and password to log in to the AD domain from your Linux client.
Join an existing AD domain during installation (or by later activating SMB user authentication with YaST in the installed system). The domain join during installation is covered in Section “User Authentication Method” (Chapter 6, Installation with YaST, ↑Deployment Guide).
![]() | Domain Name |
---|---|
Joining a domain may not succeed if the domain name ends with
|
![]() | |
Currently only a domain administrator account, such as
|
To join an AD domain in a running system, proceed as follows:
Procedure 5.1. Joining an AD Domain¶
Log in as root
and start YaST.
Start
+ .
Enter the domain to join at Figure 5.2, “Determining Windows Domain Membership”). If the DNS settings on your host
are properly integrated with the Windows DNS server, enter the AD
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.
Check
to use the SMB source for Linux authentication.Check
to automatically create a local home directory for your AD user on the Linux machine.Check
to allow your domain users to log in even if the AD server is temporarily unavailable, or if you do not have a network connection.Select
, if you want to change the UID and GID ranges for the Samba users and groups. Let DHCP retrieve the WINS server only if you need it. This is the case when some of your machines are resolved only by the WINS system.Configure NTP time synchronization for your AD 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 AD server and click Figure 5.3, “Providing Administrator Credentials”).
(seeAfter you have joined the AD domain, you can log in to it from your workstation using the display manager of your desktop or the console.
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 AD credentials. Login is supported for both desktop environments (GNOME and KDE), the console, SSH, and any other PAM-aware application.
![]() | Offline Authentication |
---|---|
SUSE Linux Enterprise Server supports offline authentication, allowing you to log in to your client machine even when it is offline. See Section 5.2.3, “Offline Service and Policy Support” for details. |
To authenticate a GNOME client machine against an AD server, proceed as follows:
Select the domain.
Enter your Windows username and press Enter.
Enter your Windows password and press Enter.
To authenticate a KDE client machine against an AD server, proceed as follows:
Select the domain.
Enter your Windows username.
Enter your Windows password and press Enter.
If configured to do so, SUSE Linux Enterprise Server creates a user home directory on the local machine on the first login of each AD authenticated user. This allows you to benefit from the AD support of SUSE Linux Enterprise Server while still having a fully functional Linux machine at your disposal.
As well as logging into the AD client machine using a graphical front-end, you can log in using the text-based console login or even remotely using SSH.
To log in to your AD client from a console, enter
at the DOMAIN
\user
login:
prompt and provide the password.
To remotely log in to your AD client machine using SSH, proceed as follows:
At the login prompt, enter:
sshDOMAIN
\\user
@hostname
The \
domain and login delimiter is escaped with
another \
sign.
Provide the user's password.
SUSE Linux Enterprise Server has the ability to help a 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, SUSE Linux Enterprise Server 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 and KDM provide feedback about password expiration and the prompt for new passwords in an interactive mode. To change passwords in the display managers, just 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.To change your Windows password from the KDE desktop, proceed as follows:
Select
from the main menu.Select
from the section.Click
.Click
.Enter your current password.
Enter and confirm the new password and apply your settings with
.Leave the configuration dialog with
+ .Contents
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:
Primary—the first part of the principal, which can be the same as your username in the case of a user.
Instance—some optional
information characterizing the primary. This string is separated
from the primary by a /
.
Realm—this specifies your Kerberos realm. Normally, your realm is your domain name in uppercase letters.
Kerberos ensures that both client and server can be sure of each other's 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 referred to as 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 username. 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. This implies that you have 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.
Windows 2000 contains a Microsoft implementation of Kerberos 5. SUSE® Linux Enterprise Server uses the MIT implementation of Kerberos 5, find useful information and guidance in the MIT documentation at Section 6.5, “For More Information”.
Ideally, a user's one and 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 somewhat awkward 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 some 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 have 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, GDM, and KDM 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 different 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.4.1, “Kerberos Network Topology”. Choose an appropriate realm for your Kerberos setup, see Section 6.4.2, “Choosing the Kerberos Realms”. Carefully set up the machine that is to serve as the KDC and apply tight security, see Section 6.4.3, “Setting Up the KDC Hardware”. Set up a reliable time source in your network to make sure all tickets contain valid timestamps, see Section 6.4.4, “Configuring Time Synchronization”.
Configure the KDC and the clients, see Section 6.4.5, “Configuring the KDC” and Section 6.4.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.4.7, “Configuring Remote Kerberos Administration”. Create service principals for every service in your realm, see Section 6.4.8, “Creating Kerberos Service Principals”.
Various services in your network can make use of Kerberos. To add Kerberos password-checking to applications using PAM, proceed as outlined in Section 6.4.9, “Enabling PAM Support for Kerberos”. To configure SSH or LDAP with Kerberos authentication, proceed as outlined in Section 6.4.10, “Configuring SSH for Kerberos Authentication” and Section 6.4.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 Chapter 25, The Domain Name System (↑Administration Guide) 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 Chapter 24, Time Synchronization with NTP (↑Administration Guide) 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 just the minimum components needed to build a Kerberos infrastructure. Depending on the size and topology of your deployment, your setup may vary.
![]() | Configuring Subnet Routing |
---|---|
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 Section “Configuring Routing” (Chapter 22, Basic Networking, ↑Administration Guide) 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. You cannot set
up a realm named EXAMPLE.COM
, have two
“subrealms” named DEVELOPMENT
and
ACCOUNTING
underneath it, and expect the two
subordinate realms to somehow inherit principals from
EXAMPLE.COM
. Instead, you would have three separate
realms for which you would have to configure crossrealm authentication
for users from one realm to interact with servers or other users from
another realm.
For the sake of simplicity, let us assume you are setting up just 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, as well as 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 over the course of 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 either by running an NTP daemon in client mode on all these machines or by running ntpdate once a day from all clients (this solution probably works for a small number of clients only). 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 ntpdate via a cron entry. To configure your machine as an NTP client, proceed as outlined in Section “Configuring an NTP Client with YaST” (Chapter 24, Time Synchronization with NTP, ↑Administration Guide).
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 as well as 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
as
described in Section 6.4.6.2.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.4.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 him to manage the database.
The Kerberos ACL file is located under
/var/lib/kerberos/krb5kdc/kadm5.acl
. Refer to
Section 6.4.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.4.5.2, “Creating a Principal” for details.
Start the Kerberos Daemon. Once the KDC software is installed and properly configured, start the Kerberos daemon to provide Kerberos service for your realm. Refer to Section 6.4.5.3, “Starting the KDC” for details.
Create a Principal for Yourself. You need a principal for yourself. Refer to Section 6.4.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:
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:Re-enter KDC database master key to verify:
To verify, use the list command:
kadmin.local kadmin> 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 geeko
, proceed as
follows:
kadmin.local kadmin> ank geeko
You will see the following output:
geeko@EXAMPLE.COM's Password:Verifying password:
Next, create another principal named geeko/admin
by
typing ank geeko/admin
at the
kadmin prompt. The admin
suffixed
to your username is a role. Later, use this role
when administering the Kerberos database. A user can have several roles
for different purposes. Roles are basically completely different
accounts with similar names.
Start the KDC daemon and the kadmin daemon. To start the daemons
manually, enter rckrb5kdc start and
rckadmind start. Also make sure that KDC and kadmind
are started by default when the server machine is rebooted with the
command insserv krb5kdc
and
insserv kadmind
or use the
YaST runlevel editor.
Once the supporting infrastructure is in place (DNS, NTP) and the KDC has been properly configured and started, configure the client machines. You can either use YaST to configure a Kerberos client or use one of the two manual approaches described below.
Rather than manually editing all relevant configuration files when configuring a Kerberos client, let YaST do the job for you. You can either perform the client configuration during the installation of your machine or in the installed system as follows:
Log in as root
and select +
(Figure 6.2, “YaST: Basic Configuration of a Kerberos Client”).
Select
.To configure a DNS-based Kerberos client, proceed as follows:
DNS-Based Static Kerberos Client
![]() | Using DNS Support |
---|---|
The option cannot be selected if the DNS server does not provide such data. |
Click
to configure details on ticket-related issues, OpenSSH support, time synchronization, and extended PAM configurations.To configure a static Kerberos client, proceed as follows:
Set
, , and to the values that match your setup.Click
to configure details on ticket-related issues, OpenSSH support, time synchronization, and extended PAM configurations.To configure ticket-related options in the Figure 6.3, “YaST: Advanced Configuration of a Kerberos Client”), choose from the following options:
dialog (Specify the d, h, and m, with no blank space between the value and the unit).
and the in days, hours, or minutes (using the units of measurementTo forward your complete identity (to use your tickets on other hosts), select
.Enable the transfer of certain tickets by selecting
.Enable Kerberos authentication support for your OpenSSH client by selecting the corresponding check box. The client then uses Kerberos tickets to authenticate with the SSH server.
Exclude a range of user accounts from using Kerberos authentication
by providing a value for the root
).
Use
to set a value for the allowable difference between the time stamps and your host's system time.To keep the system time in sync with an NTP server, you can also set up the host as an NTP client by selecting
, which opens the YaST NTP client dialog that is described in Section “Configuring an NTP Client with YaST” (Chapter 24, Time Synchronization with NTP, ↑Administration Guide). After finishing the configuration, YaST performs all the necessary changes and the Kerberos client is ready to use.
For more information about the configuration of Section 6.5, “For More Information” and the manual page
man 5 krb5.conf, which is part of the
krb5-doc
package.
When configuring Kerberos, there are basically 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
hostnames 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 minor
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 hostnames.
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
hostname 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, just add additional
statements to the [realms]
section.
Also add a statement to this file that tells applications how to map
hostnames 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.foobar.com = 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.foobar.com
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 hostname. 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.hostname
, as shown here:
_kerberos.www.foobar.com. 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, just grant yourself the privilege to administer the database by putting the following line into the file:
geeko/admin *
Replace the username geeko
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:
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 geeko
:
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 joe 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 man8 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
present 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
,
where service
/hostname
@REALM
hostname
is the host's fully qualified
hostname.
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, he needs to type his password so Kerberos can decrypt the ticket. It would be quite inconvenient for the system administrator if he had 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:
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.
SUSE® Linux Enterprise Server 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 KDM (where the user
presents a password and would like the authenticating application to
obtain an initial Kerberos ticket on his behalf). To configure PAM
support for Kerberos, use the following command:
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 rcsshd
restart
.
To use Kerberos authentication with protocol version 2, enable it on the
client side as well. Do this either in the systemwide 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.
![]() | Additional Information |
---|---|
The file
|
![]() | Additional Directives for Protocol Version 2 |
---|---|
Since SLES 11 SP3, the |
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 basically a network protocol
designed for authentication. The SASL implementation is cyrus-sasl,
which supports a number of different 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
(/etc/init.d/ldap
) 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
chgrp ldap /etc/krb5.keytab 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:
ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM
Then in the shell run:
chown ldap.ldap /etc/openldap/ldap.keytab 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
rcldap restart
.
You are now able to automatically use tools such as ldapsearch with Kerberos authentication.
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: Olaf Kirch [...]
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). What this tells you is 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
joe@EXAMPLE.COM
corresponds to the LDAP
distinguished name
uid=joe,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.
To understand how this works, you need to know that when SASL
authenticates a user, OpenLDAP forms a distinguished name from the name
given to it by SASL (such as joe
) and the name of
the SASL flavor (GSSAPI
). The result would be
uid=joe,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 username 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.
The official site of the 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 paper at ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS gives quite an extensive insight to the basic principles of Kerberos, without being too difficult to read. It also provides a lot of opportunities for further investigation and reading about Kerberos.
The official Kerberos FAQ is available at http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html. The book Kerberos—A Network Authentication System by Brian Tung (ISBN 0-201-37924-4) offers extensive information.
If your system includes a fingerprint reader, you can use biometric authentication in addition to standard authentication via login and password. After registering their fingerprint, users can log in to the system either by swiping a finger on the fingerprint reader or by typing in a password. SUSE® Linux Enterprise Server supports most available fingerprint readers. For a list of supported devices, please refer to http://www.freedesktop.org/wiki/Software/fprint/libfprint
If the hardware check detects the fingerprint reader integrated with your
laptop (or connected to your system), the packages
libfprint
,
pam_fp
, and
yast2-fingerprint-reader
are automatically installed.
Currently, only one fingerprint per user can be registered. The user's
fingerprint data is stored to
/home/
.
login
/.fprint/
The PAM module pam_fp
supports fingerprint
authentication for the following applications and actions (although you
may not be prompted to swipe your finger in all cases):
Logging in to GDM/KDM or a login shell
Unlocking your screen on the GNOME/KDE desktop
Starting YaST and the YaST modules
Starting an application with root
permission:
sudo or gnomesu
Changing to a different user identity with su or
su -
username
![]() | Fingerprint Reader Devices and Encrypted Home Directories |
---|---|
If you want to use a fingerprint reader device, you must not use encrypted home directories (see Chapter 12, Managing Users with YaST (↑Deployment Guide) for more information). Otherwise logging in will fail, because decrypting during login is not possible in combination with an active fingerprint reader device. |
Procedure 7.1. Enabling Fingerprint Authentication
You can only use biometric authentication if PAM is configured accordingly. Usually, this is done automatically during installation of the packages when the hardware check detects a supported fingerprint reader. If not, manually enable the fingerprint support in YaST as follows:
Start YaST and select
+ .In the configuration dialog, activate
and click to save the changes and close the dialog.Now you can register a fingerprint for various users.
Procedure 7.2. Registering a Fingerprint
In YaST, click
+ to open the dialog. A list of users or groups in the system is displayed.Select the user for whom you want to register a fingerprint and click
.On the
tab, select the fingerprint entry and click to open the dialog.YaST prompts the user to swipe his finger until three readable fingerprints have been gathered.
![]() |
After the fingerprint has been acquired successfully, click
to close the dialog and the dialog for the user.
If you also want to use fingerprint authentication for starting YaST
or the YaST modules, you need to register a fingerprint for
root
, too.
To do so, set the filter in the root
entry and register a fingerprint for root
as described above.
After you have registered fingerprints for the desired users, click
to close the administration dialog and to save the changes.As soon as the user's fingerprint has been successfully registered, the user can choose to authenticate with either fingerprint or password for the actions and applications listed in Section 7.1, “Supported Applications and Actions”.
Currently, YaST does not offer verification or removal of fingerprints,
but you remove fingerprints by deleting the directory
/home/
.
login
/.fprint
For more technical details, refer to http://www.freedesktop.org/wiki/Software/fprint.
Contents
Abstract
The YaST module SUSE Linux Enterprise Server. 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 dialogs 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. Clicking on presents an overview of the setting and information on how to make it secure. To change a setting, click on the corresponding link in the Status column. Depending on the setting, the following entries are available:Clicking on this entry will toggle the status of the setting to either enabled or disabled.
Clicking on this entry will 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.
SUSE Linux Enterprise Server comes with three . These configurations affect all the settings available in the module. Each configuration can be modified to your needs using the dialogs available from the right pane. Choose between the following sets:
This setting is designed for a computer that has no network connection at all (including a connection to the Internet). It provides the least secure configuration of the predefined settings.
A configuration for a workstation with any kind of network connection (including a connection to the Internet).
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 have 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).
When this option is checked, any new password is checked that it consists of a mixture of characters, digits and special characters. If it fails to pass this test, a warning is issued upon the entering of the new password.
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).
If the user chooses a password with a length shorter than specified here, a warning will be issued.
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 will be able to shutdown the machine via the graphical login manager in this dialog. You can also specify how Ctrl+Alt+Del will be interpreted.
This dialog lets you configure security-related login settings:
In order 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.
With this option turned on, the last successful login attempt is
recorded in /var/log/lastlog
and displayed when
logging in. This data is also used by the command
finger.
![]() | |
Note that logging to |
When checked, the graphical login manager (e.g. gdm or kdm) 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 don't fit the above-mentioned categories are listed here:
SUSE Linux Enterprise Server 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.
Whenever a program is called without specifying the full path to the
executable, the system looks in the user's search path (defined by the
variable $PATH
) for the executable. By default the
current directory is not added to the search path. This setting
ensures that, for example, /bin/ls
and not the
trojan horse /
is executed when entering
ls. In order to start a program in the current
directory the command must be prefixed with current
directory
/ls./
.
When activating these options, the current directory
(.
) is appended to the search path. It is
recommended you not change the default.
The magic SysRq key is a keycombo that enables you to have some
control over the system even when it has crashed. The complete
documentation can be found at
/usr/src/linux/Documentation/sysrq.txt
(requires
installation of the kernel-source
package).
Abstract
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, PolicyKit 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, PolicyKit does not grant root
permissions to an
entire process, following the “least privilege” concept.
Each existing policy has a speaking name (its identifier), which is used with the command line tools and the graphical user interface.
At the moment, not all applications requiring privileges make use of PolicyKit. Find the most important policies available on SUSE® Linux Enterprise Server below, sorted into the categories where they are used.
Set scheduling priorities for the PulseAudio daemon |
Add, remove, edit, enable or disable printers |
Modify system and mandatory values with GConf |
Change the system time |
Manage and monitor local virtualized systems |
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 PolicyKit-enabled process carries out a privileged operation,
PolicyKit is asked whether this process is entitled to do so. PolicyKit 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, in most cases 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 has to authenticate.
The authentication is bound to the instance of the program currently running. Once the program is restarted, the user is required to authenticate again.
The authentication dialog box offers a check button
. If checked, the authentication is valid until the user logs out.The authentication dialog box offers a check button
. If checked, the user has 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 will not be able to carry out an action requiring authorization, even though the default implicit policy allows authorization by authentication.
Each application supporting PolicyKit 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 Linux Enterprise Server. SUSE Linux Enterprise Server comes with a predefined set of
privileges that override the upstream defaults. The default policies for
SUSE Linux Enterprise Server are defined in
/etc/polkit-default-privs.standard
and
/etc/polkit-default-privs.restrictive
. The
.standard
file defines privileges suitable for most
desktop systems. The .restrictive
set of
privileges is designed for machines administrated
centrally. It is active by default.
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 /etc/polkit-default-privs.standard
nor /etc/polkit-default-privs.restrictive
. In order
to define your own custom set of privileges, use
/etc/polkit-default-privs.local
. For details, refer
to Section 9.2.3.1, “Modifying Configuration Files for Implicit Privileges”.
To modify implicit privileges or to set explicit ones, you can either use the graphical
tool available with GNOME or KDE, use the command line tools shipped with PolicyKit, or modify the configuration files. While the GUI and the command line tools are a good solution for making temporary changes, editing the configuration files should be the preferred way to make permanent changes.![]() | Using the Authorizations Tool |
---|---|
|
Start the Authorizations tool from a desktop environment by pressing Alt+F2 and entering polkit-gnome-authorization or polkit-kde-authorization, respectively.
The
window is divided into two panes: The left-hand pane shows all policies available in a tree view, while the right-hand pane displays details for the policy selected and offers means to change it.The KDE and GNOME
dialogs are very similar. The most noticeable difference is the location where details about the chosen policy are displayed: the GNOME dialog displays them in a dedicated section on the right-hand pane. It holds the following information:: Unique string used by PolicyKit to identify the policy.
: this information explaining the purpose of the policy.
: A link to the organization that has issued this policy.
The KDE dialog shows the identifier string directly in the tree view on the left-hand pane, together with a short description, which is also displayed at the top of the right-hand pane, together with the vendor link.
Alter any settings from the right-hand pane, as described below:
In the GNOME dialog, click Section 9.1.2.1, “Implicit Privileges”. In KDE, you can directly select the authorization types from the drop-down list.
to choose an authorization type, as explained inClick
to restore the system defaults.![]() | Restrictions of the SUSE Linux Enterprise Server | function on
---|---|
With SUSE Linux Enterprise Server, refer to Section 9.2.4, “Restoring the Default Privileges”. , the tool always operates on the upstream defaults. To instead restore the defaults shipped with |
In this section you can
privileges to existing users or users. In both cases, choose a user and a . Users with a UID of less than 1000 are only shown when is checked. To delete an authorization, choose it from the list and click .PolicyKit comes with two command line tools for changing implicit privileges and for assigning explicit privileges. Each existing policy has got a speaking, unique name with which it can be identified and which is used with the command line tools. List all available policies with the command polkit-action.
polkit-action
When invoked with no parameters, the command
polkit-action shows a list of 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
.
See man 1 polkit-action for more information.
ACTION
![]() | Restrictions of polkit-action on SUSE Linux Enterprise Server |
---|---|
polkit-action always operates on the upstream defaults. Therefore it cannot be used to list or restore the defaults shipped with SUSE Linux Enterprise Server. To do so, refer to Section 9.2.4, “Restoring the Default Privileges”. |
polkit-auth
To print a list of explicit privileges for a specific user, use the following command:
polkit-auth --explicit-detail --user USER
Replace USER
with a valid username. If the
--user
option is left out, the command shows the
privileges for the user that executes the command. See man 1
polkit-auth for more information.
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 as well as explicit privileges by modifying configuration files.
SUSE Linux Enterprise Server 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.1.3, “Default Privileges”.
In order to define your custom set of privileges, use
/etc/polkit-default-privs.local
. Privileges
defined here will always take precedence over the ones defined in the
other configuration files. 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
For a list of all privilege identifiers, run the command
polkit-action. The following values are valid for
the session
parameters:
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
After editing /etc/polkit-default-privs.local
,
execute set_polkit_default_privs to activate your
settings.
Explicit privileges can be set in
/etc/PolicyKit/PolicyKit.conf
. This configuration
file is written in XML using the PolicyKit DTD. The file that is shipped
with SUSE Linux Enterprise Server already contains the necessary headers and the root
element <config>
. Place your edits inside the
<config>
tags.
match
Specify an action or a user. match
knows two
attributes, user
and action
,
but only a single attribute is allowed. Use nested
match
statements to combine attributes. POSIX
Extended Regular Expressions are allowed as attribute values.
user=USER
Specify one or more login names. Separate multiple names by the “|” symbol.
action=policy
Specify a policy by it's unique identifier. To get a list of all available policy identifiers use the command polkit-action.
return
Specify the answer PolicyKit will return. Takes a single attribute,
result=
with one
of the values listed under
Section 9.2.3.1, “Modifying Configuration Files for Implicit Privileges”.
value
define_admin_auth
Specify users or groups allowed to authorize with their own password
where normally the root
password would be required. Takes the
attributes user=
or USER
group=
, but
only one may be used at a time. Multiple attribute values must be
separated by “|”, Extended POSIX Regular Expressions
are not supported. Applies to all policies when used at the top
level, or to specific policies when used within
GROUP
<match>
statements.
Example 9.1. An example /etc/PolicyKit/PolicyKit.conf
file¶
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN" "http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd"><config version="0.1">
<match action="org.freedesktop.packagekit.system-update">
<match user="tux"> <return result="yes"/> </match> </match> <match action="org.freedesktop.policykit.*">
<match user="tux|wilber"> <return result="no"/> </match> </match> <define_admin_auth group="administrators"/>
</config>
The first three lines of the config file are the XML header. These lines are already present in the template file, leave them untouched. | |
The XML root element must always be present. The attribute
| |
A statement granting the user
| |
Withdraw privileges for all PolicyKit-related policies from the users
| |
This statement allows all members of the group
|
SUSE Linux Enterprise Server comes with a predefined set of privileges that is activated by default and thus overrides the upstream defaults. For details, refer to Section 9.1.3, “Default Privileges”.
Since the graphical PolicyKit tools and the command line tools always operate
on the upstream defaults, SUSE Linux Enterprise Server 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.
Procedure 9.1. Restoring the SUSE Linux Enterprise Server Defaults
Make sure /etc/polkit-default-privs.local
does
not contain any overrides of the default policies.
![]() | Custom Policy Configuration |
---|---|
Policies defined in
|
To reset all policies to the upstream defaults first and then apply the SUSE Linux Enterprise Server defaults:
rm -f /var/lib/PolicyKit-public/* && set_polkit_default_privs
Contents
Abstract
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.
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, as well.
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
is able to 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 had to use a number of
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 ReiserFS, Ext2, Ext3, 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 of the 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 as well as 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.
Table 10.1. ACL Entry Types¶
Type |
Text Form |
---|---|
owner |
|
named user |
|
owning group |
|
named group |
|
mask |
|
other |
|
Table 10.2. Masking Access Permissions¶
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 at all (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:
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
. mask
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 the chmod command to remove the write
permission from the group class bits, the output of the
ls command 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:
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:
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.
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 Konqueror.
Unfortunately, many editors and file managers still lack ACL support. When copying files with Emacs, for instance, the ACLs of these files are lost. 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 filename, 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).
Contents
Most users have some confidential data on their computer that third parties should not be able to access. The more you rely on mobile computing and on working in different environments and networks, the more carefully you should handle your data. The encryption of files or entire partitions is recommended if others have network or physical access to your system. Laptops or removable media, such as external hard disks or USB sticks, are prone to being lost or stolen. Thus, it is recommended to encrypt the parts of your file system that hold confidential data.
There are several ways to protect your data by means of encryption:
You can create an encrypted partition with YaST during installation or in an already installed system. Refer to Section 11.1.1, “Creating an Encrypted Partition during Installation” and Section 11.1.2, “Creating an Encrypted Partition on a Running System” for details. 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 an encrypted file on your hard disk or on a removable medium with YaST at any time. The encrypted file can then be used to store other files or folders. For more information, refer to Section 11.1.3, “Creating an Encrypted File as a Container”.
With SUSE Linux Enterprise Server, you can also create encrypted user home directories. When the user logs in to the system, the encrypted home directory is mounted and the contents are made available to the user. Refer to Section 11.2, “Using Encrypted Home Directories” for more information.
If you only have a small number of ASCII text files that hold sensitive or confidential data, you can encrypt them individually and protect them with a password using Kgpg or the vi editor. Refer to Section 11.3, “Using vi to Encrypt Single ASCII Text Files” for more information.
![]() | Encrypted Media Offers Limited Protection |
---|---|
The methods described in this chapter offer only a limited protection. You cannot protect your running system from being compromised. After the encrypted medium is successfully mounted, everybody with appropriate permissions has access to 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 have 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 it manually in the partitioning dialog.
![]() | Password Input |
---|---|
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.![]() | Additional Software Required |
---|---|
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 once it has been mounted.
To skip mounting the encrypted partition during start-up, click 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.
When you need to mount an encrypted partition which is not mounted during the boot process, open your favorite file manager and click on 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.
![]() | Activating Encryption on a Running System |
---|---|
It is also possible to create encrypted partitions on a running system. However, encrypting an existing partition destroys all data on it, and requires resizing 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 using a partition, it is possible to create an encrypted file, which can hold other files or folders containing confidential data. Such container files are created from the YaST Expert Partitioner dialog. Select
+ and enter the full path to the file and its size. If YaST should create the container file, activate the check box . Accept or change the proposed formatting settings and the file system type. Specify the mount point and make sure that is checked.Click
, enter your password for decrypting the file, and confirm with .The advantage of encrypted container files over encrypted partitions is that they can be added without repartitioning the hard disk. They are mounted with the help of a loop device and behave just like normal partitions.
YaST treats removable media (like external hard disks or USB flash drives) the same as any other hard disk. Container files or partitions on such media can be encrypted as described above. Do not, however, enable mounting at boot time, because removable media are usually only connected while the system is running.
If you encrypted your removable device with YaST, the KDE and GNOME
desktops automatically recognize the encrypted partition and prompt for
the password when the device is detected. If you plug in a FAT formatted
removable device while running KDE or GNOME, the desktop user entering
the password automatically becomes the owner of the device and can read
and write files. For devices with a file system other than FAT, change
the ownership explicitly for users other than root
to enable these
users to read or write files on the device.
To protect data in home directories from being stolen and consequent unauthorized access, use the YaST user management module to enable encryption of home directories. You can create encrypted home directories for new or existing users. To encrypt or decrypt home directories of already existing users, you need to know their login password. See Section “Managing Encrypted Home Directories” (Chapter 12, Managing Users with YaST, ↑Deployment Guide) for instructions.
Encrypted home partitions are created within a file container as
described in Section 11.1.3, “Creating an Encrypted File as a Container”. Two files
are created under /home
for each encrypted home
directory:
LOGIN
.img
The image holding the directory
LOGIN
.key
The image key, protected with the user's login password.
On login, the home directory automatically gets decrypted. Internally, it
works through the pam module called pam_mount. If
you need to add an additional login method that provides encrypted home
directories, you have to add this module to the respective configuration
file in /etc/pam.d/
. For more information see also
Chapter 2, Authentication with PAM and the man page of pam_mount
.
![]() | Security Restrictions |
---|---|
Encrypting a user's home directory does not provide strong security from other users. If strong security is required, the system should not be shared physically.
To enhance security, also encrypt the |
The disadvantage of using encrypted partitions is obvious: While the
partition is mounted, at least
root
can access the data. To
prevent this, vi can be used in encrypted mode.
Use vi -x
filename
to edit a new file. vi
prompts you to set a password, after which it encrypts the content of the
file. Whenever you access this file, vi requests the correct password.
For even more security, you can place the encrypted text file in an encrypted partition. This is recommended because the encryption used in vi is not very strong.
Abstract
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 on .Import your certificate depending on your type: use
to import server certificate, to identify other, and to identify yourself.Contents
Abstract
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 have 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 rootkit 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.
![]() | Initialize AIDE Database After Installation |
---|---|
Before you install your system, verify the checksum of your medium (see Section “Checking Media” (Chapter 36, Common Problems and Their Solutions, ↑Administration Guide)) to make sure you do not use a compromised source. After you have installed the system, initialize the AIDE database. To be really 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 SUSE Linux Enterprise Server. 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
checking options are used in the files section. Important options include
the following:
Table 13.1. Important AIDE Checking Options¶
Option |
Description |
---|---|
p |
Check for the file permissions of the selected files or directories. |
i |
Check for the inode number. Every filename 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. |
md5 |
Check if the md5 checksum of the file has changed. |
sha1 |
Check if the sha1 (160 Bit) 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 checking options. For a
complete list of available checking options, 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:
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:
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:
aide -i
Copy the generated database to a save location like a CD-R or DVD-R, a remote server or a USB 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:
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
After any configuration change, you always have to reinitialize 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:
aide --check
If the output is empty, everything is fine. If AIDE found changes, it displays a summary of changes, for example:
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:
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.
For the risk-averse administrator (and of course this is all about risk-aversion) 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 his traces.
To accomplish this task, AIDE must be run from a rescue system that is independent of the installed system. With SUSE Linux Enterprise Server 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.
Procedure 13.1. Starting a Rescue System with AIDE
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:
cp DVD1/suse/ARCH
/aideVERSION
.ARCH
.rpm /srv/ftp 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://mailman.cs.tut.fi/mailman/listinfo/aide.
Contents
Contents
Abstract
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 without the authorized user
knowing about it. 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 SUSE Linux Enterprise Server is OpenSSH.
SUSE Linux Enterprise Server installs the OpenSSH package by default providing the
commands ssh, scp, and
sftp. In the default configuration, remote access of a
SUSE Linux Enterprise Server system is only possible with the OpenSSH utilities, and only
if the sshd
is running and the
firewall permits access.
By using the ssh program, it is possible to log in to
remote systems and to work interactively. To log in to the host
sun
as user
tux
user one of the following commands:
ssh tux@sun ssh -l tux sun
If the username is the same on both machines, you may omit it: ssh sun. 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 just run non-interactive
commands on remote systems by running ssh
HOST
COMMAND
.
COMMAND
needs to be properly quoted. Multiple
commands can be concatenated as on a regular shell.
ssh root@sun "dmesg | tail -n 25" 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 remote 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.
This mechanism is deactivated in the default settings, but can be
permanently activated at any time in the systemwide configuration file
/etc/ssh/sshd_config
by setting
AllowAgentForwarding yes
.
scp copies files to or from a remote machine. If the
username on jupiter is different than the username on sun,
specify the latter using the username@host
format. If
the file should be copied into a directory other then 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.
# local -> remote scp ~/MyLetter.tex tux@sun:/tmp # remote -> local scp tux@sun:/tmp/MyLetter.tex ~
![]() | The -l Option |
---|---|
With the ssh command, the option |
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
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.
If you want to copy several files from and/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 (1) man page.
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' [...]
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 referred to as 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.
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.
![]() | Existing SSH Host Keys |
---|---|
If you install SUSE Linux Enterprise Server 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.
In case the public keys of a host have really changed (something that
needs to be verified before attempting to connect to such a server), the
offending keys can be removed with the command ssh-keygen
-r
HOSTNAME
In it's 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. Whats
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.
In order 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
).
In order to be able to log in without having to specify the remote user's
password, the public key of the “SSH user” must be present
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 username. SUSE Linux Enterprise Server is set up for using key-based authentication, covering setting up host-based authentication on SUSE Linux Enterprise Server is beyond the scope of this manual.
![]() | File Permissions for Host-Based Authentication |
---|---|
If the host-based authentication is to be used, the file
|
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
) be 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.
In order 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. In order to copy your personal key
stored under ~/.ssh/id_rsa.pub
you may use the
short form. In order to copy DSA keys or keys of other users, you need
to specify the path:
# ~/.ssh/id_rsa.pub ssh-copy-id -i tux@sun # ~/.ssh/id_dsa.pub ssh-copy-id -i ~/.ssh/id_dsa.pub tux@sun # ~notme/.ssh/id_rsa.pub ssh-copy-id -i ~notme/.ssh/id_rsa.pub tux@sun
In order to successfully copy the key, you need to enter the remote
user's password. To remove an existing key, manually edit
~/.ssh/authorized_keys
.
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 man 1 ssh-agent for details.
Once the ssh-agent is started, you need to add your keys by using ssh-add. It will prompt for the passphrase. Once entered, you can use the secure shell commands within the running session without having to provide your password.
On SUSE Linux Enterprise Server the ssh-agent is automatically started by the GNOME or KDE display managers. In order 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.
In a terminal session you need to manually start the ssh-agent and then call ssh-add afterwards. 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.
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.
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:
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 also in the OpenSSH package documentation under
/usr/share/doc/packages/openssh
.
To configure an sshd server with YaST run YaST and choose
+ . Then proceed as follows:
On the sshd
should listen on in
the table. The default port number is
22. Multiple ports are allowed. To add a new port, click
, enter the port number and click
. To delete a port, select it in the table, click
and confirm.
Select the features the sshd
daemon should support. To disable TCP forwarding, uncheck
. Disabling TCP forwarding does
not improve security unless users are also denied shell access, as they
can always install their own forwarders. See
Section 14.6, “Port Forwarding” for more information about
TCP forwarding.
To disable X forwarding, uncheck Section 14.1, “ssh—Secure Shell” for more information about X forwarding.
. If this option is disabled, any X11 forward requests by the client will return an error. However users can always install their own forwarders. SeeIn
determine, whether the connection between the server and clients should be compressed. After setting these options, click .
The /etc/motd
when a user logs in interactively. If
you want to disable connection of a user
root
, uncheck .
In
enter the maximum allowed number of authentication attempts per connection. specifies whether pure RSA authentication is allowed. This option applies to SSH protocol version 1 only. specifies whether public key authentication is allowed. This option applies to protocol version 2 only.On the
tab, determine which versions of the SSH protocol should be supported. You can choose to support version 1 only, version 2 only, or to support both SSH version 2 and 1.Under
, all supported ciphers are listed. You can remove a cipher by selecting it in the list and clicking . To add a cipher to the list, select it from the dropdown menu and click .Click
to save the configuration.The home page of OpenSSH
The OpenSSH Wikibook
Manpage of the OpenSSH daemon
Manpage of the OpenSSH SSH client configuration files
Manpage of several binary files to copy (scp, sftp), login (slogin, ssh), and manage keys.
Contents
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. With
the help of iptables—a generic table structure for the definition of
rule sets—precisely control the packets allowed to pass a network
interface. Such a packet filter can be set up quite easily with the help
of SuSEfirewall2 and the corresponding YaST module.
The components netfilter
and
iptables
are responsible for the filtering and
manipulation of network packets as well as 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 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 15.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 of all possible cases, 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 are actually matched.
Masquerading is the Linux-specific form of NAT (network address
translation). It can be used to connect a small LAN (where hosts use IP
addresses from the private range—see
Section “Netmasks and Routing” (Chapter 22, Basic Networking, ↑Administration Guide)) with the Internet
(where official IP addresses are used). For the LAN hosts to be able to
connect to the Internet, their private addresses are 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.
![]() | Using the Correct Network Mask |
---|---|
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, set
the variable IP_FORWARD
in the file
/etc/sysconfig/sysctl
to
IP_FORWARD=yes
.
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 a number of 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 provides and manages a link between networks while also controlling the data flow between them. 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
SUSE Linux Enterprise Server. For further information about packet filtering and
firewalling, read the Firewall HOWTO included in the
howto
package. If this package
is installed, read the HOWTO with
less /usr/share/doc/howto/en/txt/Firewall-HOWTO.gz
SuSEfirewall2 is a script that reads the variables set in
/etc/sysconfig/SuSEfirewall2
to generate a set of
iptables rules. It defines three security zones, although only the first
and the second one are considered in the following sample configuration:
Given that there is no way to control what is happening on the external network, the host needs to be protected from it. In most cases, the external network is the Internet, but it could be another insecure network, such as a WLAN.
This refers to the private network, in most cases the LAN. If the hosts on this network use IP addresses from the private range (see Section “Netmasks and Routing” (Chapter 22, Basic Networking, ↑Administration Guide)), enable network address translation (NAT), so hosts on the internal network can access the external one. All ports are open in the internal zone. The main benefit of putting interfaces into the internal zone (rather than stopping the firewall) is that the firewall still runs, so when you add new interfaces, they will be put into the external zone by default. That way an interface is not accidentally “open” by default.
While hosts located in this zone can be reached both from the external and the internal network, they cannot access the internal network themselves. This setup can be used to put an additional line of defense in front of the internal network, because the DMZ systems are isolated from the internal network.
Any kind of network traffic not explicitly allowed by the filtering rule set is suppressed by iptables. Therefore, each of the interfaces with incoming traffic must be placed into one of the three zones. For each of the zones, define the services or protocols allowed. The rule set is only applied to packets originating from remote hosts. Locally generated packets are not captured by the firewall.
The configuration can be performed with YaST (see
Section 15.4.1, “Configuring the Firewall with YaST”). It can also be made manually in
the file /etc/sysconfig/SuSEfirewall2
, which is well
commented. Additionally, a number of example scenarios are available in
/usr/share/doc/packages/SuSEfirewall2/EXAMPLES
.
![]() | Automatic Firewall Configuration |
---|---|
After the installation, YaST automatically starts a firewall on all configured interfaces. If a server is configured and activated on the system, YaST can modify the automatically-generated firewall configuration with the options or in the server configuration modules. Some server module dialogs include a button for activating additional services and ports. The YaST firewall configuration module can be used to activate, deactivate, or reconfigure the firewall. |
The YaST dialogs for the graphical configuration can be accessed from the YaST Control Center. Select
+ . The configuration is divided into seven sections that can be accessed directly from the tree structure on the left side.Set the start-up behavior in this dialog. In a default installation, SuSEfirewall2 is started automatically. You can also start and stop the firewall here. To implement your new settings in a running firewall, use
.All known network interfaces are listed here. To remove an interface from a zone, select the interface, press
, and choose . To add an interface to a zone, select the interface, press and choose any of the available zones. You may also create a special interface with your own settings by using .You need this option to offer services from your system to a zone from which it is protected. By default, the system is only protected from external zones. Explicitly allow the services that should be available to external hosts. After selecting the desired zone in
, activate the services from the list.Masquerading hides your internal network from external networks (such as the Internet) while enabling hosts in the internal network to access the external network transparently. Requests from the external network to the internal one are blocked and requests from the internal network seem to be issued by the masquerading server when seen externally. If special services of an internal machine need to be available to the external network, add special redirect rules for the service.
In this dialog, configure the UDP ports that allow broadcasts. Add
the required port numbers or services to the appropriate zone,
separated by spaces. See also the file
/etc/services
.
The logging of broadcasts that are not accepted can be enabled here. This may be problematic, because Windows hosts use broadcasts to know about each other and so generate many packets that are not accepted.
Configure whether the IPsec service should be available to the external network in this dialog. Configure which packets are trusted under
.There is another functionality under
: IPsec packets are packed in an encrypted format, so they have to be decrypted and you can configure the way the firewall will handle the decrypted packets. If you select , the decrypted IPsec packets will be trusted as if they came from the Internal Zone - although they could possibly come from the external one. Choose to avoid this situation.There are two rules for logging: accepted and not accepted packets. Packets that are not accepted are DROPPED or REJECTED. Select from
, , or .Here, set special firewall rules that allow connections, matching specified criteria such as source network, protocol, destination port, and source port. Configure such rules for external, internal, and demilitarized zones.
When finished with the firewall configuration, exit this dialog with
. A zone-oriented summary of your firewall configuration then opens. In it, check all settings. All services, ports, and protocols that have been allowed and all custom rules are listed in this summary. To modify the configuration, use . Press to save your configuration.
The following paragraphs provide step-by-step instructions for a
successful configuration. Each configuration item is marked as to
whether it is relevant to firewalling or masquerading. Use port range
(for example, 500:510
) whenever appropriate. Aspects
related to the DMZ (demilitarized zone) as mentioned in the
configuration file are not covered here. They are applicable only to a
more complex network infrastructure found in larger organizations
(corporate networks), which require extensive configuration and in-depth
knowledge about the subject.
First, use the YaST module System Services (Runlevel) to enable SuSEfirewall2 in
your runlevel (3 or 5 most likely). It sets the symlinks for the
SuSEfirewall2_* scripts in the /etc/init.d/rc?.d/
directories.
FW_DEV_EXT
(firewall, masquerading)
The device linked to the Internet. For a modem connection, enter
ppp0
. For an ISDN link, use
ippp0
. DSL connections use
dsl0
. Specify auto
to use the
interface that corresponds to the default route.
FW_DEV_INT
(firewall, masquerading)
The device linked to the internal, private network (such as
eth0
). Leave this blank if there is no internal
network and the firewall protects only the host on which it runs.
FW_ROUTE
(firewall, masquerading)
If you need the masquerading function, set this to
yes
. Your internal hosts will not be visible to
the outside, because their private network addresses (e.g.,
192.168.x.x
) are ignored by Internet routers.
For a firewall without masquerading, set this to
yes
if you want to allow access to the internal
network. Your internal hosts need to use officially registered IP
addresses in this case. Normally, however, you should
not allow access to your internal network from
the outside.
FW_MASQUERADE
(masquerading)
Set this to yes
if you need the masquerading
function. This provides a virtually direct connection to the Internet
for the internal hosts. It is more secure to have a proxy server
between the hosts of the internal network and the Internet.
Masquerading is not needed for services that a proxy server provides.
FW_MASQ_NETS
(masquerading) Specify the hosts or networks to masquerade, leaving a space between the individual entries. For example:
FW_MASQ_NETS="192.168.0.0/24 192.168.10.1"
FW_PROTECT_FROM_INT
(firewall)
Set this to yes
to protect your firewall host from
attacks originating in your internal network. Services are only
available to the internal network if explicitly enabled. Also see
FW_SERVICES_INT_TCP
and
FW_SERVICES_INT_UDP
.
FW_SERVICES_EXT_TCP
(firewall) Enter the TCP ports that should be made available. Leave this blank for a normal workstation at home that should not offer any services.
FW_SERVICES_EXT_UDP
(firewall) Leave this blank unless you run a UDP service and want to make it available to the outside. The services that use UDP include include DNS servers, IPsec, TFTP, DHCP and others. In that case, enter the UDP ports to use.
FW_SERVICES_ACCEPT_EXT
(firewall)
List services to allow from the Internet. This is a more generic form
of the FW_SERVICES_EXT_TCP
and
FW_SERVICES_EXT_UDP
settings, and more
specific than FW_TRUSTED_NETS
. The notation
is a space-separated list of
,
for example net
,protocol
[,dport
][,sport
]0/0,tcp,22
or
0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh
,
which means: allow a maximum of three SSH connects per minute from
one IP address.
FW_SERVICES_INT_TCP
(firewall)
With this variable, define the services available for the internal
network. The notation is the same as for
FW_SERVICES_EXT_TCP
, but the settings are
applied to the internal network. The variable
only needs to be set if FW_PROTECT_FROM_INT
is set to yes
.
FW_SERVICES_INT_UDP
(firewall)
See FW_SERVICES_INT_TCP
.
FW_SERVICES_ACCEPT_INT
(firewall)
List services to allow from internal hosts. See
FW_SERVICES_ACCEPT_EXT.
FW_SERVICES_ACCEPT_RELATED_*
(firewall)
This is how the SuSEfirewall2 implementation considers packets
RELATED
by netfilter.
For example, to allow finer grained filtering of Samba broadcast
packets, RELATED
packets are not accepted
unconditionally. Variables starting with
FW_SERVICES_ACCEPT_RELATED_
allow
restricting RELATED
packets handling to certain
networks, protocols and ports.
This means that adding connection tracking modules (conntrack
modules) to FW_LOAD_MODULES
does not
automatically result in accepting the packets tagged by those
modules. Additionally, you must set variables starting with
FW_SERVICES_ACCEPT_RELATED_
to a suitable
value.
FW_CUSTOMRULES
(firewall)
Uncomment this variable to install custom rules. Find examples in
/etc/sysconfig/scripts/SuSEfirewall2-custom
.
After configuring the firewall, test your setup. The
firewall rule sets are created by entering rcSuSEfirewall2
start as root
.
Then use telnet, for example, from an external host
to see whether the connection is actually denied. After that, review
/var/log/messages
, where you should see something
like this:
Mar 15 13:21:38 linux kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:80:c8:94:c3:e7:00:a0:c9:4d:27:56:08:00 SRC=192.168.10.0 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=15330 DF PROTO=TCP SPT=48091 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A061AFEBC0000000001030300)
Other packages to test your firewall setup are Nmap (portscanner) or
OpenVAS (Open Vulnerability Assessment System). The documentation of
Nmap is found at /usr/share/doc/packages/nmap
after
installing the package and the documentation of openVAS resides at
http://www.openvas.org.
The most up-to-date information and other documentation about the
SuSEfirewall2
package is found in
/usr/share/doc/packages/SuSEfirewall2
. The home page
of the netfilter and iptables project,
http://www.netfilter.org, provides a large collection of
documents in many languages.
Contents
Abstract
Nowadays, the Internet connection is cheap and available almost everywhere. It is important that the connection is as secure as possible. Virtual Private Network (VPN) is a secure network within a second, insecure network such as the Internet or WLAN. It can be implemented in different ways and serves several purposes. In this chapter, we focus on VPNs to link branch offices via secure wide area networks (WANs).
This section defines some term regarding to VPN and introduces 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 setup a VPN connection your IP packets are transferred over your secured tunnel. A tunnel can use a so-called tun or tap device. They are virtual network kernel drivers which implement the transmission of ethernet frames or ip frames/packets.
Any userspace program OpenVPN can attach itself to a tun or tap device to receive packets sent by your OS. 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 bridged VPN. Furthermore, it allows the user to tune MTU (Maximum Transfer Unit) to raise efficiency. However, in a heterogeneous environment NetBIOS broadcasts do not work if you do not have a Samba server on the gateway. If you need IPv6, each tun drivers on both ends must support this protocol explicitly. This scenario is depicted in Figure 16.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 if you want 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 scenarios 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.
The following example creates a point-to-point VPN tunnel. It
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
192.168.1.120
and your client the IP
address 192.168.2.110
. You can
modify these private IP addresses to your needs but make sure you select
addresses which do not conflict with other IP addresses.
![]() | Use It Only For Testing |
---|---|
This scenario is only useful for testing and is considered as an example to get familiar with VPN. Do not use this as a real world scenario to connect as it can compromise your security and the safety of your IT infrastructure! |
To configure a VPN server, proceed as follows:
Procedure 16.1. VPN Server Configuration¶
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:
openvpn --genkey --secret /etc/openvpn/secret.key
Copy the secret key to your client:
scp /etc/openvpn/secret.key root@192.168.2.110:/etc/openvpn/
Create the file /etc/openvpn/server.conf
with the
following content:
dev tun ifconfig 192.168.1.120 192.168.2.110 secret secret.key
If you use a firewall, start YaST and open UDP port 1194 (
+ + .
Start the OpenVPN service as root
:
rcopenvpn start
To configure the VPN client, do the following:
Procedure 16.2. VPN Client Configuration
Install the package openvpn
on your client VPN machine.
Create /etc/openvpn/client.conf
with the
following content:
remote IP_OF_SERVER
dev tun
ifconfig 192.168.2.110 192.168.1.120
secret secret.key
Replace the placeholder IP_OF_SERVER
in the
first line with either the domain name, or the public IP address of
your server.
If you use a firewall, start YaST and open UDP port 1194 as described in Step 5 of Procedure 16.1, “VPN Server Configuration”.
Start the OpenVPN service as root
:
rcopenvpn start
After the OpenVPN is successfully started, test if the tun device is available with the following command:
ifconfig tun0
To verify the VPN connection, use ping on both client and server to see if you can reach each other. Ping server from client:
ping -I tun0 192.168.1.120
Ping client from server:
ping -I tun0 192.168.2.110
The example shown in Section 16.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.
The general overview of this process involves the following steps explained in these sections:
Before a VPN connection gets 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 in Chapter 17, Managing X.509 Certification for more details.
To create a VPN root, server, and client CA, proceed as follows:
Procedure 16.3. Creating a VPN Server Certificate¶
Prepare a common VPN Certificate Authority (CA):
Start the YaST CA module.
Click
.Enter your VPN-Server-CA
.
Fill out the other fields 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 then appears in the overview.Create a VPN server certificate:
Select your created root CA from Step 1 and click .
Click the
tab and click + .Enter the openvpn.example.com
and proceed with
.
Enter your password twice and proceed with
.Review the summary. YaST displays the current settings for confirmation. Click
. The VPN server certificate is created and appears in the tab.Create VPN client certificates:
Make sure you are on the
tab and click + .Enter the client1.example.com
.
Enter the e-mail addresses for your client, something
like user1@client1.example.com
,
and click . Proceed with
.
Enter your password twice and proceed with
.Review the summary. YaST displays the current settings for confirmation. Click
. The VPN client certificate is created and appears in the tab.Repeat Step 3 if you need more clients.
After you have successfully finished Procedure 16.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:
Activate the
tab if you haven't done so yet.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 + .
Mark /etc/openvpn/ssl/client1.pk12
.
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 and select .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 filenames can
be used for the ca
, cert
, and
key
options in the OpenVPN configuration file
(see Example 16.1, “VPN Server Configuration File”).
The configuration file is mostly a summary of
/usr/share/doc/packages/openvpn/sample-config-files/server.conf
without the comments and with some small changes concerning some paths.
Example 16.1. VPN Server Configuration File¶
# /etc/openvpn/server.conf port 1194proto udp
dev tun0
# Security
pkcs12 ssl/client1.p12 # Enable one of these options:
# tls-verify openvpn.example.com # ns-cert-type server dh ssl/dh1024.pem server 192.168.1.120 255.255.255.0
ifconfig-pool-persist /var/run/openvpn/ipp.txt
# Privileges
user nobody group nobody # Other configuration
keepalive 10 120 comp-lzo persist-key persist-tun status /var/log/openvpn-status.log log-append /var/log/openvpn.log verb 4
The TCP/UDP port to which OpenVPN listens. You have to open up the port in the Firewall, see Chapter 15, Masquerading and Firewalls. The standard port for VPN is 1194, so in most cases you can leave that as it is. | |
The protocol, either UDP or TCP. | |
The tun or tap device, see Section 16.1.1, “Terminology” for the differences. | |
The following lines contain the relative or absolute path to the root
server CA certificate ( | |
Verifies the X509 name of a pending TLS connection
(option | |
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 it is a good idea to run the OpenVPN daemon with
reduced privileges. For this reason the group and user
| |
Several other configurations, see comment in the original
configuration from
|
After this configuration, you can see log messages from your OpenVPN
server under /var/log/openvpn.log
. When you have
started it for the first time, it should finish it with:
... Initialization Sequence Completed
If you do not see this message, check the log carefully. Usually OpenVPN gives you some hints what is wrong in your configuration file.
The configuration file is mostly a summary from
/usr/share/doc/packages/openvpn/sample-config-files/client.conf
without the comments and with some small changes concerning some paths.
Example 16.2. VPN Client Configuration File
# /etc/openvpn/client.conf clientdev tun
proto udp
remote
IP_OR_HOSTNAME
1194resolv-retry infinite nobind # Privileges
user nobody group nobody # Try to preserve some state across restarts. persist-key persist-tun # Security
ca ssl/ca.crt cert ssl/client.crt key ssl/client.key comp-lzo
We must specify 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. | |
Replace the placeholder | |
For security reasons it is a good idea to run the OpenVPN daemon with
reduced privileges. For this reason the group and user
| |
Contains the client files. For security reasons, it is better to have a separate file pair for each client. | |
Turns compression on. Use it only when the server has this parameter switched on as well. |
If you need to change name servers before or during your VPN session, use netconfig.
![]() | Differences between SUSE Linux Enterprise Desktop and SUSE Linux Enterprise Server |
---|---|
The following procedure is for SUSE Linux Enterprise Servers only without NetworkManager (with
ifup). SUSE Linux Enterprise Desktop installations use NetworkManager and must install
the |
Use the following procedure to change a name server:
Procedure 16.4. Changing Nameservers¶
Copy the scripts and make them executable:
cp /usr/share/doc/packages/openvpn/sample-scripts/client-netconfig.* \ /etc/openvpn/ chmod +x /etc/openvpn/client-netconfig.*
Add the following lines to
/etc/openvpn/client.conf
:
pull dhcp-options up /etc/openvpn/client-netconfig.up down /etc/openvpn/client-netconfig.down
If you need to specify a ranking list of fallback services, use the
NETCONFIG_DNS_RANKING
variable in
/etc/sysconfig/network/config
. The default value is
auto
which resolves to:
+strongswan +openswan +racoon +openvpn -avahi
Preferred service names have the +
prefix, fallback
services the -
prefix.
The following sections describe the setup of OpenVPN connections with the GNOME and KDE desktop tools.
To setup an OpenVPN connection in KDE4 that can be easily turned on or off, proceed as follows:
Make sure you have installed the
NetworkManager-openvpn-kde4
package with all dependencies resolved.
Right-click on a widget of your panel and select
+ .Select
.Right-click on the icon and choose
.Add a new VPN connection with
+ . A new window opens.Choose the
between or depending on what you have setup with your OpenVPN server.Insert the necessary files into the respective text fields. From our example configuration these are:
|
|
|
|
|
|
|
The user |
|
The password for the user |
If you have not used the KDE Wallet System, you are asked if you want to configure it. Follow the steps in the wizard. After you have finished this step, you are reverted back to the
dialog.Finish with
.Enable the connection with your Network manager applet.
To setup a OpenVPN connection in GNOME that can be easily turned on or off, proceed as follows:
Make sure you have installed the package
NetworkManager-openvpn-gnome
and have resolved all dependencies.
Start the Network Connection Editor with Alt+F2 and insert nm-connection-editor into the text field. A new window appears.
Select the
tab and click .Choose the VPN connection type, in this case
.Choose the
type. Select between or depending on the setup of your OpenVPN server.Insert the necessary files into the respective text fields. According to the example configuration, these are:
|
The user (only available when you have selected ) |
|
The password for the user (only available when you have selected ) |
|
|
|
|
|
|
Finish with
and .Enable the connection with your Network Manager applet.
For more information about VPN, visit:
http://www.openvpn.net: Homepage of VPN
man openvpn
/usr/share/doc/packages/openvpn/sample-config-files/
:
Examples of configuration files for different scenarios
/usr/src/linux/Documentation/networking/tuntap.txt
,
install the
kernel-source
package
Contents
Abstract
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 wish 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 that is also responsible for the other aspects of certificate management, such as publication, withdrawal, and renewal of certificates. An infrastructure of this kind is generally referred to as 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 17.1 shows the fields of a basic X.509 certificate in version 3.
Table 17.1. X.509v3 Certificate¶
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 17.2 shows the basic parts of a X.509 CRL.
Table 17.2. X.509 Certificate Revocation List (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 4, LDAP—A Directory Service. Chapter 31, The Apache HTTP Server (↑Administration Guide) 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 17.1. The text fields 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 fields 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 17.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 17.2).
tab (seeClick
and select . A dialog box opens.Enter the old and the new password.
Finish with
A sub-CA is created in exactly 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 17.2).
(seeClick
and select . This opens the same dialog as for creating a root CA.Proceed as described in Section 17.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.![]() | Check your Valid Period |
---|---|
Take into account that the valid period must be lower than the valid period in the root CA. |
Select the Section 17.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 17.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 hostname 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 17.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 17.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 17.2.3, “Creating or Revoking a Sub-CA”.
Click
+ .Choose the type the settings to change. The dialog for changing the defaults, shown in Figure 17.4, “YaST CA Module—Extended Settings”, then 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 17.2.3, “Creating or Revoking a Sub-CA” (for sub-CAs) and Section 17.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 17.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. Afterwards, 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 17.3, “Passwords during LDAP Export”).
Table 17.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 17.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 17.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 filename. 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 USB
stick. The |
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 a transport medium, such as a USB stick. |
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
.Detailed information about X.509 certificates, refer to http://www.ietf.org/html.charters/pkix-charter.html.
Contents
#include
Statementspam_apparmor
Many security vulnerabilities result from bugs in trusted programs. A trusted program runs with privileges that attackers would like to have. 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 for that application (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 and Tomcat).
The AppArmor–loadable kernel module and associated control scripts to enforce AppArmor policies on your SUSE® Linux Enterprise Server 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.
This document discusses the concept and design of AppArmor from a very technical point of view. It is available at http://forgeftp.novell.com/apparmor/LKML_Submission-June-07/techdoc.html.
Contents
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 19.3, “Choosing the Applications to Profile”.
Build the needed profiles as roughly outlined in Section 19.4, “Building and Modifying Profiles”. Check the results and adjust the profiles when necessary.
Keep track of what is happening on your system by running AppArmor reports and dealing with security events. Refer to Section 19.5, “Configuring AppArmor Event Notification and Reports”.
Update your profiles whenever your environment changes or you need to react to security events logged by AppArmor's reporting tool. Refer to Section 19.6, “Updating Your Profiles”.
AppArmor is installed and running on any installation of SUSE® Linux Enterprise Server 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
AppArmor is configured to run by default on any fresh installation of SUSE Linux Enterprise Server. 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
+ .Select
.
Select boot.apparmor
and click + .
Exit the YaST Runlevel tool with
.AppArmor will not be initialized on reboot, and stays inactive until you reenable it. Reenabling a service using the YaST Runlevel tool is similar to disabling it.
Toggle the status of AppArmor in a running system by using the AppArmor Control Panel. These changes take effect as soon as you apply them and survive a reboot of the system. To toggle AppArmor's status, proceed as follows:
Start YaST.
Select
+ .Select
. To disable AppArmor, uncheck this option.Exit the AppArmor Control Panel with
.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
.
Example 19.1. Output of aa-unconfined¶
19848 /usr/sbin/cupsd not confined 19887 /usr/sbin/sshd not confined 19947 /usr/lib/postfix/master not confined 29205 /usr/sbin/sshd confined by '/usr/sbin/sshd (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 |
---|---|
For more information about choosing the the right applications to profile, refer to Section 20.2, “Determining Programs to Immunize”. |
AppArmor on SUSE Linux Enterprise Server ships with a pre-configured 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. Both methods basically work the same 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
programname
or
Outline the basic profile by running
+ + and specifying the complete path to the application you want to profile.A basic profile is outlined and AppArmor is 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.
or
Analyze the logs by clicking
in the and following the instructions given in the wizard until the profile is completed.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.
Once all access permissions are set, your profile is set to enforce mode. The profile is applied and AppArmor restricts the application according to the profile just created.
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 24.6.3.2, “aa-complain—Entering Complain or Learning Mode” and Section 24.6.3.3, “aa-enforce—Entering Enforce Mode”.
Test your profile settings by performing every task you need with the application you just confined. Normally, the confined program runs smoothly and you do not notice AppArmor activities at all. 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
|
/var/log/messages
|
dmesg
|
To adjust the profile, analyze the log messages relating to this application again as described in Step 3. Determine the access rights or restrictions when prompted.
![]() | For More Information |
---|---|
For more information about profile building and modification, refer to Chapter 21, Profile Components and Syntax, Chapter 23, Building and Managing Profiles with YaST, and Chapter 24, Building Profiles from the Command Line. |
Set up event notification in AppArmor so you can review security events. Event Notification is an AppArmor feature that informs a specified e-mail recipient when systemic AppArmor activity occurs under the chosen severity level. This feature is currently available in the YaST interface.
To set up event notification in YaST, proceed as follows:
Make sure that a mail server is running on your system to deliver the event notifications.
Start YaST. Then select
+ . In , select .For each record type (
, , and ), set a report frequency, enter the e-mail address that should receive the reports, and determine the severity of events to log. To include unknown events in the event reports, check .![]() | Selecting Events to Log |
---|---|
Unless you are familiar with AppArmor's event categorization, choose to be notified about events for all security levels. |
Leave this dialog with
+ to apply your settings.Using AppArmor reports, you can read important AppArmor security events reported in the log files without manually sifting through the cumbersome messages only useful to the aa-logprof tool. You can decrease the size of the report by filtering by date range or program name.
To configure the AppArmor reports, proceed as follows:
Start YaST. Select
+ .Select the type of report to examine or configure from
, , and .Edit the report generation frequency, e-mail address, export format, and location of the reports by selecting
and providing the requested data.To run a report of the selected type, click
.Browse through the archived reports of a given type by selecting
and specifying the report type.or
Delete unneeded reports or add new ones.
![]() | For More Information |
---|---|
For more information about configuring event notification in AppArmor, refer to Section 27.2, “Configuring Security Event Notification”. Find more information about report configuration in Section 27.3, “Configuring Reports”. |
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 also be addressed using the
.To update your profile set, proceed as follows:
Start YaST and choose
+ .Adjust access or execute rights to any resource or for any executable that has been logged when prompted.
Leave YaST after you have answered all questions. Your changes are applied to the respective profiles.
![]() | For More Information |
---|---|
For more information about updating your profiles from the system logs, refer to Section 23.5, “Updating Profiles from Log Entries”. |
Contents
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 referred to as 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 at all. 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 to cover this kind of behavior.
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 21, Profile Components and Syntax, Chapter 23, Building and Managing Profiles with YaST, or Chapter 24, 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.
![]() | Background Information for AppArmor |
---|---|
To get a more in-depth overview of AppArmor and the overall concept behind it, refer to Section 18.1, “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 21.1, “Breaking a 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-unconfined detects any application running on your system that listens for network connections and is not protected by an AppArmor profile. Refer to Section 24.6.3.8, “aa-unconfined—Identifying Unprotected Processes” for detailed information about this tool.
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 24.6.3.1, “aa-autodep—Creating Approximate Profiles” for detailed information about this tool.
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 24.6.3.4, “aa-genprof—Generating Profiles” for detailed information about this tool.
aa-logprof interactively scans and reviews the log entries generated by an application that is confined by an AppArmor profile in complain mode. It assists you in generating new entries in the profile concerned. Refer to Section 24.6.3.5, “aa-logprof—Scanning the System Log” for detailed information about this tool.
aa-complain toggles the mode of an AppArmor profile from enforce to complain. Exceptions to rules set in a profile are logged, but the profile is not enforced. Refer to Section 24.6.3.2, “aa-complain—Entering Complain or Learning Mode” for detailed information about this tool.
aa-enforce toggles the mode of an AppArmor profile from complain to enforce. Exceptions to rules set in a profile are logged, but not permitted—the profile is enforced. Refer to Section 24.6.3.3, “aa-enforce—Entering Enforce Mode” for detailed information about this tool.
Once a profile has been built and is loaded, there are two ways in which it can get processed:
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. 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 (YaST or aa-logprof) to transform log events into improved profiles.
In enforce mode, violations of AppArmor profile rules, such as the profiled program accessing files not permitted by the profile, are detected. 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. Enforce toggles with complain mode.
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:
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 20.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 20.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 20.4.2, “Immunizing Network Agents”.
Conversely, unprivileged programs do not need to be profiled. For instance, a shell script might invoke the cp program to copy a file. Because cp does not have its own profile, it inherits the profile of the parent shell script, so can copy any files that the parent shell script's profile can read and write.
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/*
For root
's cron jobs, edit the tasks with crontab
-e and list root
's cron tasks with crontab
-l. You must be root
for these to work.
Once you find these programs, you can use the Section 23.1, “Adding a Profile Using the Wizard”.
to create profiles for them. Refer toAn automated method for finding network server daemons that should be profiled is to use the aa-unconfined tool. You can also simply view a report of this information in the YaST module (refer to Section 27.3.1.1, “Application Audit Report” for instructions).
The aa-unconfined tool uses the command netstat -nlp to inspect your 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:
2325 /sbin/portmap not confined 3702/usr/sbin/sshd
confined by '/usr/sbin/sshd
(enforce)' 4040 /usr/sbin/ntpd confined by '/usr/sbin/ntpd (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)' 5274 /sbin/dhcpcd 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 |
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-general@forge.novell.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 SUSE Linux Enterprise Server. We cannot guarantee that every profile will be included, but we make a sincere effort to include as much as possible so that end users can contribute to the security profiles that ship in SUSE Linux Enterprise Server.
Alternatively, use the AppArmor profile repository to make your profiles available to other users and to download profiles created by other AppArmor users and the AppArmor developers. Refer to Section 22.2, “Using the External Repository” for more information on how to use the AppArmor profile repository.
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.
SUSE Linux Enterprise Server,
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 AppArmor Section 23.1, “Adding a Profile Using the Wizard”.
to create profiles for them. Refer to
Because CGI programs are executed by the Apache Web server, the profile
for Apache itself, usr.sbin.httpd2-prefork
for
Apache2 on
SUSE Linux Enterprise Server,
must be modified to add execute permissions to each of these programs.
For instance, 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 instance,
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
Python script.
![]() | |
If you want the subprocess confinement module
( |
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 log file when AppArmor complains about access violations. See Chapter 27, 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 the local
system time:
/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
basically sufficient to display an HTML 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.
To find network server daemons and network clients (such as fetchmail, Firefox, amaroK or Banshee) that need to be profiled, you should inspect the open ports on your machine, 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 a 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. 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. |
Contents
#include
StatementsBuilding 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
Files
#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 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 20.2, “Determining Programs to Immunize”. To start building AppArmor profiles with YaST, proceed to Chapter 23, Building and Managing Profiles with YaST. To build profiles using the AppArmor command line interface, proceed to Chapter 24, Building Profiles from the Command Line.
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># a comment naming the application to confine /usr/bin/foo
{
#include <abstractions/base>
capability setgid
, network inet tcp
, link /etc/sysconfig/foo -> /etc/foo.conf,
/bin/mount ux, /dev/{,u}
random 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, /tmp/foo.pid wr, /tmp/foo.* lrw, /@{HOME}
/.foo_file rw, /@{HOME}/.foo_lock kw, owner
/shared/foo/** rw, /usr/bin/foobar cx,
/bin/** px -> bin_generic,
# a comment about foo's local (children)profile for /usr/bin/foobar. profile /usr/bin/foobar
{ /bin/bash rmix, /bin/cat rmix, /bin/more rmix, /var/log/foobar* rwl, /etc/foobar r, } # foo's hat, bar. ^bar
{ /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 21.5, “Network Access Control”. | |
A link pair rule specifying the source and the target of a link. See Section 21.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 21.7.7, “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 21.8.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 25, 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 (see the
chmod
and chown
man
pages) 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 otherwise in /var/log/messages
. In many cases,
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 21.8.7, “Named Profile Transitions”) or with the
change_profile
rule (see
Section 21.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 just like standard profiles except 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 21.8.2, “Discrete Local Profile Execute Mode (cx)”) or a named
profile transition (see
Section 21.8.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 25, 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 of the 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 (e.g. 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 may not be seen by the kernel and hence not
restricted by the new profile.
![]() | Safety of Domain Transitions |
---|---|
The |
#include
Statements¶
#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.
By default, AppArmor adds /etc/apparmor.d
to the path in
the #include
statement. AppArmor expects the include files
to be located in /etc/apparmor.d
. Unlike other
profile statements (but similar to C programs),
#include
lines do not end with a comma.
To assist you in profiling your applications, AppArmor provides three
classes of #include
s: abstractions, program chunks and
tunables.
Abstractions are #include
s 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 require some of the other files listed in the abstraction file
(depending on the local configuration as well as 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 statements are simply the word capability
followed by the name of the POSIX.1e capability as defined in the
capabilities(7)
man page.
AppArmor allows mediation of network access based on the address type and family. The following illustrates the network access rule syntax:
network [[<domain>][<type
>][<protocol
>]]
Supported domains: | |
Supported types: | |
Supported protocols: |
The AppArmor tools support only family and type specification. The AppArmor
module emits only network
in “access denied”
messages. And only these are output by the profile generation tools, both
YaST and command line.
domain
type
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.
network, network inet
, network inet6
, network inet stream
, network inet tcp
, network tcp
,
Allow all networking. No restrictions applied with regards 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. |
AppArmor explicitly distinguishes directory pathnames from file pathnames.
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
.
/some/random/example/** r
Give read access to files and directories under
/some/random/example
.
/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 |
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 have 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/syslog-ng { ... # chrooted applications @{CHROOT_BASE}/var/lib/*/dev/log w, @{CHROOT_BASE}/var/log/** w, ... }
![]() | |
With the current AppArmor tools, variables can only be used when manually editing and maintaining a profile. |
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:
alias /home/ -> /mnt/users/
![]() | |
With the current AppArmor tools, alias rules can only be used when manually
editing and maintaining a profile. Whats more, they are deactivated by
disabled. Enable alias rules by editing
|
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 just 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 (with the exception that the destination does not need link access).
The link mode grants permission to create links to arbitrary files,
provided the link has a subset of the permissions granted by the target
(subset permission test). 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. To force the rule to
require the test the subset
keyword is used. The
following rules are equivalent:
/link l, link subset /link -> /**,
![]() | |
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. |
The file rules can be extended so that they can be conditional upon the
the user being the owner of the file (the fsuid has to match the file's
uid). For this purpose the owner
keyword is prepended
to the rule. Owner conditional rules accumulate just as regular file
rules.
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.
![]() | Precedence of Regular File Rules |
---|---|
Owner conditional rules are considered a subset of regular file rules. If a regular file rule overlaps with an owner conditional file rule, the resultant permissions will be that of the regular file rule. |
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, prepend the deny
entry with the keyword audit
.
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, /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 make use of 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.
Execute modes, also named profile transitions, consist of the following modes:
|
Discrete profile execute mode |
|
Discrete local profile execute mode |
|
Unconstrained 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.
![]() | Using the Discrete Profile Execute Mode |
---|---|
|
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.
![]() | Limitations of the Discrete Local Profile Execute Mode (cx) |
---|---|
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 unconstrained execution rights, it is possible
to bypass the mandatory constraints imposed on all confined processes.
For more information about what is constrained, see the
apparmor(7)
man page.
![]() | Using Unconstrained Execute Mode (ux) |
---|---|
Use |
This mode is incompatible with Ux
,
px
, Px
, and ix
.
The clean exec modes allow the named program to run in
px
, cx
and ux
mode, but AppArmor invokes the Linux kernel's unsafe_exec
routines to scrub the environment, similar to setuid programs. The clean
exec modes are specified with an uppercase letter:
Px
, Cx
and Ux
.
See the man page of ld.so(8) for some information
about setuid and setgid environment scrubbing.
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 who's 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 in conjunction 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 { ... } }
![]() | Difference Between Normal and Named Transitions |
---|---|
When used with globbing, normal transitions provide a “one to
many” relationship— 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
|
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
. 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
AppArmor provides the ability to set and control an application's resource
limits (rlimits, also known as ulimits). By default AppArmor does not control
applications 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 has the ability to further reduce the applications rlimits.
AppArmor's rlimit rules will also provide mediation of setting an application's hard limits, should it try to raise them. The application will not be able to 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 once 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 rlimitresource
<=value
,
where resource
and
value
are to be replaced with the following
values:
cpu
currently not supported
fsize
, data
, stack
,
core
, rss
, as
,
memlock
, msgqueue
a number in bytes, or a number with a suffix where the suffix can be K (kilobytes), M (megabytes), G (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 given time. Once 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
prepended to 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 just 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 read or write. |
Audit control can be combined with owner conditional file rules to provide auditing when users access files they own (at the moment it is not possible to audit files they don't own):
audit owner /home/*/.ssh/** rw,
Normally AppArmor only restricts existing native Linux controls and does not grant additional privileges. Therefore a program, having been granted write access to a file via its profile, would not be able to actually write to this file as long as the mode bits are set to read-only.
The only exception to this strict rule is the set
capability
rule. This provides the ability to give non-root
users administrative privileges, as defined in the
capabilities(7)
man page. Contrary to setting a
program to setuid or using file system capabilities (that apply to single
programs only), the set capability rule allows the user to apply
capabilities to multiple programs running under a specific profile (by
using ix transitions). For security reasons, set capability rules will
not be inherited (once a program leaves the profile, it loses the
elevated privilege).
![]() | Use set capabilities Rules with Extreme Caution |
---|---|
Using the set capabilities rules allows to give processes |
To set a capability in a profile the keyword “set” is prepended to a capability rule. Setting a capability also implicitly adds a capability rule allowing that capability.
set capability cap_chown,
![]() | |
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 ships a set of profiles enabled by default and created by the AppArmor
developers, and kept under the /etc/apparmor.d
. In
addition to these profiles,
SUSE Linux Enterprise Server
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
.
AppArmor also supports the use of an external profile repository. This repository is maintained by Novell and allows you to download profiles generated by Novell and other AppArmor users as well as uploading your own. Find the profile repository at http://apparmor.opensuse.org.
The AppArmor tools (YaST and 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 one inactive profile in your local repository, you are asked
whether you would like 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 further adjustments will be done to the active
profile under /etc/apparmor.d
.
The external AppArmor profile repository at http://apparmor.opensuse.org serves two main purposes: Allowing users to either browse and download profiles created by other users and uploading their profiles to be able to easily use them on different machines. A valid login on the profile repository server is required for uploading profiles. Simply downloading profiles from the server does not require a login.
![]() | Using the AppArmor Profile Repository |
---|---|
When using the profile repository in your deployment, keep in mind that the profiles maintained in the repository are primarily targeted at profile developers and might probably need fine-tuning before they suit your particular needs. Please test the downloaded profiles extensively before deploying them to your live setup, and adjust them if necessary. |
Once properly configured, both the YaST and the command line tools support the use of an external profile repository. The initial configuration takes place when you start the YaST Add Profile Wizard, the Update Profile Wizard, aa-genprof, or aa-logprof to create or update a profile that already exists on the repository server:
Determine whether to use the profile repository.
Enable the repository for profile downloads.
Once you have created or modified a profile, determine whether the tools need to be able to upload your profile to the repository.
If you choose to upload profiles to the repository, enter your credentials for the repository server.
The configuration of the repository is done by editing two configuration
files, /etc/apparmor/logprof.conf
and
/etc/apparmor/respository.conf
.
The /etc/apparmor/logprof.conf
file contains a
section called [repository]
.
distro
determines the version of SUSE Linux Enterprise Server used
on your system for which the AppArmor tools need to search profiles on the
server. url
holds the server URL and
preferred_user
tells the AppArmor tools to prefer
profiles created by the novell
user. Those profiles
were created, tested and approved by members of the SUSE development
team.
... [repository] distro = opensuse10.3 url = http://apparmor.opensuse.org/backend/api preferred_user = novell ...
The /etc/apparmor/repository.conf
file is created
during the configuration process with the AppArmor tools. It contains your
authentication data and specifies which actions to enable with regards
to the profile repository. If you opt for profile download and do not
want to be able to upload your own profiles enabled
is set to yes
while upload
is set
to no
.
[repository] enabled = yes upload = yes user = tux pass = XXXXX
Once initially configured through the AppArmor tools, the configuration can only be changed manually.
While creating a profile from scratch or updating an existing profile by
processing reject messages in the log, the AppArmor tools search the
repository for a matching profile. If the search is successful, the
profile or the list of profiles is displayed and you can view them and
choose the one that best matches your setup. As soon as you have chosen
a profile, it gets copied to the local machine (to the
/etc/apparmor.d
directory) and activated.
Alternatively, you can choose to ignore the profile on the repository
and create your own one from scratch.
After a profile has been created or updated, the AppArmor tools that a profile also present in the repository has been changed or that a new one has been created. If your system is configured to upload profiles to the repository, you are prompted to provide a ChangeLog to document your changes before the changes are uploaded to the server. These changes are only synched to the repository, but not to the creator of the original profile.
Contents
YaST provides an easy way to build profiles and manage AppArmor®. 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 24, 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.
The right frame shows the AppArmor options:
For detailed steps, refer to Section 23.1, “Adding a Profile Using the Wizard”.
Add a AppArmor profile for an application on your system without the help of the wizard. For detailed steps, refer to Section 23.2, “Manually Adding a Profile”.
Edits an existing AppArmor profile on your system. For detailed steps, refer to Section 23.3, “Editing Profiles”.
Deletes an existing AppArmor profile from your system. For detailed steps, refer to Section 23.4, “Deleting a Profile”.
For detailed steps, refer to Section 23.5, “Updating Profiles from Log Entries”.
For detailed steps, refer to Section 27.3, “Configuring Reports”.
For detailed steps, refer to Section 23.6, “Managing AppArmor and Security Event Status”.
aa-genprof (generate profile) and aa-logprof (update profiles from learning mode log file). For more information about these tools, refer to Section 24.6.3, “Summary of Profiling Tools”.
is designed to set up AppArmor profiles using the AppArmor profiling tools,Stop the application before profiling it to ensure that application start-up is included in the profile. To do this, make sure that the application or daemon is not running.
For example, enter rcPROGRAM
stop (or
/etc/init.d/PROGRAM
stop)
in a terminal window while logged in as root
, replacing
PROGRAM
with the name of the program to
profile.
Start YaST and select
+ .Enter the name of the application or browse to the location of the program.
Click aa-autodep, which performs a static analysis of the program to profile and loads an approximate profile into the AppArmor module. For more information about aa-autodep, refer to Section 24.6.3.1, “aa-autodep—Creating Approximate Profiles”.
. This runs an AppArmor tool namedDepending on whether the profile you are about to create already exists either in the local profile repository (see Section 22.1, “Using the Local Repository”) or in the external profile repository (see Section 22.2, “Using the External Repository”) or whether it does not exist yet, proceed with one of the following options:
Determine whether you want to use or fine-tune an already existing profile from your local profile repository, as outlined in Step 5.
Determine whether you want to use or fine-tune an already existing profile from the external profile repository, as outlined in Step 6.
Create the profile from scratch and proceed with Step 7 and beyond.
If the profile already exists in the local profile repository under
/etc/apparmor/profiles/extra
, YaST informs you
that there is an inactive profile which you can either use as a base
for your own efforts or which you can just accept as is.
Alternatively, you can choose not to use the local version at all and start creating the profile from scratch. In any case, proceed with Step 7.
If the profile already exists in the external profile repository and this is the first time you tried to create a profile that already exists in the repository, configure your access to the server and determine how to use it:
Determine whether you want to enable access to the external repository or postpone this decision. In case you have selected Step 7.
, determine the access mode (download/upload) in a next step. In case you want to postpone the decision, select and proceed directly toProvide username and password for your account on the profile repository server and register at the server.
Select the profile to use and proceed to Step 7.
Run the application to profile.
Perform as many of the application functions as possible, so that learning mode can log the files and directories to which the program requires access to function properly. Be sure to include restarting and stopping the program in the exercised functions. AppArmor needs to handle these events, as well as any other program function.
Click
to parse the learning mode log files. This generates a series of questions that you must answer to guide the wizard in generating the security profile.If requests to add hats appear, proceed to Chapter 25, Profiling Your Web Applications Using ChangeHat.
The questions fall into two categories:
A resource is requested by a profiled program that is not in the profile (see Figure 23.2, “Learning Mode Exception: Controlling Access to Specific Resources”). Allow or deny access to a specific resource.
A program is executed by the profiled program and the security domain transition has not been defined (see Figure 23.3, “Learning Mode Exception: Defining Execute Permissions for an Entry”). Define execute permissions for an entry.
Each of these cases results in a series of questions that you must answer to add the resource to the profile or to add the program to the profile. For an example of each case, see Figure 23.2, “Learning Mode Exception: Controlling Access to Specific Resources” and Figure 23.3, “Learning Mode Exception: Defining Execute Permissions for an Entry”. Subsequent steps describe your options in answering these questions.
![]() | Varying Processing Options |
---|---|
Depending on the type of entry processed, the available options vary. |
The Figure 23.2, “Learning Mode Exception: Controlling Access to Specific Resources”) or requires you to define execute permissions for entries (as seen in Figure 23.3, “Learning Mode Exception: Defining Execute Permissions for an Entry”).
begins suggesting directory path entries that have been accessed by the application profiled (as seen inFor Figure 23.2: Learning Mode Exception: Controlling Access to Specific Resources: Select the option that satisfies the request for access, which could be a suggested include, a particular globbed version of the path, or the actual pathname. Depending on the situation, these options are available:
#include
The section of a AppArmor profile that refers to an include file. Include files give 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.
Accessed by clicking Section 21.6, “Paths and Globbing”.
. For information about globbing syntax, refer toLiteral path that the program needs to access to run properly.
After selecting a directory path, process it as an entry to the AppArmor profile by clicking
or . If you are not satisfied with the directory path entry as it is displayed, you can also or it.The following options are available to process the learning mode entries and build the profile:
Grant the program access to the specified directory path entries. The Section 21.7, “File Permission Access Modes”.
suggests file permission access. For more information about this, refer toClick
to prevent the program from accessing the specified paths.Clicking this modifies the directory path (using wild cards) to include all files in the suggested directory. Double-clicking it grants access to all files and subdirectories beneath the one shown. For more information about globbing syntax, refer to Section 21.6, “Paths and Globbing”.
Modify the original directory path while retaining the filename
extension. A single click causes
/etc/apache2/file.ext
to become
/etc/apache2/*.ext
, adding the wild card
(asterisk) in place of the filename. This allows the program to
access all files in the suggested directories that end with the
.ext
extension. When you double-click it,
access is granted to all files with the particular extension and
subdirectories beneath the one shown.
Edit the highlighted line. The new edited line appears at the bottom of the list.
Abort aa-logprof, losing all rule changes entered so far and leaving all profiles unmodified.
Close aa-logprof, saving all rule changes entered so far and modifying all profiles.
Click
or for each learning mode entry. These help build the AppArmor profile.![]() | |
The number of learning mode entries corresponds to the complexity of the application. |
For Figure 23.3: Learning Mode Exception: Defining Execute Permissions for an Entry: From the following options, select the one that satisfies the request for access. For detailed information about the options available, refer to Section 21.7, “File Permission Access Modes”.
Stay in the same security profile (parent's profile).
Require a separate profile to exist for the executed program. When selecting this option, also select whether AppArmor should sanitize the environment when switching profiles by removing certain environment variables that can modify the execution behavior of the child process. Unless these variables are absolutely required to properly execute the child process, always choose the more secure, sanitized option.
Execute the program without a security profile. When prompted, have AppArmor sanitize the environment to avoid adding security risks by inheriting certain environmental variables from the parent process.
![]() | Risks of Running Unconfined |
---|---|
Unless absolutely necessary, do not run unconfined. Choosing the option executes the new program without any protection from AppArmor. |
Click
to prevent the program from accessing the specified paths.Abort aa-logprof, losing all rule changes entered so far, and leaving all profiles unmodified.
Close aa-logprof, saving all rule changes entered so far, and modifying all profiles.
Repeat the previous steps if you need to execute more functionality of the application.
When you are done, click
. Choose to apply your changes to the local profile set. If you have previously chosen to upload your profile to the external profile repository, provide a brief change log entry describing your work and upload the profile. If you had postponed the decision on whether to upload the profile or not, YaST asks you again and you can create an account the upload the profile now or not upload it at all.As soon as you exit the
, the profile is saved both locally and on the repository server, if you have chosen to upload it. The profile is then loaded into the AppArmor module.AppArmor enables you to create a AppArmor profile by manually adding entries into the profile. Select the application for which to create a profile then add entries.
Start YaST and select
+ .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 Section 23.3.1, “Adding an Entry”, Section 23.3.2, “Editing an Entry”, or Section 23.3.3, “Deleting an Entry”.
, add, edit, or delete AppArmor profile entries by clicking the corresponding buttons and referring toWhen finished, click
.AppArmor enables you to edit AppArmor profiles manually by adding, editing, or deleting entries. To edit a profile, proceed as follows:
Start YaST and select
+ .From the list of profiled applications, select the profile to edit.
Click
. The window displays the profile.In the Section 23.3.1, “Adding an Entry”, Section 23.3.2, “Editing an Entry”, or Section 23.3.3, “Deleting an Entry”.
window, add, edit, or delete AppArmor profile entries by clicking the corresponding buttons and referring toWhen you are finished, click
.In the pop-up that appears, click
to confirm your changes to the profile and reload the AppArmor profile set.![]() | Syntax Checking in AppArmor |
---|---|
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 |
The Section 23.2, “Manually Adding a Profile” or Section 23.3, “Editing Profiles”. When you select , a list shows the types of entries you can add to the AppArmor profile.
option can be found inFrom 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 21.6, “Paths and Globbing”. For file access permission information, refer to Section 21.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 21.6, “Paths and Globbing”. For file access permission information, refer to Section 21.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 21.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 21.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 21.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 25, Profiling Your Web Applications Using ChangeHat.
When you select
, the file browser pop-up window opens. From here, edit the selected entry.In the pop-up window, specify the absolute path of a file, including the type of access permitted. You can use globbing if necessary. When finished, click
.For globbing information, refer to Section 21.6, “Paths and Globbing”. For file access permission information, refer to Section 21.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 and select
+ .Select the profile to delete.
Click
.In the pop-up that opens, click
to delete the profile and reload the AppArmor profile set.The AppArmor profile wizard uses aa-logprof, the tool that scans log files and enables you to update profiles. aa-logprof tracks messages from the AppArmor module that represent exceptions for all profiles running on your system. These exceptions represent the behavior of the profiled application that is outside of the profile definition for the program. You can add the new behavior to the relevant profile by selecting the suggested profile entry.
![]() | Support for the External Profile Repository |
---|---|
Similar to the Section 22.2, “Using the External Repository”. For details on how to configure access and access mode to the server, check the procedure described under Section 23.1, “Adding a Profile Using the Wizard”. , the also supports profile exchange with the external repository server. For background information on the use of the external AppArmor profile repository, refer to |
Start YaST and select
+ .Running aa-logprof) parses the learning mode log files. This generates a series of questions that you must answer to guide aa-logprof to generate the security profile. The exact procedure is the same as with creating a new profile. Refer to Step 9 in Section 23.1, “Adding a Profile Using the Wizard” for details.
(When you are done, click
. In the following pop-up, click to exit the . The profile is saved and loaded into the AppArmor module.You 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. You can determine how and when you are notified when system security events occur.
![]() | |
For event notification to work, you must set up a mail server on your system that can send outgoing mail using the single mail transfer protocol (SMTP), such as postfix or exim. |
To configure event notification or change the status of AppArmor, start YaST and select
+ .From the
screen, determine whether AppArmor and security event notification are running by looking for a status message that reads or configure the mode of individual profiles.To change the status of AppArmor, continue as described in Section 23.6.1, “Changing AppArmor Status”. To change the mode of individual profiles, continue as described in Section 23.6.2, “Changing the Mode of Individual Profiles”. To configure security event notification, continue as described in Section 27.2, “Configuring Security Event Notification”.
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 and select
+ .Enable AppArmor by checking
or disable AppArmor by deselecting it.Click
in the window.Click
+ in the YaST Control Center.AppArmor can apply profiles in two different modes. In complain or learning 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 syslogd.
The Section 24.6.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 loaded AppArmor profiles. This feature is useful for determining the status of your system during profile development. During the course of systemic profiling (seeTo edit an application's profile mode, proceed as follows:
Start YaST and select
+ .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 .![]() | Listing the Profiles Available |
---|---|
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. |
Contents
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.
![]() | Background Information |
---|---|
Before starting to manage your profiles using the AppArmor command line tools, check out the general introduction to AppArmor given in Chapter 20, Immunizing Programs and Chapter 21, Profile Components and Syntax. |
An AppArmor module can be in any one of three states:
The AppArmor module is not loaded into the kernel.
The AppArmor module is loaded into the kernel and is enforcing AppArmor program policies.
The AppArmor module is loaded into the kernel, but no policies are enforced.
Detect the state of the AppArmor module 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 through the script rcapparmor
, which can
perform the following operations:
Behavior depends on the AppArmor module state. If it is unloaded,
start
loads the module and starts it, putting it in
the running state. If it is stopped, start
causes the
module to rescan the AppArmor profiles usually found in
/etc/apparmor.d
and puts the module in the
running state. If the module is already running,
start
reports a warning and takes no action.
Stops the AppArmor module if it is running by removing all profiles from
kernel memory, effectively disabling all access controls, and putting
the module into the stopped state. If the AppArmor module is unloaded or
already stopped, stop
tries to unload the profiles
again, but nothing happens.
Causes the AppArmor module to rescan 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.
Unconditionally removes the AppArmor module from the kernel. However, unloading modules from the Linux kernel is unsafe. This command is provided only for debugging and emergencies (when the module might need to be removed).
![]() | |
AppArmor is a powerful access control system and it is possible to lock yourself out of your own machine to the point where you must boot the machine from a rescue medium (such as the first medium of SUSE Linux Enterprise Server) to regain control.
To prevent such a problem, always ensure that you have a running,
unconfined, |
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 21, 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.
You can use a text editor, such as vim, to access and make changes to these profiles. The following options contain detailed steps for building profiles:
Refer to Section 24.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 24.6, “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 rcapparmor restart in a terminal window.
The following steps describe the procedure for deleting 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 AppArmor directory with cd /etc/apparmor.d/.
Enter ls to view all the AppArmor profiles that are currently installed.
Delete the profile with rm
profilename
.
Restart AppArmor by entering rcapparmor restart in a terminal window.
Given the syntax for AppArmor profiles in Chapter 21, 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 24.6.1, “Stand-Alone Profiling”.
A method suitable for profiling large numbers of programs all 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 24.6.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 24.6.3.4, “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 a large number of programs all 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 24.6.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 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 23.6.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 24.6.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:
aa-logprof [ -d/path/to/profiles
] [ -f/path/to/logfile
]
Refer to Section 24.6.3.5, “aa-logprof—Scanning the System Log” for more information about using aa-logprof.
This generates optimum 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 might want to review the profiles that have been generated. You
can open and edit the profiles in
/etc/apparmor.d/
using vim.
Return to enforce mode.
This is when the system goes back to enforcing the rules of the
profiles, not just 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 23.6.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/*.
Rescan all profiles.
To have AppArmor rescan all of the profiles and change the enforcement mode in the kernel, enter rcapparmor restart.
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
form of aa-autodep is to enter the following in a
terminal window when logged in as root
:
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
ps 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:
aa-complain [program1
program2
...]
If the program is not in your path, specify the entire path as follows:
aa-complain /sbin/program1
If the profiles are not in /etc/apparmor.d
, use
the following to override the default location:
aa-complain/path/to/profiles/
program1
Specify the profile for program1
as
follows:
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 instance, 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.
![]() | Toggling Profile Mode with YaST |
---|---|
YaST offers a graphical front-end for toggling complain and enforce mode. See Section 23.6.2, “Changing the Mode of Individual Profiles” for information. |
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. Enforce toggles with complain mode.
Manually activating enforce mode (using the command line) adds a flag
to the top of the profile so that /bin/foo
becomes
/bin/foo flags=(enforce)
. To use enforce mode, open
a terminal window and enter one of the following lines as root
.
If the example program (program1
) is in
your path, use:
aa-enforce [program1
program2
...]
If the program is not in your path, specify the entire path, as follows:
aa-enforce /sbin/program1
If the profiles are not in
/etc/apparmor.d
, use the following to
override the default location:
aa-enforce /path/to/profiles/program1
Specify the profile for program1
as
follows:
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.
![]() | Toggling Profile Mode with YaST |
---|---|
YaST offers a graphical front-end for toggling complain and enforce mode. See Section 23.6.2, “Changing the Mode of Individual Profiles” for information. |
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:
aa-genprof [ -d/path/to/profiles
]program
To create a profile for the the Apache Web server program
httpd2-prefork, do the following as root
:
Enter rcapache2 stop.
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
SUSE Linux Enterprise Server,
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 24.6.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): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/index.html" pid=27471 profile="null-complain-profile"
If you are not running the audit daemon, the AppArmor events are logged
to /var/log/messages
:
Sep 13 13:20:30 K23 kernel: audit(1189682430.672:20810): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/phpsysinfo/templates/bulix/form.tpl" pid=30405 profile="/usr/sbin/httpd2-prefork///phpsysinfo/"
They also can be viewed using the dmesg command:
audit(1189682430.672:20810): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/phpsysinfo/templates/bulix/form.tpl" pid=30405 profile="/usr/sbin/httpd2-prefork///phpsysinfo/"
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 in order to function properly. For example, in a new terminal window, enter rcapache2 start.
Select from the following options that are available in the aa-logprof terminal window after you have executed the program function:
S runs aa-logprof 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 and returns to the main menu.
![]() | |
If requests to add hats appear, proceed to Chapter 25, 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 24.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 24.2, “Learning Mode Exception: Defining Execute 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 24.1, “Learning Mode Exception: Controlling Access to Specific Resources” and Example 24.2, “Learning Mode Exception: Defining Execute 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:
Example 24.1. Learning Mode Exception: Controlling Access to Specific Resources¶
Reading log entries from /var/log/audit/audit.log. Updating AppArmor profiles in /etc/apparmor.d. Profile: /usr/sbin/xinetd Program: xinetd Execute: /usr/lib/cups/daemon/cups-lpd Severity: unknown [(I)nherit] / (P)rofile / (U)nconfined / (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.The child runs completely unconfined without any AppArmor profile applied to the executed resource.
Choose the
(Ux) option to scrub the environment of environment variables that could modify execution behavior when passed to the child process. This option introduces a security vulnerability that could be used to exploit AppArmor. Only use it as a last resort.
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.
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 24.2, “Learning Mode Exception: Defining Execute Permissions for an Entry” shows AppArmor suggesting directory path entries that have been accessed by the application being profiled. It might also require you to define execute permissions for entries.
Example 24.2. Learning Mode Exception: Defining Execute Permissions for an Entry¶
Adding /bin/ps ix to profile. Profile: /usr/sbin/xinetd Path: /etc/hosts.allow New Mode: r [1 - /etc/hosts.allow] [(A)llow] / (D)eny / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish
AppArmor provides one or more paths or includes. By entering the option number, select the desired options then proceed to the next step.
![]() | |
All of these options are not 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 21.6, “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 21.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 21.6, “Paths and Globbing”.
This modifies the original directory path while retaining the
filename extension. For example,
/etc/apache2/file.ext
becomes
/etc/apache2/*.ext
, adding the wild card
(asterisk) in place of the filename. 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 vim, enter vim
/etc/apparmor.d/profilename
in a
terminal window.
Restart AppArmor and reload the profile set including the newly created
one using the rcapparmor restart
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
If you want to just use this profile, hit U ( ) and follow the profile generation procedure outlined above.
If you want to examine the profile before activating it, hit V ( ).
If you want to ignore the existing profile, hit C ( ) and follow the profile generation procedure outlined above to create the profile from scratch.
Leave aa-genprof by hitting F ( ) when you are done and save your changes.
To use the remote AppArmor profile repository with aa-genprof, proceed as follows:
Start aa-genprof as described above.
If aa-genprof detects a suitable profile on the repository server, the following lines appear on your terminal window:
Repository: http://apparmor.opensuse.org/backend/api Would you like to enable access to the profile repository? (E)nable Repository / (D)isable Repository / Ask Me (L)ater
Hit E ( ) to enable the repository.
Determine whether you want to aa-genprof to upload any profiles to the repository server:
Would you like to upload newly created and changed profiles to the profile repository? (Y)es / (N)o / Ask Me (L)ater
Hit Y ( ), if you want to enable profile upload or select N ( ), if you want aa-genprof to just pull profiles from the repository, but not to upload any.
Create a new user on the profile repository server to be able to upload profiles. Provide username and password.
Determine whether you want to use the profile downloaded from the server or whether you would just like to review it:
Profile: /usr/bin/opera [1 - novell] [(V)iew Profile] / (U)se Profile / (C)reate New Profile / Abo(r)t / (F)inish
If you want to just use this profile, hit U ( ) and follow the profile generation procedure outlined above.
If you want to examine the profile before activating it, hit V ( ).
If you want to ignore the existing profile, hit C ( ) and follow the profile generation procedure outlined above to create the profile from scratch.
Leave aa-genprof by hitting F ( ) when you are done and save the profile.
If you opted for uploading your profile, provide a short change log and push it to the repository.
aa-logprof is an interactive tool used to review the
learning or complain-mode output found in the log entries in
/var/log/audit/audit.log
or
/var/log/messages
(if auditd is not running) and
generate new entries in AppArmor security profiles.
When you run aa-logprof, it begins to scan the log files produced in learning or complain mode and, if there are new security events that are not covered by the existing profile set, it gives suggestions for modifying the profile. The learning or complain mode traces program behavior and enters it in the log. 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, and Ux 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 the AppArmor module is running, the updated profiles are reloaded and, if any processes that generated security events are still running in the null-complain-profile, those processes are set to run under their proper profiles.
![]() | Support for the External Profile Repository |
---|---|
Similar to the aa-genprof, aa-logprof also supports profile exchange with the external repository server. For background information on the use of the external AppArmor profile repository, refer to Section 22.2, “Using the External Repository”. For details on how to configure access and access mode to the server, check the procedure described under Section 24.6.3.4, “aa-genprof—Generating 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:
/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/
.
/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,
/var/log/audit/audit.log
or
/var/log/messages
(if auditd is not running).
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:
aa-logprof -m"17:04:21"
or
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/
and scans the log in
/var/log/messages
. In many cases, running
aa-logprof as root
is enough to create 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 /var/log/messages*` | 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 also makes the profile less brittle in that any changes to
DNS configuration and the associated name service profile package can
be made just 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 21.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 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 21.6, “Paths and Globbing”.
This modifies the original directory path while retaining the
filename extension. For example,
/etc/apache2/file.ext
becomes
/etc/apache2/*.ext
, adding the wild card
(asterisk) in place of the filename. 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
SUSE Linux Enterprise Server
serves FTP files from /srv/ftp
by default. This is
because httpd2-prefork 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 might want to 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 might want to grant more general access to FTP files. If
you select aa-logprof replaces the suggested path of
/y2k.jpg
with /*
.
Alternatively, you might want to 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 24.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 / (U)nconfined / (D)eny
![]() | |
The actual executable file for |
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 makes
use of 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.
In other circumstances, you might instead want to use the aa-logprof:
option. This has two effects onThe rule written into the profile uses 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.
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 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 21.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. Choosing
uses the execution mode ux
for your profile. The
default value selected is Ux
for unconfined
execution mode.
![]() | Running Unconfined |
---|---|
Choosing |
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. |
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/ntpd
is named
usr.sbin.ntpd
.
/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.
A 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 a 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 arbitrary times during the application execution. Two examples for ChangeHat-aware applications are the Apache Web server and Tomcat.
A profile can have an arbitrary number of subprofiles, but there are only
two levels: a subprofile cannot have further sub-subprofiles. A subprofile
is written as a separate profile and named as the containing profile
followed by the subprofile name, separated by a ^
.
Subprofiles must be stored in the same file as the parent profile.
Note that the security of hats is considerably weaker than that of full profiles. That is to say, if attackers can find just the right kind of bug in a program, they 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 in conjunction 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 in conjunction 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 25.2.2, “Location and Directory Directives”.
![]() | For More Information |
---|---|
For more information, see the change_hat man page. |
AppArmor provides a mod_apparmor
module (package
apache2-mod-apparmor
) for the
Apache program (only included in SUSE Linux Enterprise Server).
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,
^phpsysinfo/templates/classic/images/bar_left.gif
DEFAULT_URI
HANDLING_UNTRUSTED_INPUT
![]() | Apache Configuration |
---|---|
If you install
a2enmod apparmor |
As with most of the AppArmor tools, you can use two methods for managing ChangeHat, YaST or the command line interface. Managing ChangeHat-aware applications from the command line is much more flexible, but the process is also more complicated. Both methods allow you to manage the hats for your application and populate them with profile entries.
The following steps are a demonstration that adds hats to an Apache profile using YaST. In the
, the AppArmor profiling utilities prompt you to create new hats for distinct URI requests. Choosing to create a new hat allows you to create individual profiles for each URI. You can create very tight rules for each request.If the URI that is processed does not represent significant processing or otherwise does not represent a significant security risk, safely select
to process this URI in the default hat, which is the default security profile.
This example creates a new hat for the URI
phpsysinfo
and its subsequent accesses. Using the
profiling utilities, delegate what to add to this new hat. The resulting
hat becomes a tight-security container that encompasses all the
processing on the server that occurs when the
phpsysinfo
URI is passed to the Apache Web server.
The URI runs the application phpsysinfo (refer to
http://phpsysinfo.sourceforge.net for more
information). The
phpsysinfo
package is
assumed to be installed in
/srv/www/htdocs/phpsysinfo
in a clean (new)
installation of
SUSE Linux Enterprise Server
and AppArmor.
Once phpsysinfo
is
installed, you are ready to add hats to the Apache profile. From the
AppArmor GUI, select .
In httpd2-prefork.
, enterClick
.![]() |
Restart Apache by entering rcapache2 restart in a terminal window.
Restart any program you are profiling at this point.
Open http://localhost/phpsysinfo/
in a Web
browser window. The browser window should display network usage and
system information.
![]() | Data Caching |
---|---|
To ensure that this request is processed by the server and you do not
review cached data in your browser, refresh the page. To do this,
click the browser |
Click aa-logprof tool, which scans the information learned in the previous step. It begins to prompt you with profile questions.
. AppArmor launches the
aa-logprof first prompts with or because
it noticed that the phpsysinfo
URI was accessed.
Select .
Click
.Choosing
in the previous step creates a new hat in the profile and specifies that the results of subsequent questions about the script's actions are added to the newly created hat rather than the default hat for this application.In the next screen, AppArmor displays an external program that the script executed. You can specify that the program should run confined by the phpsysinfo hat (choose
), confined by a separate profile (choose ), or that it should run unconfined or without any security profile (choose ). For the case of the option, a new profile is created for the program if one does not already exist.![]() | Security Considerations |
---|---|
Selecting can create a significant security hole and should be done with caution. |
Select /bin/bash
path. This adds
/bin/bash
(accessed by Apache) to the
phpsysinfo hat profile with the necessary permissions.
Click
.The remaining questions prompt you to generate new hats and add entries to your profile and its hats. The process of adding entries to profiles is covered in detail in the Section 23.1, “Adding a Profile Using the Wizard”.
When all profiling questions are answered, click
to save your changes and exit the wizard.The following is an example phpsysinfo hat.
Example 25.1. Example phpsysinfo Hat¶
/usr/sbin/httpd2-prefork { ... ^phpsysinfo { #include <abstractions/bash> #include <abstractions/nameservice> /bin/basename ixr, /bin/bash ixr, /bin/df ixr, /bin/grep ixr, /bin/mount Ux, /bin/sed ixr, /dev/bus/usb/ r, /dev/bus/usb/** r, /dev/null w, /dev/tty rw, /dev/urandom r, /etc/SuSE-release r, /etc/ld.so.cache r, /etc/lsb-release r, /etc/lsb-release.d/ r, /lib/ld-2.6.1.so ixr, /proc/** r, /sbin/lspci ixr, /srv/www/htdocs/phpsysinfo/** r, /sys/bus/pci/** r, /sys/bus/scsi/devices/ r, /sys/devices/** r, /usr/bin/cut ixr, /usr/bin/getopt ixr, /usr/bin/head ixr, /usr/bin/lsb_release ixr, /usr/bin/lsscsi ixr, /usr/bin/tr ixr, /usr/bin/who ixr, /usr/lib/lib*so* mr, /usr/lib/locale/** r, /usr/sbin/lsusb ixr, /usr/share/locale/** r, /usr/share/pci.ids r, /usr/share/usb.ids r, /var/log/apache2/access_log w, /var/run/utmp kr, } }
![]() | Hat and Parent Profile Relationship |
---|---|
The profile |
When you use the Section 23.3, “Editing Profiles”) or when you add a new profile using (for instructions, refer to Section 23.2, “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 to![]() |
From the
window, click then select . The dialog box opens:![]() |
Enter the name of the hat to add to the AppArmor profile. The name is the URI that, when accessed, receives the permissions set in the hat.
Click
. You are returned to the screen.After adding the new hat, click
.![]() | For More Information |
---|---|
For an example of an AppArmor profile, refer to Example 25.1, “Example phpsysinfo Hat”. |
Apache is configured by placing directives in plain text configuration
files. The main configuration file is usually
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 start or restart
Apache, so the changes are recognized.
Virtual host directives control whether requests that contain trailing pathname information following an actual filename (or that refer to a nonexistent file in an existing directory) are accepted or rejected. For Apache documentation on virtual host directives, refer to http://httpd.apache.org/docs-2.2/mod/core.html#virtualhost.
The ChangeHat-specific configuration keyword is
AADefaultHatName
. It is used similarly to
AAHatName
, for example, AADefaultHatName
My_Funky_Default_Hat
.
The configuration option is actually based on a server directive, which enables you to use the keyword outside of other options, setting it for the default server. Virtual hosts are considered internally within Apache to be separate “servers,” so you can set a default hat name for the default server as well as one for each virtual host, if desired.
When a request comes in, the following steps reflect the sequence in
which mod_apparmor
attempts to apply hats.
A location or directory hat as specified by the
AAHatName
keyword
A hat named by the entire URI path
A default server hat as specified by the
AADefaultHatName
keyword
DEFAULT_URI
(if none of those exist, it goes back
to the “parent” Apache hat)
Location and directory directives specify hat names in the program configuration file so the program 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.2/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.immunix.com/docs"> # Note lack of trailing slash AAHatName immunix.com </Directory>
Example: The program phpsysinfo is used to illustrate a location directive in the following example. The tarball can be downloaded from http://phpsysinfo.sourceforge.net.
After downloading the tarball, install it into
/srv/www/htdocs/phpsysinfo
.
Create /etc/apache2/conf.d/phpsysinfo.conf
and
add the following text to it:
<Location "/phpsysinfo"> AAHatName phpsysinfo </Location>
The following hat should then work for phpsysinfo:
/usr/sbin/httpd2-prefork { ... ^phpsysinfo { #include <abstractions/bash> #include <abstractions/nameservice> /bin/basename ixr, /bin/bash ixr, /bin/df ixr, /bin/grep ixr, /bin/mount Ux, /bin/sed ixr, /dev/bus/usb/ r, /dev/bus/usb/** r, /dev/null w, /dev/tty rw, /dev/urandom r, /etc/SuSE-release r, /etc/ld.so.cache r, /etc/lsb-release r, /etc/lsb-release.d/ r, /lib/ld-2.6.1.so ixr, /proc/** r, /sbin/lspci ixr, /srv/www/htdocs/phpsysinfo/** r, /sys/bus/pci/** r, /sys/bus/scsi/devices/ r, /sys/devices/** r, /usr/bin/cut ixr, /usr/bin/getopt ixr, /usr/bin/head ixr, /usr/bin/lsb_release ixr, /usr/bin/lsscsi ixr, /usr/bin/tr ixr, /usr/bin/who ixr, /usr/lib/lib*so* mr, /usr/lib/locale/** r, /usr/sbin/lsusb ixr, /usr/share/locale/** r, /usr/share/pci.ids r, /usr/share/usb.ids r, /var/log/apache2/access_log w, /var/run/utmp kr, } }
Reload AppArmor profiles by entering rcapparmor
restart at a terminal window as root
.
Restart Apache by entering rcapache2 restart at a
terminal window as root
.
Enter http://hostname/phpsysinfo/
into a browser
to receive the system information that phpsysinfo delivers.
Locate configuration errors by going to
/var/log/audit/audit.log
or running
dmesg and looking for any rejections in the output.
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 authenticated users into subprofiles based on groupnames, usernames, or a default profile. To accomplish this, pam_apparmor needs to be registered as a PAM session module.
The package pam_apparmor may not installed by default, you may need to
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.
pam_apparmor allows you to set up role-based access control (RBAC). In conjunction with the set capabilities rules (see Section 21.11, “Setting Capabilities per Profile” for more information), it allows you to map restricted admin profiles to users. A detailed HOWTO on setting up RBAC with AppArmor is available at http://developer.novell.com/wiki/index.php/Apparmor_RBAC_in_version_2.3.
Contents
After creating profiles and immunizing your applications, SUSE® Linux Enterprise Server 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, running periodic reports, updating profiles from system log entries by running the aa-logprof tool through YaST, and dealing with maintenance issues.
Applications that are confined by AppArmor security profiles generate messages when applications execute in unexpected ways or outside of their specified profile. These messages can be monitored by event notification, periodic report generation, or integration into a third-party reporting mechanism.
For reporting and alerting, AppArmor uses a userspace daemon
(/usr/sbin/aa-eventd
). This
daemon monitors log traffic, sends out notifications, and runs scheduled
reports. It does not require any end user configuration and it is started
automatically as part of the security event notification through the
YaST AppArmor Control Panel or by the configuration of scheduled reports in
the YaST AppArmor Reports module.
Apart from transparently enabling and disabling
aa-eventd
with the YaST
modules, you can manually toggle its status with the
rcaaeventd init script. The AppArmor event daemon is not
required for proper functioning of the profiling process (such as
enforcement or learning). It is just required for reporting.
Find more details on security event notification in Section 27.2, “Configuring Security Event Notification” and on scheduled reports in Section 27.3, “Configuring Reports”.
If you prefer a simple way of being notified of any AppArmor reject events that does not require you to check your e-mails or any log files, use the AppArmor Desktop Monitor applet that integrates into the GNOME desktop. Refer to Section 27.4, “Configuring and Using the AppArmor Desktop Monitor Applet” for details.
Security event notification is a AppArmor feature that informs you when systemic AppArmor activity occurs. Activate it by selecting a notification frequency (receiving daily notification, for example). Enter an e-mail address so you can be notified by e-mail when AppArmor security events occur. Select one of the following notification types:
Terse notification summarizes the total number of system events without providing details. For example:
jupiter.example.com has had 41 security events since Mon Sep 10 14:53:16 2007.
Summary notification displays the logged AppArmor security events and lists the number of individual occurrences, including the date of the last occurrence. For example:
AppArmor: PERMITTING access to capability ’setgid’ (httpd2-prefork(6347) profile /usr/sbin/httpd2-prefork active /usr/sbin/httpd2-prefork) 2 times, the latest at Sat Oct 9 16:05:54 2004.
Verbose notification displays unmodified, logged AppArmor security events. It tells you every time an event occurs and writes a new line in the verbose log. These security events include the date and time the event occurred, when the application profile permits and rejects access, and the type of file permission access that is permitted or rejected. Verbose notification also reports several messages that the aa-logprof tool (see Section 24.6.3.5, “aa-logprof—Scanning the System Log”) uses to interpret profiles. For example:
type=APPARMOR_DENIED msg=audit(1189428793.218:2880): operation="file_permission" requested_mask="::w" denied_mask="::w" fsuid=1000 name="/var/log/apache2/error_log" pid=22969 profile="/usr/sbin/httpd2-prefork"
![]() | |
You must set up a mail server that can send outgoing mail using the SMTP protocol (for example, postfix or exim) for event notification to work. |
In the
section of the window, click .![]() |
In the
window, enable , , or event notification.In each applicable notification type section, enter the e-mail addresses of those who should receive notification in the field provided. If notification is enabled, you must enter an e-mail address. Separate multiple e-mail addresses with commas.
For each notification type enabled, select the frequency of notification.
Select a notification frequency from the following options:
Disabled
1 minute
5 minutes
10 minutes
15 minutes
30 minutes
1 hour
1 day
1 week
For each selected notification type, select the lowest severity level for which a notification should be sent. Security events are logged and the notifications are sent at the time indicated by the interval when events are equal to or greater than the selected severity level. If the interval is
, the notification is sent daily, if security events occur.![]() | Severity Levels |
---|---|
AppArmor sends out event messages for things that are in the severity
database and above the level selected. Severity levels are numbered
1 through 10, with 10 being the most severe security incident. The
|
Click
.Click
in the window.Click
+ in the YaST Control Center.After configuring security event notification, read the reports and determine whether events require follow up. Follow up may include the procedures outlined in Section 27.5, “Reacting to Security Event Rejections”.
AppArmor's reporting feature adds flexibility by enhancing the way users can view security event data. The reporting tool performs the following:
Creates on-demand reports
Exports reports
Schedules periodic reports for archiving
E-mails periodic reports
Filters report data by date
Filters report data by other options, such as program name
Using reports, you can read important AppArmor security events reported in
the log files without manually sifting through the messages only useful
to the aa-logprof tool. Narrow down the size of the
report by filtering by date range or program name. You can also export an
html
or csv
file.
The following are the three types of reports available in AppArmor:
A combined report, consisting of one or more security incident reports from one or more machines. This report can provide a single view of security events on multiple machines. For more details, refer to Section 27.3.1.3, “Executive Security Summary”.
An auditing tool that reports which application servers are running and whether the applications are confined by AppArmor. Application servers are applications that accept incoming network connections. For more details, refer to Section 27.3.1.1, “Application Audit Report”.
A report that displays application security for a single host. It reports policy violations for locally confined applications during a specific time period. You can edit and customize this report or add new versions. For more details, refer to Section 27.3.1.2, “Security Incident Report”.
To use the AppArmor reporting features, proceed with the following steps:
Open
+ .In
, click . The window appears. From the window, select an option and proceed to the respective section for instructions:![]() |
Displays all reports that have been run and stored in
/var/log/apparmor/reports-archived/
. Select the
report you want to see in detail and click .
For instructions, proceed to
Section 27.3.1, “Viewing Archived Reports”.
Produces an instant version of the selected report type. If you select a security incident report, it can be further filtered in various ways. For Section 27.3.2, “Run Now: Running On-Demand Reports”.
instructions, proceed toCreates a scheduled security incident report. For Section 27.3.3, “Adding New Reports”.
instructions, proceed toEdits a scheduled security incident report.
Deletes a scheduled security incident report. All stock or canned reports cannot be deleted.
Returns you to the AppArmor main screen.
Returns you to the AppArmor main screen.
Performs the same function as the
button.enables you to specify the location of a collection of reports from one or more systems, including the ability to filter by date or names of programs accessed and display them all together in one report.
From the
window, select .![]() |
Select the report type to view. Toggle between the different types:
(Security Incident Report), (Application Audit), and (Executive Security Summary).
You can alter the directory location of the archived reports in
/var/log/apparmor/reports-archived
.
To view all the reports in the archive, select
. To view a specific report, select a report file listed in the field then select .For Step 9.
and reports, proceed toThe
opens for reports.![]() |
The
dialog enables you to filter the reports selected in the previous screen. Enter the desired filter details. The fields are:To display reports for a certain time period, select
. Enter the start and end dates that define the scope of the report.When you enter a program name or pattern that matches the name of the binary executable of the program of interest, the report displays security events that have occurred for a specific program.
When you enter the name of the profile, the report displays the security events that are generated for the specified profile. You can use this to see what is being confined by a specific profile.
is a number that uniquely identifies one specific process or running program (this number is valid only during the lifetime of that process).
Select the lowest severity level for security events to include in the report. The selected severity level (and above) are then included in the reports.
A source to which the profile has denied access. This includes capabilities and files. You can use this field to report the resources to which profiles prevent access.
The access type describes what is actually happening with the
security event. The options are PERMITTING
,
REJECTING
, or AUDITING
.
The all
(all modes without filtering),
r
(read), w
(write),
l
(link),x
(execute), and
m
(mmap).
Enables you to export a CSV (comma separated values) or HTML file. The CSV file separates pieces of data in the log entries with commas using a standard data format for importing into table-oriented applications. You can enter a path for your exported report by typing the full path in the field provided.
Enables you to change the location at which to store the exported
report. The default location is
/var/log/apparmor/reports-exported
. When you
change this location, select . Select
to browse the file system.
To see the report, filtered as desired, select
. One of the three reports displays.Refer to the following sections for detailed information about each type of report.
For the application audit report, refer to Section 27.3.1.1, “Application Audit Report”.
For the security incident report, refer to Section 27.3.1.2, “Security Incident Report”.
For the executive summary report, refer to Section 27.3.1.3, “Executive Security Summary”.
An application audit report is an auditing tool that reports which application servers are running and whether they are confined by AppArmor.
![]() |
The following fields are provided in an application audit report:
The machine protected by AppArmor for which the security events are reported.
The date during which security events occurred.
The name and path of the executing process.
The absolute name of the security profile that is applied to the process.
A number that uniquely identifies one specific process or running program (this number is valid only during the lifetime of that process).
This field reveals whether the program listed in the program field is confined. If it is not confined, consider creating a profile for it.
This field reveals the type of confinement the security event represents (either complain or enforce). If the application is not confined (state), no type of confinement is reported.
A security incident report displays security events of interest to an administrator. The SIR reports policy violations for locally confined applications during a specified time period. It also reports policy exceptions and policy engine state changes. These two types of security events are defined as follows:
When an application requests a resource that is not defined within its profile, a security event is triggered. A report is generated that displays security events of interest to an administrator. The SIR reports policy violations for locally confined applications during a specified time period. The SIR reports policy exceptions and policy engine state changes.
Enforces policy for applications and maintains its own state, including when engines start or stop, when a policy is reloaded, and when global security feature are enabled or disabled.
![]() |
The fields in the SIR report have the following meanings:
The machine protected by AppArmor for which the security events are reported.
The date during which security events occurred.
The name of the executing process.
The absolute name of the security profile that is applied to the process.
A number that uniquely identifies one specific process or running program (this number is valid only during the lifetime of that process).
Severity levels of events are reported from the severity database. The severity database defines the importance of potential security events and numbers them 1 through 10, 10 being the most severe security incident. The severity levels are determined by the threat or importance of different security events, such as certain resources accessed or services denied.
The mode is the permission that the profile grants to the program or
process to which it is applied. The options are r
(read), w
(write), l
(link), and
x
(execute).
A source to which the profile has denied access.This includes capabilities and files. You can use this field to report the resources to which the profile prevents access.
The access type describes what is actually happening with the
security event. The options are PERMITTING
,
REJECTING
, or AUDITING
.
A combined report consisting of one or more high-level reports from one
or more machines. This report can provide a single view of security
events on multiple machines as long as each machine's data is copied to
the report archive directory, which is
/var/log/apparmor/reports-archived
. One line of
the ESS report represents a range of SIR reports.
The following fields are provided in an executive security summary:
The machine protected by AppArmor for which the security events are reported.
The first date in a range of dates during which security events are reported.
The last date in a range of dates during which security events are reported.
In the date range given, the total number of security events that are rejected access attempts.
In the date range given, the total number of security events.
This is the average of the severity levels reported in the date range given. Unknown severities are disregarded in this figure.
This is the severity of the highest severity event reported in the date range given.
The Section 27.3, “Configuring Reports”. Perform the following steps to run a report from the list of reports:
report feature enables you to instantly extract report information from the AppArmor event logs without waiting for scheduled events. If you need help navigating to the main report screen, seeSelect the report to run instantly from the list of reports in the
window.Select
or . The next screen is dependent on which report you selected in the previous step. As an example, select a security incident report.The
opens for security incident reports.![]() |
The
enables you to filter the reports selected in the previous screen. Enter the desired filter details. The following filter options are available:To limit reports to a certain time period, select
. Enter the start and end dates that determine the scope of the report.When you enter a program name or pattern that matches the name of the binary executable for the relevant program, the report displays security events that have occurred for that program only.
When you enter the name of the profile, the report displays the security events that are generated for the specified profile. You can use this to see what is confined by a specific profile.
A number that uniquely identifies one specific process or running program (this number is valid only during the lifetime of that process).
Select the lowest severity level for security events to include in the report. The selected severity level and above are included in the reports.
A source to which the profile has denied access. This includes capabilities and files. You can use this field to report the resources to which profiles prevent access.
The access type describes the action being taken with the security
event. The options are PERMITTING
,
REJECTING
, or AUDITING
.
The mode is the permission that the profile grants to the program
or process to which it is applied. The options are
r
(read), w
(write),
l
(link), and x
(execute).
Enables you to export a CSV (comma separated values) or HTML file. The CSV file separates pieces of data in the log entries with commas, using a standard data format for importing into table-oriented applications. Enter a path for your exported report by typing in the full path in the field provided.
Enables you to change the location that the exported report is
stored. The default location is
/var/log/apparmor/reports-exported
. When you
change this location, select . Select
to browse the file system.
To see the report, filtered as desired, select
. One of the three reports displays.Refer the following sections for detailed information about each type of report.
For the application audit report, refer to Section 27.3.1.1, “Application Audit Report”.
For the security incident report, refer to Section 27.3.1.2, “Security Incident Report”.
For the executive summary report, refer to Section 27.3.1.3, “Executive Security Summary”.
Adding new reports enables you to create a scheduled security incident report that displays AppArmor security events according to your preset filters. When a report is set up in
, it periodically launches a report of AppArmor security events that have occurred on the system.You can configure a daily, weekly, monthly, or hourly report to run for a specified period. You can set the report to display rejections for certain severity levels or to filter by program name, profile name, severity level, or denied resources. This report can be exported to an HTML (Hypertext Markup Language) or CSV (Comma Separated Values) file format.
![]() | |
Return to the beginning of this section if you need help navigating to the main report screen (see Section 27.3, “Configuring Reports”). |
To add a new scheduled security incident report, proceed as follows:
Click
to create a new security incident report. The first page of opens.![]() |
Fill in the fields with the following filtering information, as necessary:
Specify the name of the report. Use names that easily distinguish different reports.
Select any day of the month to activate monthly filtering in
reports. If you select All
, monthly filtering is
not performed.
Select the day of the week on which to schedule weekly reports, if
desired. If you select ALL
, weekly filtering is
not performed. If monthly reporting is selected, this field
defaults to ALL
.
Select the time. This specifies the hour and minute that you would like the reports to run. If you do not change the time, selected reports run at midnight. If neither month nor day of week are selected, the report runs daily at the specified time.
You have the ability to send the scheduled security incident report via e-mail to up to three recipients. Just enter the e-mail addresses for those who require the security incident information.
This option enables you to export a CSV (comma separated values) or HTML file. The CSV file separates pieces of data in the log entries with commas using a standard data format for importing into table-oriented applications. Enter a path for your exported report by typing in the full path in the field provided.
Enables you to change the location where the exported report is
stored. The default location is
/var/log/apparmor/reports-exported
. When you
change this location, select . Select
to browse the file system.
Click
to proceed to the second page of .![]() |
Fill in the fields with the following filtering information, as necessary:
You can specify a program name or pattern that matches the name of the binary executable for the program of interest. The report displays security events that have occurred for the specified program only.
You can specify the name of the profile for which the report should display security events. You can use this to see what is being confined by a specific profile.
A number that uniquely identifies one specific process or running program (this number is valid only during the lifetime of that process).
A source to which the profile has denied access. This includes capabilities and files. You can use this field to create a report of resources to which profiles prevent access.
Select the lowest severity level of security events to include in the report. The selected severity level and above are included in the reports.
The access type describes the action being taken with the security
event. The options are PERMITTING
,
REJECTING
, or AUDITING
.
The mode is the permission that the profile grants to the program
or process to which it is applied. The options are
r
(read), w
(write),
l
(link), and x
(execute).
Click
to save this report. AppArmor returns to the main window where the newly scheduled report appears in the list of reports.From the AppArmor stock reports) cannot be edited or deleted.
screen, you can select and edit a report. The three pre-configured reports (![]() | |
Return to the beginning of this section if you need help navigating to the main report screen (see Section 27.3, “Configuring Reports”). |
Perform the following steps to modify a report from the list of reports:
From the list of reports in the
window, select the report to edit. This example assumes that you have selected a security incident report.Click
to edit the security incident report. The first page of the displays.![]() |
Modify the following filtering information, as necessary:
Select any day of the month to activate monthly filtering in
reports. If you select All
, monthly filtering is
not performed.
Select the day of the week on which to schedule the weekly reports.
If you select All
, weekly filtering is not
performed. If monthly reporting is selected, this defaults to
All
.
Select the time. This specifies the hour and minute that you would like the reports to run. If you do not change the time, the selected report runs at midnight. If neither the day of the month nor day of the week is selected, the report runs daily at the specified time.
You have the ability to send the scheduled security incident report via e-mail to up to three recipients. Just enter the e-mail addresses for those who require the security incident information.
This option enables you to export a CSV (comma separated values) or HTML file. The CSV file separates pieces of data in the log entries with commas, using a standard data format for importing into table-oriented applications. Enter a path for your exported report by typing the full path in the field provided.
Enables you to change the location where the exported report is
stored. The default location is
/var/log/apparmor/reports-exported
. When you
change this location, select . Select
to browse the file system.
Click
to proceed to the next page. The second page of opens.![]() |
Modify the fields with the following filtering information, as necessary:
You can specify a program name or pattern that matches the name of the binary executable for the program of interest. The report displays security events that have occurred for the specified program only.
You can specify the name of the profile for which to display security events. You can use this to see what is being confined by a specific profile.
Process ID number is a number that uniquely identifies one specific process or running program (this number is valid only during the lifetime of that process).
A source to which the profile has denied access. This includes capabilities and files. You can use this field to create a report of resources to which profiles prevent access.
Select the lowest severity level for security events to include in the report. The selected severity level and above are included in the reports.
The access type describes the action being taken with the security
event. The options are PERMITTING
,
REJECTING
, or AUDITING
.
The mode is the permission that the profile grants to the program
or process to which it is applied. The options are
r
(read), w
(write),
l
(link), and x
(execute).
Select
to save the changes to this report. AppArmor returns to the main window where the scheduled report appears in the list of reports.enables you to permanently remove a report from the list of AppArmor scheduled reports. To delete a report, follow these instructions:
To remove a report from the list of reports, highlight the report and click
.From the confirmation pop-up, select
if you do not want to delete the selected report. If you are sure you want to remove the report permanently from the list of reports, select .
The Linux audit framework contains a dispatcher that can send AppArmor events
to any consumer application via dbus. The GNOME AppArmor Desktop Monitor
applet is one example of an application that gathers AppArmor events via
dbus. To configure audit to use the dbus dispatcher, just set the
dispatcher in your audit configuration in
/etc/audit/auditd.conf
to
apparmor-dbus
and restart auditd:
dispatcher=/usr/bin/apparmor-dbus
Once the dbus dispatcher is configured correctly, add the AppArmor Desktop
Monitor to the GNOME panel by right-clicking the panel and selecting
REJECT
event is logged, the applet's panel icon changes appearance and you can
click the applet to see the number of reject events per confined
application. To view the exact log messages, refer to the audit log under
/var/log/audit/audit.log
. React to any
REJECT
events as described in
Section 27.5, “Reacting to Security Event Rejections”.
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 or the in AppArmor to update your profile.
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 reprofile 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
:
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 Konqueror or 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 23.3, “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 one of the following:
Run the profiling wizard by selecting Section 23.1, “Adding a Profile Using the Wizard”.
in YaST. This creates a new profile for the added or patched application. For step-by-step instructions, refer to
Run aa-genprof in a terminal while logged in as
root
. For detailed instructions, refer to
Section 24.6.3.4, “aa-genprof—Generating Profiles”.
If you intend to deploy a patch or upgrade directly into a production environment, the best method for updating your profiles is one of the following:
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 24.6.3.5, “aa-logprof—Scanning the System Log”.
Run the YaST Section 23.5, “Updating Profiles from Log Entries”.
to learn the new behavior (high security risk as all accesses are allowed and logged, not rejected). For step-by-step instructions, refer toContents
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 solutions. Report defects or enhancement requests for AppArmor following the instructions in this chapter.
Updates for AppArmor packages are provided in the same way as any other update for SUSE Linux Enterprise Server. Retrieve and apply them exactly like for any other package that ships as part of SUSE Linux Enterprise Server.
There are man pages available for your use. In a terminal, enter man apparmor to open the apparmor man page. Man pages are distributed in sections numbered 1 through 8. Each section is specific to a category of documentation:
Table 28.1. Man Pages: Sections and Categories
Section |
Category |
---|---|
1 |
User commands |
2 |
System calls |
3 |
Library functions |
4 |
Device driver information |
5 |
Configuration file formats |
6 |
Games |
7 |
High level concepts |
8 |
Administrator commands |
The section numbers are used to distinguish man pages from each other.
For example, exit(2)
describes the exit system
call, while exit(3)
describes the exit C library
function.
The AppArmor man pages are:
unconfined(8)
autodep(1)
complain(1)
enforce(1)
genprof(1)
logprof(1)
change_hat(2)
logprof.conf(5)
apparmor.conf(5)
apparmor.d(5)
apparmor.vim(5)
apparmor(7)
apparmor_parser(8)
Find more information about the AppArmor project at the AppArmor Wiki: http://wiki.apparmor.net/. Find
the product documentation for AppArmor, including this document, at
http://www.suse.com/documentation/apparmor/ or in the
installed system in /usr/share/doc/manual
.
This section lists the most common problems and error messages that may occur using AppArmor.
If you notice odd application behavior or any other type of application problem, you should first check the reject messages in the log files to see if AppArmor is too closely constricting your application. To check reject messages, start
+ and go to . Select and for the application audit report. You can filter dates and times to narrow down the specific periods when the unexpected application behavior occurred.If you detect reject messages that indicate that your application or service is too closely restricted by AppArmor, update your profile to properly handle your use case of the application. Do this with the Section 23.5, “Updating Profiles from Log Entries”.
in YaST, as described in
If you decide to run your application or service without AppArmor
protection, remove the application's profile from
/etc/apparmor.d
or move it to another location.
If you have been using previous versions of AppArmor and have updated your system (but kept your old set of profiles) you might notice some applications which seemed to work perfectly before you updated behaving strangely, or not working at all .
This version of AppArmor introduces a set of new features to the profile syntax and the AppArmor tools that might cause trouble with older versions of the AppArmor profiles. Those features are:
File Locking
Network Access Control
The SYS_PTRACE
Capability
Directory Path Access
The current version of AppArmor mediates file locking and introduces a new
permission mode (k
) for this. Applications requesting
file locking permission might misbehave or fail altogether if confined
by older profiles which do not explicitly contain permissions to lock
files. If you suspect this being the case, check the log file under
/var/log/audit/audit.log
for entries like the
following:
type=APPARMOR_DENIED msg=audit(1188913493.299:9304): operation="file_lock" requested_mask="::k" denied_mask="::k" fsuid=1000 name="/home/tux/.qt/.qtrc.lock" pid=25736 profile="/usr/bin/opera"
Update the profile using the YaST Update Profile Wizard or the aa-logprof command as outlined below.
The new network access control syntax based on the network family and
type specification, described in
Section 21.5, “Network Access Control”, might cause application
misbehavior or even stop applications from working. If you notice a
network-related application behaving strangely, check the log file under
/var/log/audit/audit.log
for entries like the
following:
type=APPARMOR_DENIED msg=audit(1188894313.206:9123): operation="socket_create" family="inet" sock_type="raw" protocol=1 pid=23810 profile="/bin/ping"
This log entry means that our example application, /bin/ping in this case, failed to get AppArmor's permission to open a network connection. This permission has to be explicitly stated to make sure that an application has network access. To update the profile to the new syntax, use the YaST Update Profile Wizard or the aa-logprof command as outlined below.
The current kernel requires the SYS_PTRACE
capability, if a process tries to access files in
/proc/
. New
profiles need an entry for the file and the capability, where old
profiles only needed the file entry. For example:
pid
/fd/*
/proc/*/fd/** rw,
in the old syntax would translate to the following rules in the new syntax:
capability SYS_PTRACE, /proc/*/fd/** rw,
To update the profile to the new syntax, use the YaST Update Profile Wizard or the aa-logprof command as outlined below.
With this version of AppArmor, a few changes have been made to the profile rule syntax to better distinguish directory from file access. Therefore, some rules matching both file and directory paths in the previous version might now just match a file path. This could lead to AppArmor not being able to access a crucial directory at all, and thus trigger misbehavior of your application and various log messages. The following examples highlight the most important changes to the path syntax.
Using the old syntax, the following rule would allow access to files and
directories in /proc/net
. It would allow directory
access only to read the entries in the directory, but not give access to
files or directories under the directory, e.g.
/proc/net/dir/foo
would be matched by the asterisk
(*), but as foo
is a file or directory under
dir
, it cannot be accessed.
/proc/net/* r,
To get the same behavior using the new syntax, you need two rules
instead of one. The first allows access to the file under
/proc/net
and the second allows access to
directories under /proc/net
. Directory access can
only be used for listing the contents, not actually accessing files or
directories underneath the directory.
/proc/net/* r, /proc/net/*/ r,
The following rule works similarly both under the old and the new
syntax, and allows access to both files and directories under
/proc/net
:
/proc/net/** r,
To distinguish file access from directory access using the above
expression in the new syntax, use the following two rules. The first one
only allows to recursively access directories under
/proc/net
while the second one explicitly allows
for recursive file access only.
/proc/net/**/ r, /proc/net/**[^/] r,
The following rule works similarly both under the old and the new syntax
and allows access to both files and directories beginning with
foo
under /proc/net
:
/proc/net/foo** r,
To distinguish file access from directory access in the new syntax and
use the **
globbing pattern, use the following two
rules. The first one would have matched both files and directories in
the old syntax, but only matches files in the new syntax due to the
missing trailing slash. The second rule matched neither file nor
directory in the old syntax, but matches directories only in the new
syntax:
/proc/net/**foo r, /proc/net/**foo/ r,
The following rules illustrate how the use of the ?
globbing pattern has changed. In the old syntax, the first rule would
have matched both files and directories (four characters, last character
could be any but a slash). In the new syntax, it matches only files
(trailing slash is missing). The second rule would match nothing in the
old profile syntax, but matches directories only in the new syntax. The
last rule matches explicitly matches a file called
bar
under /proc/net/foo?
.
Using the old syntax, this rule would have applied to both files and
directories:
/proc/net/foo? r, /proc/net/foo?/ r, /proc/net/foo?/bar r,
To find and resolve issues related to syntax changes, take some time after the update to check the profiles you want to keep and proceed as follows for each application you kept the profile for:
Make sure that AppArmor is running and that the application's profile is loaded.
Start the YaST AppArmor Control Panel and put the application's profile into complain mode. Log entries are made for any actions violating the current profile, but the profile is not enforced and the application's behavior not restricted.
Run the application covering all the tasks you need this application to be able to perform.
Start the YaST Update Profile Wizard to update the application's profile according to the log entries generated while running the application.
Once the profile is updated, put it back into enforce mode via the YaST AppArmor Control Panel.
Using the AppArmor command line tools, you would proceed as follows:
Put the application's profile into complain mode:
aa-complain /path/to/application
Run the application.
Update the profile according to the log entries made while running the application:
aa-logprof /path/to/application
Put the resulting profile back into enforce mode:
aa-enforce /path/to/application
Currently, it is not possible to confine KDE applications to the same extent as any other application, due to the way KDE manages its processes.
If you want to confine KDE applications, choose one of the following approaches, but note that none of them are really suited for a standard setup:
As all KDE processes are children of one parent process and AppArmor cannot distinguish an individual application's process from the rest, create one huge profile to confine the entire desktop all at once. This approach is only feasible if your setup is a very limited (kiosk-type) one. Maintaining such a profile for a standard KDE desktop (including all of its applications) would be close to impossible.
Using KDE_EXEC_SLAVES=1
and
KDE_IS_PRELINKED=1
variables force KDE to manage
its processes in a way that allows AppArmor to distinguish individual
applications from each other and apply profiles to them. This
approach might slow down your desktop considerably, as it turns off a
crucial optimization for speed. Note that the above mentioned
environment variables have to be set before KDM/XDM/GDM or startx are
started. One way to achieve this would be to add them to
/etc/security/pam_env.conf
.
Apache is not starting properly or it is not serving Web pages and you
just installed a new module or made a configuration change. When you
install additional Apache modules (like
apache2-mod_apparmor
) or make configuration changes
to Apache, you should profile Apache again to catch any additional rules
that need to be added to the profile.
When the reporting feature generates an HTML or CSV file that exceeds the default size, the file is not sent. Mail servers have a default hard limit for e-mail size. This limitation can impede AppArmor's ability to send e-mails that are generated for reporting purposes. If your mail is not arriving, this could be why. Consider the mail size limits and check the archives if e-mails have not been received.
AppArmor always loads and applies all profiles that are available in its
profile directory (/etc/apparmor.d/
). If you decide
not to apply a profile to a certain application, delete the appropriate
profile or move it to another location where AppArmor would not check for
it.
Managing profiles with AppArmor requires you to have access to the log of
the system on which the application is running. So you do not need to
run the application on your profile, build host as long as you have
access to the machine that runs the application. You can run the
application on one system, transfer the logs
(/var/log/audit.log
or, if
audit
is not installed,
/var/log/messages
) to your profile build host and
run aa-logprof -f
path_to_logfile
.
Manually editing AppArmor profiles can introduce syntax errors. If you attempt to start or restart AppArmor with syntax errors in your profiles, error results are shown. This example shows the syntax of the entire parser error.
localhost:~ # rcapparmor start Loading AppArmor profiles AppArmor parser error in /etc/apparmor.d/usr.sbin.squid at line 410: syntax error, unexpected TOK_ID, expecting TOK_MODE Profile /etc/apparmor.d/usr.sbin.squid failed to load
Using the AppArmor YaST tools, a graphical error message indicates which profile contained the error and requests you to fix it.
![]() |
To fix a syntax error, log in to a terminal window as root
, open
the profile, and correct the syntax. Reload the profile set with
rcapparmor reload
.
The developers of AppArmor are eager to deliver products of the highest quality. Your feedback and your bug reports help us keep the quality high. Whenever you encounter a bug in AppArmor, file a bug report against this product:
Use your Web browser to go to https://bugzilla.novell.com/index.cgi.
Enter the account data of your Novell account and click
or
Create a new Novell account as follows:
Click
on the page.Provide a username and password and additional address data and click
to immediately proceed with the login creation.or
Provide data on which other Novell accounts you maintain to sync all these to one account.
Check whether a problem similar to yours has already been reported by clicking
. Use a quick search against a given product and keyword or use the .If your problem has already been reported, check this bug report and add extra information to it, if necessary.
If your problem has not been reported yet, select
from the top navigation bar and proceed to the page.Select the product against which to file the bug. In your case, this would be your product's release. Click
.Select the product version, component (AppArmor in this case), hardware platform, and severity.
Enter a brief headline describing your problem and add a more elaborate description including log files. You may create attachments to your bug report for screen shots, log files, or test cases.
Click
after you have entered all the details to send your report to the developers.Apache is a freely-available UNIX-based Web server. It is currently the most commonly used Web server on the Internet. Find more information about Apache at the Apache Web site at http://www.apache.org.
AppArmor contains applications and limits the actions they are permitted to take. It uses privilege confinement to prevent attackers from using malicious programs on the protected server and even using trusted applications in unintended ways.
Pattern in system or network activity that alerts of a possible virus or hacker attack. Intrusion detection systems might use attack signatures to distinguish between legitimate and potentially malicious activity.
By not relying on attack signatures, AppArmor provides "proactive" instead of "reactive" defense from attacks. This is better because there is no window of vulnerability where the attack signature must be defined for AppArmor as it does for products using attack sign