SUSE Linux Enterprise
www.novell.com11
March17,2009 Security Guide
Desktop
Security Guide
All content is copyright © 2006- 2009 Novell, Inc.
Legal Notice
This manual is protected under Novell intellectual property rights. By reproducing, duplicating or
distributing this manual you explicitly agree to conform to the terms and conditions of this license
agreement.
This manual may be freely reproduced, duplicated and distributed either as such or as part of a bundled
package in electronic and/or printed format, provided however that the following conditions are fullled:
That this copyright notice and the names of authors and contributors appear clearly and distinctively
on all reproduced, duplicated and distributed copies. That this manual, specically for the printed
format, is reproduced and/or distributed for noncommercial use only. The express authorization of
Novell, Inc must be obtained prior to any other use of any manual or part thereof.
For Novell trademarks, see the Novell Trademark and Service Mark list http://www.novell
.com/company/legal/trademarks/tmlist.html. * Linux is a registered trademark of
Linus Torvalds. All other third party trademarks are the property of their respective owners. A trademark
symbol (®, ™ etc.) denotes a 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 Novell, Inc., SUSE LINUX Products GmbH, the authors,
nor the translators shall be held liable for possible errors or the consequences thereof.
Contents
About This Guide ix
1 Security and Condentiality 1
1.1 Local Security and Network Security . . . . . . . . . . . . . . . . . 2
1.2 Some General Security Tips and Tricks . . . . . . . . . . . . . . . . 11
1.3 Using the Central Security Reporting Address . . . . . . . . . . . . . 14
Part I Authentication 15
2 Authentication with PAM 17
2.1 Structure of a PAM Conguration File . . . . . . . . . . . . . . . . 18
2.2 The PAM Conguration of sshd . . . . . . . . . . . . . . . . . . . 20
2.3 Conguration of PAM Modules . . . . . . . . . . . . . . . . . . . 22
2.4 Conguring PAM Using pam-cong . . . . . . . . . . . . . . . . . 24
2.5 For More Information . . . . . . . . . . . . . . . . . . . . . . . 26
3 Using NIS 27
3.1 Conguring NIS Clients . . . . . . . . . . . . . . . . . . . . . . 27
4 LDAP—A Directory Service 29
4.1 LDAP versus NIS . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Structure of an LDAP Directory Tree . . . . . . . . . . . . . . . . . 31
4.3 Conguring an LDAP Client with YaST . . . . . . . . . . . . . . . . 34
4.4 Conguring LDAP Users and Groups in YaST . . . . . . . . . . . . . . 42
4.5 Browsing the LDAP Directory Tree . . . . . . . . . . . . . . . . . . 44
4.6 For More Information . . . . . . . . . . . . . . . . . . . . . . . 45
5 Active Directory Support 47
5.1 Integrating Linux and AD Environments . . . . . . . . . . . . . . . . 47
5.2 Background Information for Linux AD Support . . . . . . . . . . . . 48
5.3 Conguring a Linux Client for Active Directory . . . . . . . . . . . . 54
5.4 Logging In to an AD Domain . . . . . . . . . . . . . . . . . . . . 57
5.5 Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Network Authentication with Kerberos 61
6.1 Kerberos Terminology . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 How Kerberos Works . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Users' View of Kerberos . . . . . . . . . . . . . . . . . . . . . . 66
6.4 For More Information . . . . . . . . . . . . . . . . . . . . . . . 67
7 Using the Fingerprint Reader 69
7.1 Supported Applications and Actions . . . . . . . . . . . . . . . . . 69
7.2 Managing Fingerprints with YaST . . . . . . . . . . . . . . . . . . 70
Part II Local Security 73
8 Conguring Security Settings with YaST 75
8.1 Security Overview . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.2 Predened Security Congurations . . . . . . . . . . . . . . . . . 76
8.3 Password Settings . . . . . . . . . . . . . . . . . . . . . . . . 77
8.4 Boot Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.5 Login Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.6 User Addition . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.7 Miscellaneous Settings . . . . . . . . . . . . . . . . . . . . . . . 79
9 PolicyKit 81
9.1 Available Policies and Supported Applications . . . . . . . . . . . . . 81
9.2 Authorization Types . . . . . . . . . . . . . . . . . . . . . . . . 82
9.3 Modifying and Setting Privileges . . . . . . . . . . . . . . . . . . . 84
10 Access Control Lists in Linux 93
10.1 Traditional File Permissions . . . . . . . . . . . . . . . . . . . . . 93
10.2 Advantages of ACLs . . . . . . . . . . . . . . . . . . . . . . . . 95
10.3 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.4 Handling ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . 96
10.5 ACL Support in Applications . . . . . . . . . . . . . . . . . . . . 104
10.6 For More Information . . . . . . . . . . . . . . . . . . . . . . 105
11 Encrypting Partitions and Files 107
11.1 Setting Up an Encrypted File System with YaST . . . . . . . . . . . . 108
11.2 Using Encrypted Home Directories . . . . . . . . . . . . . . . . . 111
11.3 Using vi to Encrypt Single ASCII Text Files . . . . . . . . . . . . . . 112
12 Certicate Store 113
12.1 Activating Certicate Store . . . . . . . . . . . . . . . . . . . . 113
12.2 Importing Certicates . . . . . . . . . . . . . . . . . . . . . . 114
13 Intrusion Detection with AIDE 115
13.1 Setting Up a AIDE Database . . . . . . . . . . . . . . . . . . . . 115
13.2 Local AIDE Checks . . . . . . . . . . . . . . . . . . . . . . . . 118
13.3 System Independent Checking . . . . . . . . . . . . . . . . . . . 119
13.4 For More Information . . . . . . . . . . . . . . . . . . . . . . 120
Part III Network Security 121
14 SSH: Secure Network Operations 123
14.1 The OpenSSH Package . . . . . . . . . . . . . . . . . . . . . . 123
14.2 The ssh Program . . . . . . . . . . . . . . . . . . . . . . . . . 124
14.3 scp—Secure Copy . . . . . . . . . . . . . . . . . . . . . . . . 124
14.4 sftp—Secure File Transfer . . . . . . . . . . . . . . . . . . . . . 125
14.5 The SSH Daemon (sshd)—Server-Side . . . . . . . . . . . . . . . . 125
14.6 SSH Authentication Mechanisms . . . . . . . . . . . . . . . . . . 126
14.7 X, Authentication, and Forwarding Mechanisms . . . . . . . . . . . . 128
14.8 Conguring An SSH Daemon with YaST . . . . . . . . . . . . . . . 129
15 Masquerading and Firewalls 131
15.1 Packet Filtering with iptables . . . . . . . . . . . . . . . . . . . . 131
15.2 Masquerading Basics . . . . . . . . . . . . . . . . . . . . . . . 134
15.3 Firewalling Basics . . . . . . . . . . . . . . . . . . . . . . . . 135
15.4 SuSErewall2 . . . . . . . . . . . . . . . . . . . . . . . . . . 136
15.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 141
16 Conguring VPN Server 143
16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
16.2 Creating the Simplest VPN Example . . . . . . . . . . . . . . . . . 147
16.3 Setting Up Your VPN Server Using Certicate Authority . . . . . . . . 149
16.4 KDE- and GNOME Applets For Clients . . . . . . . . . . . . . . . . 155
16.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 157
17 Managing X.509 Certication 159
17.1 The Principles of Digital Certication . . . . . . . . . . . . . . . . 159
17.2 YaST Modules for CA Management . . . . . . . . . . . . . . . . . 163
Part IV Conning Privileges with Novell AppArmor 175
18 Introducing AppArmor 177
18.1 Background Information on AppArmor Proling . . . . . . . . . . . 178
19 Getting Started 179
19.1 Installing Novell AppArmor . . . . . . . . . . . . . . . . . . . . 180
19.2 Enabling and Disabling Novell AppArmor . . . . . . . . . . . . . . 180
19.3 Choosing the Applications to Prole . . . . . . . . . . . . . . . . 181
19.4 Building and Modifying Proles . . . . . . . . . . . . . . . . . . 182
19.5 Conguring Novell AppArmor Event Notication and Reports . . . . . 184
19.6 Updating Your Proles . . . . . . . . . . . . . . . . . . . . . . 186
20 Immunizing Programs 187
20.1 Introducing the AppArmor Framework . . . . . . . . . . . . . . . 188
20.2 Determining Programs to Immunize . . . . . . . . . . . . . . . . 190
20.3 Immunizing cron Jobs . . . . . . . . . . . . . . . . . . . . . . . 191
20.4 Immunizing Network Applications . . . . . . . . . . . . . . . . . 192
21 Prole Components and Syntax 197
21.1 Breaking a Novell AppArmor Prole into Its Parts . . . . . . . . . . . 198
21.2 Prole Types . . . . . . . . . . . . . . . . . . . . . . . . . . 201
21.3
#include Statements . . . . . . . . . . . . . . . . . . . . . . 204
21.4 Capability Entries (POSIX.1e) . . . . . . . . . . . . . . . . . . . . 205
21.5 Network Access Control . . . . . . . . . . . . . . . . . . . . . 205
21.6 Paths and Globbing . . . . . . . . . . . . . . . . . . . . . . . 206
21.7 File Permission Access Modes . . . . . . . . . . . . . . . . . . . 209
21.8 Execute Modes . . . . . . . . . . . . . . . . . . . . . . . . . 212
21.9 Resource Limit Control . . . . . . . . . . . . . . . . . . . . . . 217
21.10 Auditing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 218
21.11 Setting Capabilities per Prole . . . . . . . . . . . . . . . . . . . 219
22 AppArmor Prole Repositories 221
22.1 Using the Local Repository . . . . . . . . . . . . . . . . . . . . 221
22.2 Using the External Repository . . . . . . . . . . . . . . . . . . . 222
23 Building and Managing Proles with YaST 225
23.1 Adding a Prole Using the Wizard . . . . . . . . . . . . . . . . . 227
23.2 Manually Adding a Prole . . . . . . . . . . . . . . . . . . . . . 235
23.3 Editing Proles . . . . . . . . . . . . . . . . . . . . . . . . . 235
23.4 Deleting a Prole . . . . . . . . . . . . . . . . . . . . . . . . 241
23.5 Updating Proles from Log Entries . . . . . . . . . . . . . . . . . 241
23.6 Managing Novell AppArmor and Security Event Status . . . . . . . . . 243
24 Building Proles from the Command Line 247
24.1 Checking the AppArmor Module Status . . . . . . . . . . . . . . . 247
24.2 Building AppArmor Proles . . . . . . . . . . . . . . . . . . . . 249
24.3 Adding or Creating an AppArmor Prole . . . . . . . . . . . . . . 250
24.4 Editing an AppArmor Prole . . . . . . . . . . . . . . . . . . . . 250
24.5 Deleting an AppArmor Prole . . . . . . . . . . . . . . . . . . . 250
24.6 Two Methods of Proling . . . . . . . . . . . . . . . . . . . . . 251
24.7 Important Filenames and Directories . . . . . . . . . . . . . . . . 272
25 Proling Your Web Applications Using ChangeHat 275
25.1 Apache ChangeHat . . . . . . . . . . . . . . . . . . . . . . . . 276
25.2 Conguring Apache for mod_apparmor . . . . . . . . . . . . . . . 282
26
Conning Users with pam_apparmor 287
27 Managing Proled Applications 289
27.1 Monitoring Your Secured Applications . . . . . . . . . . . . . . . 289
27.2 Conguring Security Event Notication . . . . . . . . . . . . . . . 290
27.3 Conguring Reports . . . . . . . . . . . . . . . . . . . . . . . 293
27.4 Conguring and Using the AppArmor Desktop Monitor Applet . . . . . 313
27.5 Reacting to Security Event Rejections . . . . . . . . . . . . . . . . 314
27.6 Maintaining Your Security Proles . . . . . . . . . . . . . . . . . 314
28 Support 317
28.1 Updating Novell AppArmor Online . . . . . . . . . . . . . . . . . 317
28.2 Using the Man Pages . . . . . . . . . . . . . . . . . . . . . . . 317
28.3 For More Information . . . . . . . . . . . . . . . . . . . . . . 319
28.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 320
28.5 Reporting Bugs for AppArmor . . . . . . . . . . . . . . . . . . . 327
29 AppArmor Glossary 329
Part V The Linux Audit Framework 333
30 Understanding Linux Audit 335
30.1 Introducing the Components of Linux Audit . . . . . . . . . . . . . 338
30.2 Conguring the Audit Daemon . . . . . . . . . . . . . . . . . . . 339
30.3 Controlling the Audit System Using auditctl . . . . . . . . . . . . . 345
30.4 Passing Parameters to the Audit System . . . . . . . . . . . . . . . 347
30.5 Understanding the Audit Logs and Generating Reports . . . . . . . . . 351
30.6 Querying the Audit Daemon Logs with ausearch . . . . . . . . . . . 363
30.7 Analyzing Processes with autrace . . . . . . . . . . . . . . . . . . 367
30.8 Visualizing Audit Data . . . . . . . . . . . . . . . . . . . . . . 368
31 Setting Up the Linux Audit Framework 371
31.1 Determining the Components to Audit . . . . . . . . . . . . . . . 372
31.2 Conguring the Audit Daemon . . . . . . . . . . . . . . . . . . . 373
31.3 Enabling Audit for System Calls . . . . . . . . . . . . . . . . . . 374
31.4 Setting Up Audit Rules . . . . . . . . . . . . . . . . . . . . . . 375
31.5 Conguring Audit Reports . . . . . . . . . . . . . . . . . . . . . 377
31.6 Conguring Log Visualization . . . . . . . . . . . . . . . . . . . 380
32 Introducing an Audit Rule Set 383
32.1 Adding Basic Audit Conguration Parameters . . . . . . . . . . . . 384
32.2 Adding Watches on Audit Log Files and Conguration Files . . . . . . . 385
32.3 Monitoring File System Objects . . . . . . . . . . . . . . . . . . 386
32.4 Monitoring Security Conguration Files and Databases . . . . . . . . . 387
32.5 Monitoring Miscellaneous System Calls . . . . . . . . . . . . . . . 390
32.6 Filtering System Call Arguments . . . . . . . . . . . . . . . . . . 390
32.7 Managing Audit Event Records Using Keys . . . . . . . . . . . . . . 393
33 Useful Resources 395
About This Guide
This manual introduces the basic concepts of system security on SUSE Linux Enterprise
Desktop. It covers extensive documentation about 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 a rewall and masquerading and how to set up
virtual private networks (VPN). This manual also shows how to make use of the product
inherent security software like Novell AppArmor (which lets you specify per program
which les 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. This
includes 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.novell.com/documentation or to
the following section.
1 Available Documentation
We provide HTML and PDF versions of our books in different languages. The following
manuals for users and administrators are available on this product:
GNOME User Guide (↑GNOME User Guide)
Introduces the GNOME desktop of SUSE Linux Enterprise Desktop. It guides you
through using and conguring the desktop and helps you perform key tasks. It is
intended mainly for end users who want to make efcient use of GNOME desktop
as their default desktop.
Application Guide (↑Application Guide)
Learn how to use and congure key desktop applications on SUSE Linux Enterprise
Desktop. This guide introduces browsers and e-mail clients as well as ofce applications and collaboration tools. It also covers graphics and multimedia applications.
Deployment Guide (↑Deployment Guide)
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.
Administration Guide (↑Administration Guide)
Covers system administration tasks like maintaining, monitoring and customizing
an initially installed system.
Security Guide (page 1)
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 Novell AppArmor (which lets you specify per program which les the program
may read, write, and execute) or the auditing system that reliably collects information about any security-relevant events.
System Analysis and Tuning Guide (↑System Analysis and Tuning Guide)
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 efciently manage resources. Also contains an overview of common problems
and solutions and of additional help and documentation resources.
Virtualization with Xen (↑Virtualization with Xen)
Offers an introduction to virtualization technology of your product. It features an
overview of the various elds 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.
In addition to the comprehensive manuals, several quick start guides are available:
Installation Quick Start (↑Installation Quick Start)
Lists the system requirements and guides you step-by-step through the installation
of SUSE Linux Enterprise Desktop from DVD, or from an ISO image.
Linux Audit Quick Start
Gives a short overview how to enable and congure the auditing system and how
to execute key tasks such as setting up audit rules, generating reports, and analyzing
the log les.
x Security Guide
Novell AppArmor Quick Start
Helps you understand the main concepts behind Novell® AppArmor.
Find HTML versions of most SUSE Linux Enterprise Desktop 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.novell.com/
documentation where you can download PDF or HTML versions of the manuals
for your product.
2 Feedback
Several feedback channels are available:
• To report bugs for a product component or to submit enhancements requests, please
use https://bugzilla.novell.com/. If you are new to Bugzilla, you
might nd the Bug Writing FAQs helpful, available from the Novell Bugzilla home
page.
• We want to hear your comments and suggestions about this manual and the other
documentation included with this product. Please use the User Comments feature
at the bottom of each page of the online documentation and enter your comments
there.
3 Documentation Conventions
The following typographical conventions are used in this manual:
•
/etc/passwd: directory names and lenames
•
placeholder: replace placeholder with the actual value
•
PATH: the environment variable PATH
•
ls, --help: commands, options, and parameters
•
user: users or groups
About This Guide xi
•
Alt, Alt + F1: a key to press or a key combination; keys are shown in uppercase as
on a keyboard
•
File, File > Save As: menu items, buttons
•
Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a
chapter in another manual.
xii Security Guide
Security and Condentiality
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. 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 condentiality 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 if the suspicion arises that
someone has gained unauthorized access and tampered with les.
1
Security and Condentiality 1
1.1 Local Security and Network Security
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 from the console of a computer (physical access)
• 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 all your personal data to any surfer.
In the list above, the rst 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 condence of that person by using
clever rhetoric. The victim could be led to reveal gradually more information, maybe
without even becoming 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 cable or the power
cord. 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.
2 Security Guide
Serial terminals connected to serial ports are still used in many places. Unlike network
interfaces, they do not rely on a network protocol 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 anything that runs over the wires. 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 le locally on a host requires other 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.
1.1.1 Local Security
Local security starts with the physical environment in the location where the 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 the supreme
power on the system. root can take on the identity of any other local user without
being prompted for the password and read any locally stored le.
1.1.2 Passwords
On a Linux system, passwords are not stored as plain text and the text string entered 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
le. 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.
Security and Condentiality 3
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 le 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 is not safe enough.
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 rst 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.
1.1.3 The Boot Procedure
Congure your system so it cannot be booted from a oppy or from CD, either by removing the drives entirely or by setting a BIOS password and conguring 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 10, 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 rst authority to grant root permissions at system start-
up.
1.1.4 File Permissions
As a general rule, always work with the most restrictive privileges possible for a given
task. For example, it is denitely 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.
4 Security Guide
The permissions of all les included in the SUSE Linux Enterprise Desktop distribution
are carefully chosen. A system administrator who installs additional software or other
les 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 le list, which allows them to detect any in-
correct le permissions immediately. An incorrect le attribute does not only mean
that les could be changed or deleted. These modied les could be executed by root
or, in the case of conguration les, programs could use such les with the permissions
of root. This signicantly increases the possibilities of an attacker. Attacks like this
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.
A SUSE® Linux Enterprise Desktop system includes the les permissions,
permissions.easy, permissions.secure, and permissions.paranoid,
all in the directory /etc. The purpose of these les is to dene special permissions,
such as world-writable directories or, for les, 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 le owner, in most cases root). An administrator can use
the le /etc/permissions.local to add his own settings.
To dene which of the above les is used by SUSE Linux Enterprise Desktop's conguration programs to set permissions accordingly, select Local Security in the Security
and Users section of YaST. To learn more about the topic, read the comments in /etc/
permissions or consult the manual page of chmod (man chmod).
1.1.5 Buffer Overows and Format String
Bugs
Special care must be taken whenever a program is supposed to process data that can or
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 the
interfaces dened for that purpose.
A buffer overow 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
Security and Condentiality 5
the user) uses up some 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 inuenced 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.4, “File Permissions” (page 4)).
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.4, “File Permissions”
(page 4)).
Given that buffer overows 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 overows and format string bugs should be classied as being
relevant for both local and network security.
1.1.6 Viruses
Contrary to what some people say, there are viruses that run on Linux. However, the
viruses that are known were released by their authors as a proof of concept to prove
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 les, especially important
with system les. 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 Desktop's RPM packages
6 Security Guide
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 to the world of networks
entirely. Worms do not need a host to spread.
1.1.7 Network Security
Network security is important for protecting from an attack that is started outside. 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.
1.1.8 X Window System and X
Authentication
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 should 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 tiny 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.
Security and Condentiality 7
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 (the word goes back not to ordinary cookies, but to Chinese fortune cookies,
which contain an epigram) is stored on login in the le .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 le .Xauthority can be examined by the user with the tool xauth.
If you were to rename .Xauthority or if you deleted the le from your home direc-
tory 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 Op-
erations (page 123).
WARNING
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 sniff your keyboard
input, for instance.
1.1.9 Buffer Overows and Format String
As discussed in Section 1.1.5, “Buffer Overows and Format String Bugs” (page 5),
buffer overows and format string bugs should be classied as issues concerning both
local and network security. As with the local variants of such bugs, buffer overows
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 any other vulnerabilities that might exist on
the system.
Buffer overows 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 the security mailing lists.
They can be used to target the vulnerability without knowing the details of the code.
8 Security Guide
Bugs
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 x the problems in their software. With free software, anyone
has access to the source code (SUSE Linux Enterprise Desktop comes with all available
source codes) and anyone who nds a vulnerability and its exploit code can submit a
patch to x the corresponding bug.
1.1.10 Denial of Service
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 overow.
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 (snifng, TCP connection hijacking, spoong)
and DNS poisoning.
1.1.11 Man in the Middle: Snifng,
Hijacking, Spoong
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 trafc 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 nally 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.
Security and Condentiality 9
Spoong is an attack where packets are modied 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.
1.1.12 DNS Poisoning
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.
1.1.13 Worms
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.
10 Security Guide
1.2 Some General Security Tips and
Tricks
To handle security competently, it is important to keep up with new developments and
stay informed about the latest security issues. One very good way to protect your systems
against problems of all kinds is to get and install the updated packages recommended
by security announcements as quickly as possible. SUSE security announcements are
published on the list opensuse-security-announce@opensuse.org. It is a
rst-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/Communicate/Mailinglists.
SUSE security advisories are also available as a news feed at http://www.novell
.com/linux/security/suse_security.xml.
The mailing list opensuse-security@opensuse.org is a good place to discuss
any security issues of interest. Subscribe to it on the same Web page.
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.
The following is a list of rules you may nd useful in dealing with basic security concerns:
• 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 on IP addresses alone.
• 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
Security and Condentiality 11
such programs (bind, postx, ssh, etc.). The same should apply to software relevant
to local security.
•
Change the /etc/permissions le to optimize the permissions of les 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 les.
• 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 les of your system in a reliable way, use the program
AIDE (Advanced Intrusion Detection Environment), available on SUSE Linux
Enterprise Desktop. 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.
12 Security Guide
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 rst
CD of the distribution and on most key servers worldwide.
• Check your backups of user and system les regularly. Consider that if you do not
test whether the backup works, it might actually be worthless.
• Check your log les. 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 SuSErewall 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 to congure the suspend image encryption
using the configure-suspend-encryption.sh script. The program creates
the key, copies it to /etc/suspend.key, and modies /etc/suspend.conf
to use encryption for suspend images.
Security and Condentiality 13
1.3 Using the Central Security Reporting Address
If you discover a security-related problem (please check the available update packages
rst), 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.novell.com/linux/
security/securitysupport.html.
14 Security Guide
Part I. Authentication
Authentication with PAM
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 congured.
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 sufcient
to adapt or write a suitable PAM module for use by the program in question.
Every program that relies on the PAM mechanism has its own conguration le in the
directory /etc/pam.d/programname. These les dene the PAM modules used
for authentication. In addition, there are global conguration les for PAM modules
under /etc/security, which dene 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 conguration les and return the result to the calling application.
2
Authentication with PAM 17
To facilitate the creation and maintenance of PAM modules, common default conguration les for the functions auth, account, password, and session modules
have been introduced. These are pulled in from every application's PAM conguration.
Updates to the global PAM conguration modules in common-* are thus propagated
across all PAM conguration les without requiring the administrator to update every
single PAM conguration le.
The global common PAM conguration les are maintained using the pam-cong tool.
This tool automatically adds new modules to the conguration, changes the conguration
of existing ones or deletes modules or options from the congurations. Manual intervention in maintaining PAM congurations is minimized or no longer required.
2.1 Structure of a PAM Conguration
File
Each line in a PAM conguration le contains a maximum of four columns:
<Type of module> <Control flag> <Module path> <Options>
PAM modules are processed as stacks. Different types of modules have different purposes, for example, one module checks the password, another one veries the location
from which the system is accessed, and yet another one reads user-specic settings.
PAM knows about four different types of modules:
auth
The purpose of this type of module is to check the user's authenticity. This is traditionally done by querying a password, but it can also be achieved with the help of
a chip card or through biometrics (for example, ngerprints or iris scan).
account
Modules of this type check whether 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 under 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.
18 Security Guide
session
Modules of this type are responsible for managing and conguring user sessions.
They are started before and after authentication to register login attempts in system
logs and congure the user's specic environment (mail accounts, home directory,
system limits, etc.).
The second column contains control ags to inuence the behavior of the modules
started:
required
A module with this ag must be successfully processed before the authentication
may proceed. After the failure of a module with the required ag, all other
modules with the same ag are processed before the user receives a message about
the failure of the authentication attempt.
requisite
Modules having this ag must also be processed successfully, in much the same
way as a module with the required ag. However, in case of failure a module
with this ag 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 ag. The requisite ag can be used as a
basic lter checking for the existence of certain conditions that are essential for a
correct authentication.
sufficient
After a module with this ag has been successfully processed, the calling application
receives an immediate message about the success and no further modules are pro-
cessed, provided there was no preceding failure of a module with the required
ag. The failure of a module with the sufficient ag has no direct conse-
quences, in the sense that any subsequent modules are processed in their respective
order.
optional
The failure or success of a module with this ag 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 ag is given, the le specied as argument is inserted at this place.
Authentication with PAM 19
The module path does not need to be specied explicitly, as long as the module is located in the default directory /lib/security (for all 64-bit platforms supported by
SUSE® Linux Enterprise Desktop, the directory is /lib64/security). The fourth
column may contain an option for the given module, such as debug (enables debugging)
or nullok (allows the use of empty passwords).
NOTE: 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 respective pam modules when installing new modules.
2.2 The PAM Conguration of sshd
To show how the theory behind PAM works, consider the PAM conguration of sshd
as a practical example:
Example 2.1
#%PAM-1.0
auth required pam_nologin.so
auth include common-auth
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
# Enable the following line to get resmgr support for
# ssh sessions (see /usr/share/doc/packages/resmgr/README)
#session optional pam_resmgr.so fake_ttyname
The rst module that is called is pam_nologin. It checks whether the le /etc/
nologin exists. If it does, no other user than root may log in.
The typical PAM conguration of an application (sshd, in this case) contains four include
statements referring to the conguration les of four module types: common-auth,
common-account, common-password, and common-session. These four
les hold the default conguration for each module type. By including them instead of
adding each module separately to the respective PAM conguration, you automatically
get an updated PAM conguration if the administrator changes the defaults. In former
times, you had to adjust all conguration les manually for all applications when
changes to PAM occurred or a new application was installed. Now the PAM congura-
20 Security Guide
PAM Conguration for sshd
tion is made with central conguration les and all changes are automatically inherited
by the PAM conguration of each service.
The rst include le (common-auth) calls two modules of the auth type:
pam_env.so and pam_unix2.so. See Example 2.2, “Default Conguration for
the auth Section” (page 21).
Example 2.2
auth required pam_env.so
auth required pam_unix2.so
Default Conguration for the auth Section
The rst one, pam_env, loads the le /etc/security/pam_env.conf to set
the environment variables as specied in this le. This can be used to set the DISPLAY
variable to the correct value, because the pam_env module knows about the location
from which the login is taking place. The second one, pam_unix2, checks the user's
login and password against /etc/passwd and /etc/shadow.
The whole stack of auth modules is processed before sshd gets any feedback about
whether the login has succeeded. Given that all modules of the stack have the
required control ag, they must all 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 notied 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 Conguration
for the account Section” (page 21). 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 Conguration for the password Section”
(page 21).
Example 2.3
account required pam_unix2.so
Example 2.4
password requisite pam_pwcheck.so nullok cracklib
password required pam_unix2.so nullok use_authtok
Default Conguration for the account Section
Default Conguration for the password Section
Authentication with PAM 21
Again, the PAM conguration of sshd involves just an include statement referring to
the default conguration for password modules located in common-password.
These modules must successfully be completed (control ags 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 congured to complain about expired passwords, the password
modules should also be used.
Example 2.5
session required pam_limits.so
session required pam_unix2.so
session optional pam_umask.so
As the nal step, the modules of the session type, bundled in the common-session
le are called to congure the session according to the settings for the user in question.
The pam_limits module loads the le /etc/security/limits.conf, which
may dene 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 le mode creation
mask. Since this module carries the optional ag, 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.
Default Conguration for the session Section
2.3 Conguration of PAM Modules
Some of the PAM modules are congurable. The corresponding conguration les are
located in /etc/security. This section briey describes the conguration les
relevant to the sshd example—pam_env.conf, and limits.conf.
22 Security Guide
2.3.1 pam_env.conf
This le can be used to dene 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 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 Ex-
ample 2.6, “pam_env.conf” (page 23).
Example 2.6
REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST}
DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
The rst 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 the le /etc/security/pam_env.conf.
pam_env.conf
2.3.2 pam_mount.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 le server keeps
all the home directories of users. With this method, it is not necessary to mount a
complete /home directory where all user home directories would be accessible. Instead,
only the home directory of the respective user is mounted.
Authentication with PAM 23
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 conguration of this feature can be done by means of yast. Select Network
Settings > Windows Domain Membership > Expert Settings to add the respective le
server.
2.3.3 limits.conf
System limits can be set on a user or group basis in the le limits.conf, which is
read by the pam_limits module. The le allows you to set hard limits, which may
not be exceeded at all, and soft limits, which may be exceeded temporarily. To learn
about the syntax and the available options, read the comments included in the le
/etc/security/limits.conf.
2.4 Conguring PAM Using
pam-cong
The pam-cong tool helps you congure the global PAM conguration les under
/etc/pam.d/common-*-pc as well as several selected application congurations.
For a list of supported modules, use the command pam-config --list-modules.
Use the pam-config command to maintain your PAM conguration les. Add new
modules to your PAM congurations, delete other modules or modify options to these
modules. When changing global PAM conguration les, no manual tweaking of the
PAM setup for individual applications is required.
A simple real-world use case for pam-cong would involve the following:
Auto-generate a fresh Unix-style PAM conguration. Let pam-cong
1
create the simplest possible setup which you can extend later on. The
pam-config --create command creates a simple UNIX authentication
conguration. Pre-existing conguration les not maintained by pam-cong are
overwritten, but backup copies are kept as *.pam-config-backup.
24 Security Guide
Add a new authentication method. Adding a new authentication method
2
(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 conguration les.
Add debugging for test purposes. To make sure the new authentication
3
procedure works as planned, turn on debugging for all PAM-related operations.
The pam-config --add --ldap-debug turns on debugging for LDAPrelated PAM operations. Find the debugging output in /var/log/messages.
Query your setup. Before you nally apply your new PAM setup, check
4
whether it contains all the options you planned 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
5
setup when you are entirely satised with the performance of it. The
pam-config --delete --ldap-debug turns of debugging for LDAP
authentication. In case you had debugging options added for other modules, use
similar commands to turn these off.
When you create your PAM conguration les from scratch using the pam-config
--create command, it creates symbolic links from the common-* to the
common-*-pc les. pam-cong only modies the common-*-pc conguration
les. Removing these symbolic links effectively disable pam-cong, because pamcong only operates on the common-*-pc les and these les are not put into effect
without the symbolic links.
For more information on the pam-config command and the options available, refer
to the manual page of pam-config, pam-config(8).
Authentication with PAM 25
2.5 For More Information
In the directory /usr/share/doc/packages/pam of your installed system, nd
the following additional documentation:
READMEs
In the top level of this directory, there are some general README les. The subdirectory modules holds README les about the available PAM modules.
The Linux-PAM System Administrators' Guide
This document includes everything that a system administrator should know about
PAM. It discusses a range of topics, from the syntax of conguration les to the
security aspects of PAM. The document is available as a PDF le, in HTML format,
and as plain text.
The Linux-PAM Module Writers' Manual
This document summarizes the topic from the developer's point of view, with information about how to write standard-compliant PAM modules. It is available as
a PDF le, in HTML format, and as plain text.
The Linux-PAM Application Developers' Guide
This document includes everything needed by an application developer who wants
to use the PAM libraries. It is available as a PDF le, in HTML format, and as
plain text.
The PAM Manual Pages
PAM in general as well as the individual modules come with manual pages that
provide a good overview of the functionality provided by the respective component.
Thorsten Kukuk has developed a number of PAM modules and made some information
available about them at http://www.suse.de/~kukuk/pam/.
26 Security Guide
Using NIS
As soon as multiple UNIX systems in a network want to access common resources, it
becomes important that all user and group identities are the same for all machines in
that network. The network should be transparent to users: whatever machines they use,
they always nd themselves in exactly the same environment. This can be done by
means of NIS and NFS services. NFS distributes le systems over a network and is
discussed in Chapter 25, 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 les
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.”
3.1 Conguring NIS Clients
Use the YaST module NIS Client to congure a workstation to use NIS. Select whether
the host has a static IP address or receives one issued by DHCP. DHCP can also provide
the NIS domain and the NIS server. If a static IP address is used, specify the NIS domain
and the NIS server manually. See Figure 3.1, “Setting Domain and Address of a NIS
Server” (page 28). Find makes YaST search for an active NIS server in your whole
network. Depending on the size of your local network, this may be a time-consuming
process. Broadcast asks for a NIS server in the local network after the specied servers
fail to respond.
3
Using NIS 27
You can also specify multiple servers by entering their addresses in Addresses of NIS
Servers and separating them by spaces.
Depending on your local installation, you may also want to activate the automounter.
This option also installs additional software if required.
In the expert settings, disable Answer Remote Hosts if you do not want other hosts to
be able to query which server your client is using. By checking Broken Server, the client
is enabled to receive replies from a server communicating through an unprivileged port.
For further information, see man ypbind.
After you have made your settings, click Finish to save them and return to the YaST
control center.
Figure 3.1
Setting Domain and Address of a NIS Server
28 Security Guide
LDAP—A Directory Service
The Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to
access and maintain information directories. LDAP can be used for numerous purposes,
such as user and group management, system conguration management, or address
management. This chapter provides a basic understanding of how OpenLDAP works
and how to manage LDAP data with YaST. While there are several implementations
of the LDAP protocol, this chapter focuses entirely on the OpenLDAP implementation.
It is crucial within a networked environment to keep important information structured
and quickly available. This can be done with a directory service that, like the common
yellow pages, keeps information available in a well-structured, quickly searchable form.
In the ideal case, a central server keeps the data in a directory and distributes it to all
clients using a certain protocol. The data is structured in a way that allows a wide range
of applications to access it. That way, it is not necessary for every single calendar tool
and e-mail client to keep its own database—a central repository can be accessed instead.
This notably reduces the administration effort for the information. 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:
4
• To make numerous concurrent reading accesses possible, the number of updates
is usually very low compared to the number of read accesses and write access is
often limited to a few users with administrative priviledges. Conventional
databases are optimized for accepting the largest possible data volume in a short
time.
LDAP—A Directory Service 29
• 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 consistancy, such as referential integrity support of transactions. Opposed to
that short-term inconsitancies are usually acceptable in LDAP directories. LDAP
directories often do not have such strong consistancy 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 accessing this service should gain access
quickly and easily.
4.1 LDAP versus NIS
The Unix system administrator traditionally uses the NIS service for name resolution
and data distribution in a network. The conguration data contained in the les in /etc
and the directories group, hosts, mail, netgroup, networks, passwd,
printcap, protocols, rpc, and services are distributed by clients all over the
network. These les can be maintained without major effort because they are simple
text les. The handling of larger amounts of data, however, becomes increasingly difcult due to nonexistent structuring. NIS is only designed for Unix platforms. This
means it 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. Application tasks mentioned above
are additionally supported in non-Unix systems.
The LDAP principle can be applied to any data structure that should be centrally administered. A few application examples are:
• Employment as a replacement for the NIS service
• Mail routing (postx, sendmail)
• Address books for mail clients, like Mozilla, Evolution, and Outlook
30 Security Guide
• 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-dened
hierarchical structure of the data eases the administration of large amounts of data, because it can be searched more easily.
4.2 Structure of an LDAP Directory Tree
To get a deep background knowledge on how a LDAP server works and how the data
are stored, it is vital to understand the way the data are organized on the server and how
this structure enables LDAP to provide fast access to the data you need. 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 in an LDAP context. 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 Desktop.
An LDAP directory has a tree structure. All entries (called objects) of the directory
have a dened position within this hierarchy. This hierarchy is called the directory in-
formation tree (DIT). The complete path to the desired entry, which unambiguously
identies it, is called 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” (page 32).
LDAP—A Directory Service 31
Figure 4.1
ou=devel
cn=Tux Linux cn=Geeko Linux
dc=example,dc=com
ou=doc ou=it
Structure of an LDAP Directory
The complete diagram is a ctional directory information tree. The entries on three
levels are depicted. Each entry corresponds to one box in the picture. The complete,
valid distinguished name for the ctional 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 concerned object must or can be assigned. The Schema,
therefore, must contain denitions 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 denes 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” (page 33) 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.
32 Security Guide
Table 4.1
Commonly Used Object Classes and Attributes
Required Attributes
dcexample
dcObject
MeaningObject Class
domainComponent (name
Example Entry
components of the domain)
organizationalUnit
inetOrgPerson
organizationalUnit (organizational unit)
inetOrgPerson (person-related
oudoc
sn and cnGeeko Linux
data for the intranet or Internet)
Example 4.1, “Excerpt from schema.core” (page 33) shows an excerpt from a Schema
directive with explanations (line numbering for explanatory reasons).
Example 4.1
#1 attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName')
#2 DESC 'RFC2256: organizational unit this object belongs to'
#3 SUP name )
...
#4 objectclass ( 2.5.6.5 NAME 'organizationalUnit'
#5 DESC 'RFC2256: an organizational unit'
#6 SUP top STRUCTURAL
#7 MUST ou
#8 MAY (userPassword $ searchGuide $ seeAlso $ businessCategory
$ x121Address $ registeredAddress $ destinationIndicator
$ preferredDeliveryMethod $ telexNumber
$ teletexTerminalIdentifier $ telephoneNumber
$ internationaliSDNNumber $ facsimileTelephoneNumber
$ street $ postOfficeBox $ postalCode $ postalAddress
$ physicalDeliveryOfficeName
$ st $ l $ description) )
...
Excerpt from schema.core
The attribute type organizationalUnitName and the corresponding object class
organizationalUnit serve as an example here. Line 1 features the name of the
attribute, its unique OID (object identier) (numerical), and the abbreviation of the attribute.
LDAP—A Directory Service 33
Line 2 gives a brief description of the attribute with DESC. The corresponding RFC on
which the denition is based is also mentioned here. SUP in line 3 indicates a superor-
dinate attribute type to which this attribute belongs.
The denition of the object class organizationalUnit begins in line 4, like in
the denition of the attribute, with an OID and the name of the object class. Line 5
features a brief description of the object class. Line 6, with its entry SUP top, indicates
that this object class is not subordinate to another object class. Line 7, starting with
MUST, lists all attribute types that must be used in conjunction with an object of the
type organizationalUnit. Line 8, starting with MAY, lists all attribute types that
are permitted in conjunction with this object class.
A very good introduction to the use of Schemas can be found in the documentation of
OpenLDAP. When installed, nd it in /usr/share/doc/packages/openldap2/
admin-guide/index.html.
4.3 Conguring an LDAP Client with
YaST
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 Network Services >
LDAP Client. YaST automatically enables any PAM and NSS related changes as required
by LDAP and installs the necessary les. Simply connect your client to the server and
let YaST manage users over LDAP. This basic setup is described in Section 4.3.1,
“Conguring Basic Settings” (page 35).
Use the YaST LDAP client to further congure the YaST group and user conguration
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.3.2,
“Conguring the YaST Group and User Administration Modules” (page 38).
34 Security Guide
4.3.1 Conguring Basic Settings
The basic LDAP client conguration dialog (Figure 4.2, “YaST: LDAP Client Con-
guration” (page 35)) opens during installation if you choose LDAP user management
or when you select Network Services > LDAP Client in the YaST Control Center in the
installed system.
Figure 4.2
YaST: LDAP Client Conguration
To authenticate users of your machine against an OpenLDAP server and enable user
management via OpenLDAP, proceed as follows:
Click Use LDAP to enable the use of LDAP. Select Use LDAP but Disable Logins
1
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.
2
LDAP—A Directory Service 35
Enter the LDAP Base DN to select the search base on the LDAP server. To retrieve
3
the base DN automatically, click Fetch DN. YaST then checks for any LDAP
database on the server address specied 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 LDAP
4
TLS/SSL.
If the LDAP server still uses LDAPv2, explicitly enable the use of this protocol
5
version by selecting LDAP Version 2.
Select Start Automounter to mount remote directories on your client, such as a
6
remotely managed /home.
Select Create Home Directory on Login to have a user's home automatically
7
created on the rst user login.
Click Finish to apply your settings.
8
To modify data on the server as administrator, click Advanced Conguration. The following dialog is split in two tabs. See Figure 4.3, “YaST: Advanced Conguration”
(page 37).
36 Security Guide
Figure 4.3
YaST: Advanced Conguration
In the Client Settings tab, adjust the following settings according to your needs:
1
If the search base for users, passwords, and groups differs from the global
1a
search base specied in the LDAP base DN, enter these different naming
contexts in User Map, Password Map, and Group Map.
Specify the password change protocol. The standard method to use whenever
1b
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 Group Member Attribute. The default
1c
value for this is member.
LDAP—A Directory Service 37
In Administration Settings, adjust the following settings:
2
Set the base for storing your user management data via Conguration Base
2a
DN.
Enter the appropriate value for Administrator DN. This DN must be identical
2b
with the rootdn value specied 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 Append Base DN to have the base DN added automatically when
you enter cn=Administrator.
Check Create Default Conguration Objects to create the basic conguration
2c
objects on the server to enable user management via LDAP.
If your client machine should act as a le server for home directories across
2d
your network, check Home Directories on This Machine.
Use the Password Policy section to select, add, delete, or modify the password
2e
policy settings to use. The conguration of password policies with YaST is
part of the LDAP server setup.
Click OK to leave the Advanced Conguration, then Finish to apply your
2f
settings.
Use Congure User Management Settings to edit entries on the LDAP server. Access
to the conguration modules on the server is then granted according to the ACLs and
ACIs stored on the server. Follow the procedures outlined in Section 4.3.2, “Conguring
the YaST Group and User Administration Modules” (page 38).
4.3.2 Conguring the YaST Group and User
Use the YaST LDAP client to adapt the YaST modules for user and group administration
and to extend them as needed. Dene templates with default values for the individual
attributes to simplify the data registration. The presets created here are stored as LDAP
38 Security Guide
Administration Modules
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.
Figure 4.4
YaST: Module Conguration
The dialog for module conguration (Figure 4.4, “YaST: Module Conguration”
(page 39)) allows the creation of new modules, selection and modication of existing
conguration modules, and design and modication of templates for such modules.
To create a new conguration module, proceed as follows:
In the LDAP Client Conguration click Advanced Conguration, then open the
1
Administration Settings tab. Click Congure User Management Settings and
enter the LDAP server credentials.
LDAP—A Directory Service 39
Click New and select the type of module to create. For a user conguration
2
module, select suseuserconfiguration and for a group conguration
choose susegroupconfiguration.
Choose a name for the new template. The content view then features a table
3
listing all attributes allowed in this module with their assigned values. Apart from
all set attributes, the list also contains all other attributes allowed by the current
Schema but currently not used.
Accept the preset values or adjust the defaults to use in group and user congu-
4
ration by selecting the respective attribute, pressing Edit, and entering the new
value. Rename a module by simply changing the cn attribute of the module.
Clicking Delete deletes the currently selected module.
After you click OK, the new module is added to the selection menu.
5
The YaST modules for group and user administration embed templates with sensible
standard values. To edit a template associated with a conguration module, proceed
as follows:
In the Module Conguration dialog, click Congure Template.
1
Determine the values of the general attributes assigned to this template according
2
to your needs or leave some of them empty. Empty attributes are deleted on the
LDAP server.
Modify, delete, or add new default values for new objects (user or group con-
3
guration objects in the LDAP tree).
40 Security Guide
Figure 4.5
YaST: Conguration of an Object Template
Connect the template to its module by setting the susedefaulttemplate attribute
value of the module to the DN of the adapted template.
TIP
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, cn=%sn %givenName is created automatically from the attribute
values for sn and givenName.
Once all modules and templates are congured correctly and ready to run, new groups
and users can be registered in the usual way with YaST.
LDAP—A Directory Service 41
4.4 Conguring LDAP Users and
Groups in YaST
The actual registration of user and group data differs only slightly from the procedure
when not using LDAP. The following brief instructions relate to the administration of
users. The procedure for administering groups is analogous.
Access the YaST user administration with Security and Users > User and Group
1
Management.
Use Set Filter to limit the view of users to the LDAP users and enter the password
2
for Root DN.
Click Add and enter the conguration of a new user. A dialog with four tabs
3
opens:
Specify username, login, and password in the User Data tab.
3a
Check the Details tab for the group membership, login shell, and home di-
3b
rectory 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 dened with the procedure described in Section 4.3.2, “Conguring
the YaST Group and User Administration Modules” (page 38).
3c
3d
Click OK to apply your settings and leave the user conguration.
4
42 Security Guide
Modify or accept the default Password Settings.
Enter the Plug-Ins tab, select the LDAP plug-in, and click Launch to congure additional LDAP attributes assigned to the new user (see Figure 4.6,
“YaST: Additional LDAP Settings” (page 43)).
Figure 4.6
YaST: Additional LDAP Settings
The initial input form of user administration offers LDAP Options. This gives the possibility to apply LDAP search lters to the set of available users or go to the module
for the conguration of LDAP users and groups by selecting LDAP User and Group
Conguration.
LDAP—A Directory Service 43
4.5 Browsing the LDAP Directory Tree
To browse the LDAP directory tree and all its entries conveniently, use the YaST LDAP
Browser:
1
Log in as root.
Start YaST > Network Services > LDAP Browser.
2
Enter the address of the LDAP server, the Administrator DN, and the password
3
for the Root DN of this server if you need both, to read and write the data stored
on the server.
Alternatively, choose Anonymous Access and do not provide the password to
gain read access to the directory.
The LDAP Tree tab displays the content of the LDAP directory to which your
machine connected. Click items to unfold their subitems.
Figure 4.7
To view any entry in detail, select it in the LDAP Tree view and open the Entry
4
Data tab.
All attributes and values associated with this entry are displayed.
44 Security Guide
Browsing the LDAP Directory Tree
Figure 4.8
To change the value of any of these attributes, select the attribute, click Edit,
5
enter the new value, click Save, and provide the Root DN password when
prompted.
Leave the LDAP browser with Close.
6
Browsing the Entry Data
4.6 For More Information
More complex subjects, like SASL conguration or establishment of a replicating
LDAP server that distributes the workload among multiple slaves, were intentionally
not included in this chapter. Detailed information about both subjects can be found in
the OpenLDAP 2.4 Administrator's Guide—see at OpenLDAP 2.4 Administrator's
Guide (page 46).
The Web site of the OpenLDAP project offers exhaustive documentation for beginning
and advanced LDAP users:
OpenLDAP Faq-O-Matic
A very rich question and answer collection concerning installation, conguration,
and use of OpenLDAP. Find it at http://www.openldap.org/faq/data/
cache/1.html.
LDAP—A Directory Service 45
Quick Start Guide
Brief step-by-step instructions for installing your rst LDAP server. Find it at
http://www.openldap.org/doc/admin24/quickstart.html or on
an installed system in /usr/share/doc/packages/openldap2/
admin-guide/quickstart.html.
OpenLDAP 2.4 Administrator's Guide
A detailed introduction to all important aspects of LDAP conguration, including
access controls and encryption. See http://www.openldap.org/doc/
admin24/ or, on an installed system, /usr/share/doc/packages/
openldap2/admin-guide/index.html.
Understanding LDAP
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 is the corresponding RFCs
(request for comments), 2251 to 2256.
46 Security Guide
Active Directory Support
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 any of them, and enforces policies. SUSE® Linux Enterprise Desktop lets
you join existing AD domains and integrate your Linux machine into a Windows environment.
5.1 Integrating Linux and AD Environments
With a Linux client congured as an Active Directory client that is joined to an existing
Active Directory domain, benet from various features not available on a pure SUSE
Linux Enterprise Desktop Linux client:
Browsing Shared Files and Folders with SMB
Both Nautilus, the GNOME le manager, and Konqueror, its KDE counterpart,
support browsing shared resources through SMB.
Sharing Files and Folders with SMB
Both Nautilus, the GNOME le manager, and Konqueror, its KDE counterpart,
support sharing folders and les as in Windows.
5
Active Directory Support 47
Accessing and Manipulating User Data on the Windows Server
Through Nautilus and Konqueror, users are able to access their Windows user data
and can edit, create, and delete les and folders on the Windows server. Users can
access their data without having to enter their password again and again.
Ofine Authentication
Users are able to log in and access their local data on the Linux machine even if
they are ofine (for example, using a laptop) or the AD server is unavailable for
other reasons.
Windows Password Change
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.
Single-Sign-On through Kerberized Applications
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.
For directions for le and printer sharing, refer to the GNOME User Guide (↑GNOME
User Guide) and the KDE User Guide (↑KDE User Guide), where you can learn more
about AD enablement in the GNOME and KDE application worlds.
5.2 Background Information for Linux
Many system components need to interact awlessly to integrate a Linux client into an
existing Windows Active Directory domain. Figure 5.1, “Active Directory Authentication
Schema” (page 49) highlights the most prominent ones. The following sections focus
on the underlying processes of the key events in AD server and client interaction.
48 Security Guide
AD Support
Figure 5.1
(gdm, kdm, login)
PAM aware applications
apps
kerberized
nss_compat nss_winbind
nscd
Kerberos
Credential
Cache
NSS
PAM
Offline Cache winbindd
Windows DC
(Active Directory)
Kerberos
and various MS protocols
LDAP, Kerberos
pam_winbind
pam_mkhomedir
pam_unix2
Active Directory Authentication Schema
To communicate with the directory service, the client needs to share at least two protocols with the server:
LDAP
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
(page 29).
Active Directory Support 49
Kerberos
Kerberos is a third-party trusted authentication service. All its clients trust Kerberos's
judgment 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 (page 61).
The following client components process account and authentication data:
Winbind
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 (Name Service Switch)
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.
PAM (Pluggable Authentication Modules)
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
(page 17).
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 le 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.
5.2.1 Domain Join
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 that can be run during installation
or in the installed system:
50 Security Guide
The Windows domain controller providing both LDAP and KDC (Key Distribu-
1
tion Center) services is located.
A machine account for the joining client is created in the directory service.
2
An initial ticket granting ticket (TGT) is obtained for the client and stored in its
3
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 congurations are adjusted to enable the client to authenticate
4
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.
5.2.2 Domain Login and User Homes
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 Sec-
tion 5.2, “Background Information for Linux AD Support” (page 48). 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 directly 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.
Active Directory Support 51
Account disabled
The user sees an error message stating that his account has been disabled and that
he should contact the system administrator.
Account locked out
The user sees an error message stating that his account has been locked and that
he should 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 login again.
Invalid workstation
When a user is just allowed to log in from specic workstations and the current
SUSE Linux Enterprise Desktop machine is not in that list, 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 shows that login is not possible at this point in
time.
Account expired
An administrator can set an expiration time for a specic user account. If that user
tries to log in after that time has passed, 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 takes care of renewing the TGT in the background, not requiring any user
interaction.
52 Security Guide
SUSE Linux Enterprise Desktop supports local home directories for AD users. If congured through YaST as described in Section 5.3, “Conguring a Linux Client for
Active Directory” (page 54), user homes are created at the rst 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, if the Linux client has been congured to
perform ofine authentication.
5.2.3 Ofine Service and Policy Support
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 ofine state. It
tracks the number of failed login attempts and reacts according to the policies congured
in Active Directory. Ofine support is disabled by default and must be explicitly enabled
in the YaST Domain Membership module.
As in Windows, 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. 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 attaches to the corporate network
again later, SUSE Linux Enterprise Desktop acquires a new Kerberos ticket as soon as
the user has locked and unlocked the desktop (for example, using a desktop screen
saver).
Active Directory Support 53
5.3 Conguring a Linux Client for
Active Directory
Before your client can join an AD domain, some adjustments must be made to your
network setup to ensure a awless interaction of client and server.
DNS
Congure your client machine to use a DNS server that can forward DNS requests
to the AD DNS server. Alternatively, congure your machine to use the AD DNS
server as the name service data source.
NTP
To succeed with Kerberos authentication, the client must have have its time set
accurately. It is highly encouraged 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 clockskew between your Linux host and the domain controller exceeds
a certain limit, Kerberos authentication fails and the client is logged in only using
the weaker NTLM (NT LAN Manager) authentication. For more details about using
active directory for time synchronization, see Joining an AD Domain (page 55).
DHCP
If your client uses dynamic network conguration with DHCP, congure DHCP
to provide the same IP and hostname to the client. If possible, use static IP addresses
to be on the safe side.
Firewall
To browse your network neighborhood, either disable the rewall entirely or mark
the interface used for browsing as part of the internal zone.
To change the rewall settings on your client, log in as root and start the YaST
rewall module. Select Interfaces. Select your network interface from the list of
interfaces and click Change. Select Internal Zone and apply your settings with OK.
Leave the rewall settings with Next > Accept. To disable the rewall, just set
Service Start to Manually and leave the rewall module with Next > Accept.
AD Account
You cannot log in to an AD domain unless the AD administrator has provided you
with a valid user account for this domain. Use the AD username and password to
log in to the AD domain from your Linux client.
54 Security Guide
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 “Create New User” (Chapter 3, Installation with YaST, ↑Deployment Guide).
NOTE
Currently only a domain administrator account, such as Administrator, can
join SUSE Linux Enterprise Desktop into Active Directory.
To join an AD domain in a running system, proceed as follows:
Procedure 5.1
1
Log in as root and start YaST.
Start Network Services > Windows Domain Membership.
2
Enter the domain to join at Domain or Workgroup in the Windows Domain
3
Membership screen (see Figure 5.2, “Determining Windows Domain Member-
ship” (page 56)). 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 nd the correct domain controller.
To select from a list of available domains instead, use Browse to list the NetBIOS domains then select the desired domain.
Joining an AD Domain
Active Directory Support 55
Figure 5.2
Check Also Use SMB Information for Linux Authentication to use the SMB
4
source for Linux authentication.
Check Create Home Directory on Login to automatically create a local home
5
directory for your AD user on the Linux machine.
Determining Windows Domain Membership
6
7
8
9
56 Security Guide
Check Ofine Authentication to allow your domain users to log in even if the
AD server is temporarily unavailable or you do not have a network connection.
Select Expert Settings, 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.
Congure NTP time synchronization for your AD environment by selecting
NTP Conguration and entering an appropriate server name or IP address.
This step is obsolete if you have already entered the appropriate settings in
the standalone YaST NTP conguration module.
Click Finish and conrm the domain join when prompted for it.
Provide the password for the Windows administrator on the AD server and
10
click OK (see Figure 5.3, “Providing Administrator Credentials” (page 57)).
Figure 5.3
After 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.
Providing Administrator Credentials
5.4 Logging In to an AD Domain
Provided your machine has been congured 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.
IMPORTANT: Ofine Authentication
SUSE Linux Enterprise Desktop supports ofine authentication, allowing you
to remain logged in to your client machine even if the client machine is disconnected from the network. This enables you to maintain a mobile style of
working, for example, it allows you to continue to work even if you are on an
airplane and do not have a network connection.
Active Directory Support 57
5.4.1 GDM and KDM
To authenticate a GNOME client machine against an AD server, proceed as follows:
Select the domain.
1
Enter your Windows username and press Enter.
2
Enter your Windows password and press Enter.
3
To authenticate a KDE client machine against an AD server, proceed as follows:
Select the domain.
1
Enter your Windows username.
2
Enter your Windows password and press Enter.
3
If congured to do so, SUSE Linux Enterprise Desktop creates a user home directory
on the local machine on the rst login of each AD authenticated user. This allows you
to benet from the AD support of SUSE Linux Enterprise Desktop while still having
a completely capable Linux machine at your disposal.
5.4.2 Console Login
As well as logging in to 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 DOMAIN\user at the 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:
1
ssh DOMAIN\\user@hostname
The \ domain and login delimiter is escaped with another \ sign.
Provide the user's password.
2
58 Security Guide
5.5 Changing Passwords
SUSE Linux Enterprise Desktop 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. It informs about the
specic password quality requirements a user account typically has by means of a
message at login time. Like the Windows counterpart, SUSE Linux Enterprise Desktop
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 satised. Feedback about the password status is given both through the display
managers and the console.
GDM and KDM provide feedback about password expiration and prompt for new
passwords in an interactive mode. To change passwords in the display managers, just
provide the password information when prompted to do so.
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.
1
2
Enter passwd.
Enter your current password when prompted to do so.
3
Enter the new password.
4
Reenter the new password for conrmation. If your new password does not
5
comply with the policies on the Windows server, this feedback is given to you
and you are prompted for another password.
Active Directory Support 59
To change your Windows password from the GNOME desktop, proceed as follows:
Click the Computer icon on the left edge of the panel.
1
Select Control Center.
2
From the Personal section, select Change Password.
3
Enter your old password.
4
Enter and conrm the new password.
5
Leave the dialog with Close to apply your settings.
6
To change your Windows password from the KDE desktop, proceed as follows:
Select Personal Settings from the main menu.
1
Select Security & Privacy.
2
Click Password & User Account.
3
Click Change Password.
4
Enter your current password.
5
Enter and conrm the new password and apply your settings with OK.
6
Leave the Personal Settings with File > Quit.
7
60 Security Guide
Network Authentication with Kerberos
An open network provides no means to ensure that a workstation can identify its users
properly except 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 once then 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. The following shows how this is achieved. Only the basic principles of Kerberos
are discussed here. For detailed technical instruction, refer to the documentation provided
with your implementation of Kerberos.
6
Network Authentication with Kerberos 61
6.1 Kerberos Terminology
The following glossary denes some Kerberos terminology.
credential
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.
ticket
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.
authenticator
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 of the client's
name, the workstation's IP address, and the current workstation's time all encrypted
with the session key only known to the client and the server from which it is requesting a service. An authenticator can only be used once, unlike a ticket. A client
can build an authenticator itself.
principal
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 rst 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 species your Kerberos realm. Normally, your realm is your domain
name in uppercase letters.
mutual authentication
Kerberos ensures that both client and server can be sure of each others identity.
They share a session key, which they can use to communicate securely.
62 Security Guide
session key
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.
replay
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. He could then
try to resend it (replay) to impersonate you. However, Kerberos implements several
mechanisms to deal with that problem.
server or service
Service is used to refer to a specic action to perform. The process behind this action
is referred to as a server.
6.2 How Kerberos Works
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 worth all the trust put in it, run both the authentication and ticketgranting server on a dedicated machine. Make sure that only the administrator can access
this machine physically and over the network. Reduce the (networking) services run
on it to the absolute minimum—do not even run sshd.
6.2.1 First Contact
Your rst 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 about your existence, 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 ticketgranting server know:
Network Authentication with Kerberos 63
• The names both of 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.
6.2.2 Requesting a Service
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 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.
64 Security Guide
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.
6.2.3 Mutual Authentication
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.
6.2.4 Ticket Granting—Contacting All
Servers
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 just 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 ticketgranting 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:
Network Authentication with Kerberos 65
• The client's principal
• The server's principal
• The current time
• The client's IP address
• The newly-generated session key
The new ticket is assigned a lifetime, which is the lesser of the remaining lifetime of
the ticket-granting ticket and the default for the service. 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 more than once at login time.
6.2.5 Compatibility to Windows 2000
Windows 2000 contains a Microsoft implementation of Kerberos 5. Because SUSE®
Linux Enterprise Desktop uses the MIT implementation of Kerberos 5, nd useful information and guidance in the MIT documentation. See Section 6.4, “For More Infor-
mation” (page 67).
6.3 Users' View of Kerberos
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 difcult 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.
66 Security Guide
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
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
sufcient because the ticket contains workstation-specic 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.
6.4 For More Information
The ofcial site of the MIT Kerberos is http://web.mit.edu/kerberos. There,
nd 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 difcult to read. It also provides a lot of opportunities for further investigation and
reading about Kerberos.
The ofcial Kerberos FAQ is available at http://www.nrl.navy.mil/CCS/
people/kenh/kerberos-faq.html. The book Kerberos—A Network Authenti-
cation System by Brian Tung (ISBN 0-201-37924-4) offers extensive information.
Network Authentication with Kerberos 67
Using the Fingerprint Reader
If your system includes a ngerprint reader, you can use biometric authentication in
addition to standard authentication via login and password. After registering their ngerprint, users can log in to the system either by swiping a nger on the ngerprint
reader or by typing in a password. SUSE® Linux Enterprise Desktop supports most
available ngerprint readers. For a list of supported devices, please refer to http://
reactivated.net/fprint/wiki/Supported_devices.
If the hardware check detects the ngerprint 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 ngerprint per user can be registered. The user's ngerprint data
is stored to /home/login/.fprint/.
7.1 Supported Applications and
Actions
The PAM module pam_fp supports ngerprint authentication for the following applications and actions (although you may not be prompted to swipe your nger in all
cases):
7
• Logging in to GDM/KDM or a login shell
• Unlocking your screen on the GNOME/KDE desktop
Using the Fingerprint Reader 69
• 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
NOTE: Fingerprint Reader Devices and Encrypted Home Directories
If you want to use a ngerprint reader device, you must not use encrypted
home directories (see Chapter 9, 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 ngerprint reader
device.
7.2 Managing Fingerprints with YaST
Procedure 7.1
You can only use biometric authentication if PAM is congured accordingly. Usually,
this is done automatically during installation of the packages when the hardware check
detects a supported ngerprint reader. If not, manually enable the ngerprint support
in YaST as follows:
Start YaST and select Hardware > Fingerprint Reader.
1
In the conguration dialog, activate Use Fingerprint Reader and click Finish to
2
save the changes and close the dialog.
Now you can register a ngerprint for various users.
Procedure 7.2
In YaST, click Security and Users > User Management to open the User and
1
Group Administration dialog. A list of users or groups in the system is displayed.
Select the user for whom you want to register a ngerprint and click Edit.
2
On the Plug-Ins tab, select the ngerprint entry and click Launch to open the
3
Fingerprint Conguration dialog.
Enabling Fingerprint Authentication
Registering a Fingerprint
70 Security Guide
YaST prompts the user to swipe his nger until three readable ngerprints have
4
been gathered.
After the ngerprint has been acquired successfully, click Accept to close the
5
Fingerprint Conguration dialog and the dialog for the user.
If you also want to use ngerprint authentication for starting YaST or the YaST
6
modules, you need to register a ngerprint for root, too.
To do so, set the lter in the User and Group Administration dialog to System
Users, select the root entry and register a ngerprint for root as described
above.
After you have registered ngerprints for the desired users, click Finish to close
7
the administration dialog and to save the changes.
As soon as the user's ngerprint has been successfully registered, the user can choose
to authenticate with either ngerprint or password for the actions and applications listed
in Section 7.1, “Supported Applications and Actions” (page 69).
Currently, YaST does not offer verication or removal of ngerprints, but you remove
ngerprints by deleting the directory /home/login/.fprint.
For more technical details, refer to http://reactivated.net/fprint/.
Using the Fingerprint Reader 71
Part II. Local Security
Conguring Security Settings
with YaST
The YaST module Local Security offers a central clearinghouse to congure securityrelated settings for SUSE Linux Enterprise Desktop. Use it to congure security aspects
such as settings for the login procedure and for password creation, for boot permissions,
user creation or for default le permissions. Launch it from the YaST Control Center
by Security and Users > Local Security. The Local Security dialog always starts with
the Security Overview, and other conguration dialogs are available from the right pane.
8.1 Security Overview
The Security Overview 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 Help 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:
Enable/Disable
Clicking on this entry will toggle the status of the setting to either enabled or disabled.
8
Congure
Clicking on this entry will launch another YaST module for conguration. You
will return to the Security Overview when leaving the module.
Conguring Security Settings with YaST 75
Unknown
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.
Figure 8.1
YaST Local Security - Security Overview
8.2 Predened Security Congurations
SUSE Linux Enterprise Desktop comes with three predened sets of security congurations. These congurations affect all the settings available in the Local Security
module. Each conguration can be modied to your needs using the dialogs available
from the right pane. Choose between the following sets:
Home Workstation
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 conguration of
the predened settings.
Networked Workstation
A conguration for a workstation with any kind of network connection (including
a connection to the Internet).
76 Security Guide
Network Server
Security settings designed for a machine providing network services such as a web
server, le server, name server, etc. This set provides the most secure conguration
of the predened settings.
Custom Settings
A pre-selected Custom Settings (when opening the Predened Security Congurations dialog) indicates that one of the predened sets has been modied. Actively
choosing this option does not change the current conguration - you will have to
change it using the Security Overview.
8.3 Password Settings
Passwords that are easy to guess are a major security issue. The Password Settings dialog
provides the means to ensure that only secure passwords can be used.
Check New Passwords
By activating this option, a warning will be issued if new passwords appear in a
dictionary, or if they are proper names (proper nouns).
Test for Complicated Passwords
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.
Number of Passwords to Remember
When password expiration is activated, this setting stores the given number of a
user's previous passwords, preventing their reuse.
Password Encryption Method
Choose a password encryption algorithm. Normally there is no need to change the
default (Blowsh).
Minimum Acceptable Password Length
If the user chooses a password with a length shorter than specied here, a warning
will be issued.
Conguring Security Settings with YaST 77
Password Age
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 pre-
vent 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.
Days Before Password Expires Warning
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.
8.4 Boot Settings
Congure 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.
8.5 Login Settings
This dialog lets you congure security-related login settings:
Delay after Incorrect Login Attempt
In order to make it difcult 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.
Record Successful Login Attempts
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
Please note that logging to /var/log/wtmp is not affected by this option.
This le collects login dates, login times and reboot dates. The content of
/var/log/wtmp can be displayed by using the command last.
78 Security Guide
Allow Remote Graphical Login
When checked, the graphical login manager (e.g. gdm or kdm) can be accessed
from the network. This is a potential security risk.
8.6 User Addition
Set minimum and maximum values for user and group IDs. These default settings would
rarely need to be changed.
8.7 Miscellaneous Settings
Other security settings that don't t the above-mentioned categories are listed here:
File Permissions
SUSE Linux Enterprise Desktop comes with three predened sets of le permissions
for system les. These permission sets dene whether a regular user may read log
les or start certain programs. Easy le permissions are suitable for standalone
machines. This settings allows regular users, for example, to read most system
les. See the le /etc/permissions.easy for the complete conguration.
The Secure le permissions are designed for multi-user machines with network
access. A thorough explanation of these settings can be found in /etc/
permissions.secure. The Paranoid settings are the most restrictive ones
and should be used with care. See /etc/permissions.secure for more in-
formation.
User Launching updatedb
The program updatedb scans the system and creates a database of all le locations
which can be queried with the command locate. When updatedb is run as
user nobody, only world-readable les will be added to the database. When run as
user root, almost all les (except the ones root is not allowed to read) will be
added.
Conguring Security Settings with YaST 79
Current Directory in root's Path / Current Directory in Path of Regular Users
Whenever a program is called without specifying the full path to the executable,
the system looks in the user's search path (dened 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 /current
directory/ls is executed when entering ls. In order to start a program in the
current directory the command must be prexed with ./. When activating these
options, the current directory (.) is appended to the search path. It is recommended
you not change the default.
Enable Magic SysRq Keys
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 package kernel-source).
80 Security Guide
PolicyKit
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
conguration—specied 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.
9.1 Available Policies and Supported
Applications
At the moment, not all applications requiring privileges make use of PolicyKit. In the
following the most important policies available on SUSE® Linux Enterprise Desktop
are listed.
PulseAudio
Set scheduling priorities for the PulseAudio daemon
9
smppd
Control dial connections
PolicyKit 81
CUPS
Add, remove, edit, enable or disable printers
Backup Manager
Modify schedule
GNOME
Modify system and mandatory values with GConf
Change the system time
PolicyKit
Read and change privileges for other users
Modify defaults
PackageKit
Update and remove packages
Refresh repositories
System
Wake on LAN
Mount or unmount xed, hotplugable and encrypted devices
Enable or disable WLAN
Enable or disable Bluetooth
Device access
Stop and restart the system
9.2 Authorization Types
Every time a PolicyKit-enabled process carries out a privileged operation, PolicyKit is
asked whether this process is entitled to do so. The answer PolicyKit gives depends on
the policy dened for this process. It 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 specic user.
82 Security Guide
9.2.1 Implicit Privileges
Implicit privileges can be dened 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:
Authentication
The user always has to authenticate
One Shot Authentication
The authentication is bound to the instance of the program currently running. Once
the program is restarted, the user is required to authenticate again.
Keep Session Authentication
The authentication dialog box offers a check button Remember authorization for
this session. If checked, the authentication is valid until the user logs out.
Keep Indenitely Authentication
The authentication dialog box offers a check button Remember authorization. If
checked, the user has to authenticate only once.
9.2.2 Explicit Privileges
Explicit privileges can be granted to specic 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.
PolicyKit 83
9.3 Modifying and Setting Privileges
To modify implicit privileges or to set explicit ones, you can either use the graphical
Authorizations tool available with GNOME, use the command line tools shipped with
PolicyKit, or modify the conguration les. While the GUI and the command line tools
are a good solution for making temporary changes, editing the conguration les should
be the preferred way to make permanent changes.
9.3.1 Using the Graphical Authorizations
Tool
Start the Authorizations tool either via the GNOME main menu by selecting More Applications > Tools > Authorizations or by pressing Alt + F2 and entering
polkit-gnome-authorization.
TIP: Using the Authorizations tool in non-GNOME environments
Authorizations is a GNOME tool and therefore not installed when the GNOME
desktop environment is not installed. In this case you need to install the package
PolicyKit-gnome in order to use the tool.
84 Security Guide
Figure 9.1
The Authorizations Tool
The Authorizations window is divided into two parts. The left side shows all policies
available in a tree view, while the right side displays details for the policy selected and
offers means to change it.
Action
Lists details of the chosen policy. The Identier is the unique string used by PolicyKit to identify the policy. Description explains the purpose of the policy and
Vendor displays a link to the organization that has issued this policy.
Implicit Authorizations
Change the privileges by clicking Edit and choosing an authorization type explained
in Section 9.2.1, “Implicit Privileges” (page 83). Click Revert To Defaults to restore
the system defaults.
PolicyKit 85
Explicit Authorizations
In this section you can Grant privileges to existing users or Block users. In both
cases, choose a user and a Constraint. Users with a UID of less than 1000 are only
shown when Show System Users is checked. To delete an authorization, choose it
from the list and click Revoke.
NOTE: Restrictions of the Revert to Defaults function on SUSE Linux
Enterprise Desktop
When using Revert to Defaults, the Authorization tool always operates on the
upstream defaults, so it is not possible to list or restore the defaults shipped
with SUSE Linux Enterprise Desktop. Refer to Section 9.3.4, “Restoring the De-
fault Privileges” (page 90) for further information.
9.3.2 Using the Command Line Tools
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 identied and which is used with the command line tools. List all
available policies with the command polkit-action.
polkit-action
List and modify implicit privileges. Using this command you can also reset all
policies to the default value. When invoked with no parameters, The command
polkit-action shows a list of all policies. See man 1 polkit-action
for more information.
polkit-auth
Inspect, grant, block and revoke explicit privileges. To print a list of explicit privileges for a specic user, use the command polkit-auth
--explicit-detail --user USER where USER has to be replaced by a
valid username. If the --user option is left out, privileges for the user executing
the command are shown. See man 1 polkit-auth for more information.
NOTE: Restrictions of polkit-action on SUSE Linux Enterprise Desktop
Using the option --show-overrides, polkit-action lists all policies that
differ from the default values. With --reset-defaults action one can
86 Security Guide
reset the privileges for a given action to the defaults. However,
polkit-action always operates on the upstream defaults, so it is not possible
to list or restore the defaults shipped with SUSE Linux Enterprise Desktop. Refer
to Section 9.3.4, “Restoring the Default Privileges” (page 90) for further information.
9.3.3 Modifying Conguration Files
Adjusting privileges by modifying conguration les is useful when you want to deploy
the same set of policies to different machines, for example to the computers of a specic
team. It is possible to change implicit as well as explicit privileges by modifying conguration les.
Modifying Conguration Files for Implicit Privileges
SUSE Linux Enterprise Desktop ships with two sets of default authorizations located
in /etc/polkit-default-privs.standard and /etc/
polkit-default-privs.restrictive. The .standard le denes privileges
suitable for most desktop systems. It is active by default. The .restrictive set of
privileges is designed for machines administrated centrally.Activate it by setting
POLKIT_DEFAULT_PRIVS to restrictive in /etc/sysconfig/security
and run set_polkit_default_privs as root afterwards. Do not modify these
two les.
In order to dene your custom set of privileges, use /etc/polkit-default-privs
.local. Privileges dened here will always take precedence over the ones dened in
the other conguration les. To dene a privilege, add a line for each policy with the
following format:
<privilege
name> <any
session>:<inactive
session>:<active
session>
For a list of all privilege names available, run the command polkit-action. The
following values are valid for the session parameters:
PolicyKit 87
yes
grant privilege
no
block
auth_self
user needs to authenticate with own password every time the privilege is requested
auth_self_keep_session
user needs to authenticate with own password once per session, privilege is granted
for the whole session
auth_self_keep_always
user needs to authenticate with own password once, privilege is granted for the
current and for future sessions
auth_admin
user needs to authenticate with root password every time the privilege is requested
auth_admin_keep_session
user needs to authenticate with root password once per session, privilege is
granted for the whole session
auth_admin_keep_always
user needs to authenticate with root password once, privilege is granted for the
current and for future sessions
Run set_polkit_default_privs to activate your settings.
Modifying Conguration Files for Explicit Privileges
Explicit privileges can be set in /etc/PolicyKit/PolicyKit.conf. This conguration le is written in XML using the PolicyKit DTD. The le that is shipped with
SUSE Linux Enterprise Desktop already contains the necessary headers and the root
element <config>. Place your edits inside the <config> tags.
88 Security Guide
Loading...