Novell LINUX ENTERPRISE DESKTOP 11 - ADMINISTRATION GUIDE... User manual

SUSE Linux Enterprise
Desktop
www.novell.com11
March17,2009 Security Guide

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 ful-
lled:
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, specically 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
1Security and Condentiality 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
2Authentication with PAM 17
2.1 Structure of a PAM Conguration File . . . . . . . . . . . . . . . . 18
2.2 The PAM Conguration of sshd . . . . . . . . . . . . . . . . . . . 20
2.3 Conguration of PAM Modules . . . . . . . . . . . . . . . . . . . 22
2.4 Conguring PAM Using pam-cong . . . . . . . . . . . . . . . . . 24
2.5 For More Information . . . . . . . . . . . . . . . . . . . . . . . 26
3Using NIS 27
3.1 Conguring NIS Clients . . . . . . . . . . . . . . . . . . . . . . 27
4LDAP—A Directory Service 29
4.1 LDAPversusNIS......................... 30
4.2 Structure of an LDAP Directory Tree . . . . . . . . . . . . . . . . . 31
4.3 Conguring an LDAP Client with YaST . . . . . . . . . . . . . . . . 34
4.4 Conguring LDAP Users and Groups in YaST . . . . . . . . . . . . . . 42
4.5 Browsing the LDAP Directory Tree . . . . . . . . . . . . . . . . . . 44
4.6 For More Information . . . . . . . . . . . . . . . . . . . . . . . 45

5Active Directory Support 47
5.1 Integrating Linux and AD Environments . . . . . . . . . . . . . . . . 47
5.2 Background Information for Linux AD Support . . . . . . . . . . . . 48
5.3 Conguring a Linux Client for Active Directory . . . . . . . . . . . . 54
5.4 Logging In to an AD Domain . . . . . . . . . . . . . . . . . . . . 57
5.5 Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . 59
6Network 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
7Using the Fingerprint Reader 69
7.1 Supported Applications and Actions . . . . . . . . . . . . . . . . . 69
7.2 Managing Fingerprints with YaST . . . . . . . . . . . . . . . . . . 70
Part II Local Security 73
8Conguring Security Settings with YaST 75
8.1 Security Overview ......................... 75
8.2 Predened Security Congurations ................. 76
8.3 Password Settings ........................ 77
8.4 BootSettings........................... 78
8.5 LoginSettings.......................... 78
8.6 UserAddition.......................... 79
8.7 Miscellaneous Settings . . . . . . . . . . . . . . . . . . . . . . . 79
9PolicyKit 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 Denitions............................ 95
10.4 HandlingACLs.......................... 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 Certicate Store 113
12.1 Activating Certicate Store . . . . . . . . . . . . . . . . . . . . 113
12.2 Importing Certicates . . . . . . . . . . . . . . . . . . . . . . 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 ThesshProgram......................... 124
14.3 scp—SecureCopy........................ 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 Conguring 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 SuSErewall2.......................... 136
15.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 141
16 Conguring VPN Server 143
16.1 Overview............................ 143

16.2 Creating the Simplest VPN Example . . . . . . . . . . . . . . . . . 147
16.3 Setting Up Your VPN Server Using Certicate Authority . . . . . . . . 149
16.4 KDE- and GNOME Applets For Clients . . . . . . . . . . . . . . . . 155
16.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 157
17 Managing X.509 Certication 159
17.1 The Principles of Digital Certication . . . . . . . . . . . . . . . . 159
17.2 YaST Modules for CA Management . . . . . . . . . . . . . . . . . 163
Part IV Conning Privileges with Novell AppArmor 175
18 Introducing AppArmor 177
18.1 Background Information on AppArmor Proling . . . . . . . . . . . 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 Prole . . . . . . . . . . . . . . . . 181
19.4 Building and Modifying Proles . . . . . . . . . . . . . . . . . . 182
19.5 Conguring Novell AppArmor Event Notication and Reports . . . . . 184
19.6 Updating Your Proles . . . . . . . . . . . . . . . . . . . . . . 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 Prole Components and Syntax 197
21.1 Breaking a Novell AppArmor Prole into Its Parts . . . . . . . . . . . 198
21.2 ProleTypes.......................... 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 ExecuteModes......................... 212
21.9 Resource Limit Control . . . . . . . . . . . . . . . . . . . . . . 217
21.10AuditingRules.......................... 218

21.11 Setting Capabilities per Prole . . . . . . . . . . . . . . . . . . . 219
22 AppArmor Prole Repositories 221
22.1 Using the Local Repository . . . . . . . . . . . . . . . . . . . . 221
22.2 Using the External Repository . . . . . . . . . . . . . . . . . . . 222
23 Building and Managing Proles with YaST 225
23.1 Adding a Prole Using the Wizard . . . . . . . . . . . . . . . . . 227
23.2 Manually Adding a Prole . . . . . . . . . . . . . . . . . . . . . 235
23.3 EditingProles ......................... 235
23.4 Deleting a Prole . . . . . . . . . . . . . . . . . . . . . . . . 241
23.5 Updating Proles from Log Entries . . . . . . . . . . . . . . . . . 241
23.6 Managing Novell AppArmor and Security Event Status . . . . . . . . . 243
24 Building Proles from the Command Line 247
24.1 Checking the AppArmor Module Status . . . . . . . . . . . . . . . 247
24.2 Building AppArmor Proles . . . . . . . . . . . . . . . . . . . . 249
24.3 Adding or Creating an AppArmor Prole . . . . . . . . . . . . . . 250
24.4 Editing an AppArmor Prole . . . . . . . . . . . . . . . . . . . . 250
24.5 Deleting an AppArmor Prole . . . . . . . . . . . . . . . . . . . 250
24.6 Two Methods of Proling . . . . . . . . . . . . . . . . . . . . . 251
24.7 Important Filenames and Directories . . . . . . . . . . . . . . . . 272
25 Proling Your Web Applications Using ChangeHat 275
25.1 Apache ChangeHat . . . . . . . . . . . . . . . . . . . . . . . . 276
25.2 Conguring Apache for mod_apparmor . . . . . . . . . . . . . . . 282
26 Conning Users with pam_apparmor 287
27 Managing Proled Applications 289
27.1 Monitoring Your Secured Applications . . . . . . . . . . . . . . . 289
27.2 Conguring Security Event Notication . . . . . . . . . . . . . . . 290
27.3 Conguring Reports . . . . . . . . . . . . . . . . . . . . . . . 293
27.4 Conguring and Using the AppArmor Desktop Monitor Applet . . . . . 313
27.5 Reacting to Security Event Rejections . . . . . . . . . . . . . . . . 314
27.6 Maintaining Your Security Proles . . . . . . . . . . . . . . . . . 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 Conguring 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 Conguring the Audit Daemon . . . . . . . . . . . . . . . . . . . 373
31.3 Enabling Audit for System Calls . . . . . . . . . . . . . . . . . . 374
31.4 Setting Up Audit Rules . . . . . . . . . . . . . . . . . . . . . . 375
31.5 Conguring Audit Reports . . . . . . . . . . . . . . . . . . . . . 377
31.6 Conguring Log Visualization . . . . . . . . . . . . . . . . . . . 380
32 Introducing an Audit Rule Set 383
32.1 Adding Basic Audit Conguration Parameters . . . . . . . . . . . . 384
32.2 Adding Watches on Audit Log Files and Conguration Files . . . . . . . 385
32.3 Monitoring File System Objects . . . . . . . . . . . . . . . . . . 386
32.4 Monitoring Security Conguration 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 documen-
tation available on the Internet.
For an overview of the documentation available for your product and the latest docu-
mentation 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 conguring the desktop and helps you perform key tasks. It is
intended mainly for end users who want to make efcient use of GNOME desktop
as their default desktop.
Application Guide (↑Application Guide)
Learn how to use and congure key desktop applications on SUSE Linux Enterprise
Desktop. This guide introduces browsers and e-mail clients as well as ofce appli-
cations 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 approach-
es, ranging from a local installation or a network installation server to a mass de-
ployment 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 se-
curity 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 informa-
tion 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 efciently 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 congure the auditing system and how
to execute key tasks such as setting up audit rules, generating reports, and analyzing
the log les.
xSecurity 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

1
Security and Condentiality
One of the main characteristics of a Linux or UNIX system is its ability to handle sev-
eral 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 net-
work.
With the multiuser capability, the data of different users must be stored separately. Se-
curity 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 im-
portant 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 condentiality 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.
Security and Condentiality 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 condence 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 tradi-
tional 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 combi-
nations that might provoke unusual behavior. Protect yourself against this by setting
passwords for the BIOS and the boot loader.
2Security 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 secu-
rity 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 Condentiality 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 re-
ally 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 substi-
tutions 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 “beerbud-
dy” or “jasmine76” are easily guessed even by someone who has only some casual
knowledge about you.
1.1.3 The Boot Procedure
Congure your system so it cannot be booted from a oppy or from CD, either by re-
moving the drives entirely or by setting a BIOS password and conguring 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 denitely 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 ex-
actly the permissions of the program when it was started. By following the above rule,
minimize the possible damage.
4Security 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 modied les could be executed by root
or, in the case of conguration les, programs could use such les with the permissions
of root. This signicantly increases the possibilities of an attacker. Attacks like this
are called cuckoo eggs, because the program (the egg) is executed (hatched) by a differ-
ent 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 dene 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 dene which of the above les is used by SUSE Linux Enterprise Desktop's con-
guration 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 Overows 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 appli-
cation than for regular users. The programmer must make sure that his application in-
terprets 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 dened for that purpose.
Abuffer overow 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 Condentiality 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 inuenced 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 overows 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 overows and format string bugs should be classied 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
6Security 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, differen-
tiate 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 Condentiality 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 Overows and Format String
Bugs
As discussed in Section 1.1.5, “Buffer Overows and Format String Bugs” (page 5),
buffer overows and format string bugs should be classied as issues concerning both
local and network security. As with the local variants of such bugs, buffer overows
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 overows 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.
8Security Guide