Novell LINUX ENTERPRISE DESKTOP 11 User manual

SUSE Linux Enterprise
Server
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 xi
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 Servers . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Conguring NIS Clients . . . . . . . . . . . . . . . . . . . . . . 33
4LDAP—A Directory Service 35
4.1 LDAPversusNIS......................... 36
4.2 Structure of an LDAP Directory Tree . . . . . . . . . . . . . . . . . 37
4.3 Conguring an LDAP Server with YaST . . . . . . . . . . . . . . . . 40
4.4 Conguring an LDAP Client with YaST . . . . . . . . . . . . . . . . 49
4.5 Conguring LDAP Users and Groups in YaST . . . . . . . . . . . . . . 57

4.6 Browsing the LDAP Directory Tree . . . . . . . . . . . . . . . . . . 59
4.7 Manually Conguring an LDAP Server . . . . . . . . . . . . . . . . 60
4.8 Manually Administering LDAP Data . . . . . . . . . . . . . . . . . 61
4.9 For More Information . . . . . . . . . . . . . . . . . . . . . . . 65
5Active Directory Support 67
5.1 Integrating Linux and AD Environments . . . . . . . . . . . . . . . . 67
5.2 Background Information for Linux AD Support . . . . . . . . . . . . 68
5.3 Conguring a Linux Client for Active Directory . . . . . . . . . . . . 74
5.4 Logging In to an AD Domain . . . . . . . . . . . . . . . . . . . . 77
5.5 Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . 79
6Network Authentication with Kerberos 81
6.1 Kerberos Terminology . . . . . . . . . . . . . . . . . . . . . . . 82
6.2 How Kerberos Works . . . . . . . . . . . . . . . . . . . . . . . 83
6.3 Users' View of Kerberos . . . . . . . . . . . . . . . . . . . . . . 86
6.4 Installing and Administering Kerberos . . . . . . . . . . . . . . . . 87
6.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 108
7Using the Fingerprint Reader 109
7.1 Supported Applications and Actions . . . . . . . . . . . . . . . . 109
7.2 Managing Fingerprints with YaST . . . . . . . . . . . . . . . . . . 110
Part II Local Security 113
8Conguring Security Settings with YaST 115
8.1 Security Overview . . . . . . . . . . . . . . . . . . . . . . . . 115
8.2 Predened Security Congurations . . . . . . . . . . . . . . . . . 116
8.3 Password Settings . . . . . . . . . . . . . . . . . . . . . . . . 117
8.4 BootSettings.......................... 118
8.5 LoginSettings.......................... 118
8.6 UserAddition.......................... 119
8.7 Miscellaneous Settings . . . . . . . . . . . . . . . . . . . . . . 119
9PolicyKit 121
9.1 Available Policies and Supported Applications . . . . . . . . . . . . 121
9.2 Authorization Types . . . . . . . . . . . . . . . . . . . . . . . 122
9.3 Modifying and Setting Privileges . . . . . . . . . . . . . . . . . . 123

10 Access Control Lists in Linux 131
10.1 Traditional File Permissions . . . . . . . . . . . . . . . . . . . . 131
10.2 Advantages of ACLs . . . . . . . . . . . . . . . . . . . . . . . 133
10.3 Denitions........................... 133
10.4 HandlingACLs.......................... 134
10.5 ACL Support in Applications . . . . . . . . . . . . . . . . . . . . 142
10.6 For More Information . . . . . . . . . . . . . . . . . . . . . . 143
11 Encrypting Partitions and Files 145
11.1 Setting Up an Encrypted File System with YaST . . . . . . . . . . . . 146
11.2 Using Encrypted Home Directories . . . . . . . . . . . . . . . . . 149
11.3 Using vi to Encrypt Single ASCII Text Files . . . . . . . . . . . . . . 150
12 Certicate Store 151
12.1 Activating Certicate Store . . . . . . . . . . . . . . . . . . . . 151
12.2 Importing Certicates . . . . . . . . . . . . . . . . . . . . . . 152
13 Intrusion Detection with AIDE 153
13.1 Setting Up a AIDE Database . . . . . . . . . . . . . . . . . . . . 153
13.2 Local AIDE Checks . . . . . . . . . . . . . . . . . . . . . . . . 156
13.3 System Independent Checking . . . . . . . . . . . . . . . . . . . 157
13.4 For More Information . . . . . . . . . . . . . . . . . . . . . . 158
Part III Network Security 159
14 SSH: Secure Network Operations 161
14.1 The OpenSSH Package . . . . . . . . . . . . . . . . . . . . . . 161
14.2 ThesshProgram......................... 162
14.3 scp—SecureCopy........................ 162
14.4 sftp—Secure File Transfer . . . . . . . . . . . . . . . . . . . . . 163
14.5 The SSH Daemon (sshd)—Server-Side . . . . . . . . . . . . . . . . 163
14.6 SSH Authentication Mechanisms . . . . . . . . . . . . . . . . . . 164
14.7 X, Authentication, and Forwarding Mechanisms . . . . . . . . . . . . 166
14.8 Conguring An SSH Daemon with YaST . . . . . . . . . . . . . . . 167
15 Masquerading and Firewalls 169
15.1 Packet Filtering with iptables . . . . . . . . . . . . . . . . . . . . 169
15.2 Masquerading Basics . . . . . . . . . . . . . . . . . . . . . . . 172
15.3 Firewalling Basics . . . . . . . . . . . . . . . . . . . . . . . . 173

15.4 SuSErewall2.......................... 174
15.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 179
16 Conguring VPN Server 181
16.1 Overview............................ 181
16.2 Creating the Simplest VPN Example . . . . . . . . . . . . . . . . . 185
16.3 Setting Up Your VPN Server Using Certicate Authority . . . . . . . . 187
16.4 KDE- and GNOME Applets For Clients . . . . . . . . . . . . . . . . 193
16.5 For More Information . . . . . . . . . . . . . . . . . . . . . . 195
17 Managing X.509 Certication 197
17.1 The Principles of Digital Certication . . . . . . . . . . . . . . . . 197
17.2 YaST Modules for CA Management . . . . . . . . . . . . . . . . . 202
Part IV Conning Privileges with Novell AppArmor 215
18 Introducing AppArmor 217
18.1 Background Information on AppArmor Proling . . . . . . . . . . . 218
19 Getting Started 219
19.1 Installing Novell AppArmor . . . . . . . . . . . . . . . . . . . . 220
19.2 Enabling and Disabling Novell AppArmor . . . . . . . . . . . . . . 220
19.3 Choosing the Applications to Prole . . . . . . . . . . . . . . . . 221
19.4 Building and Modifying Proles . . . . . . . . . . . . . . . . . . 222
19.5 Conguring Novell AppArmor Event Notication and Reports . . . . . 224
19.6 Updating Your Proles . . . . . . . . . . . . . . . . . . . . . . 226
20 Immunizing Programs 227
20.1 Introducing the AppArmor Framework . . . . . . . . . . . . . . . 228
20.2 Determining Programs to Immunize . . . . . . . . . . . . . . . . 230
20.3 Immunizing cron Jobs . . . . . . . . . . . . . . . . . . . . . . . 231
20.4 Immunizing Network Applications . . . . . . . . . . . . . . . . . 232
21 Prole Components and Syntax 237
21.1 Breaking a Novell AppArmor Prole into Its Parts . . . . . . . . . . . 238
21.2 ProleTypes.......................... 241
21.3 #include Statements . . . . . . . . . . . . . . . . . . . . . . . 244
21.4 Capability Entries (POSIX.1e) . . . . . . . . . . . . . . . . . . . . 245

21.5 Network Access Control . . . . . . . . . . . . . . . . . . . . . 245
21.6 Paths and Globbing . . . . . . . . . . . . . . . . . . . . . . . 246
21.7 File Permission Access Modes . . . . . . . . . . . . . . . . . . . 249
21.8 ExecuteModes......................... 252
21.9 Resource Limit Control . . . . . . . . . . . . . . . . . . . . . . 257
21.10AuditingRules.......................... 258
21.11 Setting Capabilities per Prole . . . . . . . . . . . . . . . . . . . 259
22 AppArmor Prole Repositories 261
22.1 Using the Local Repository . . . . . . . . . . . . . . . . . . . . 261
22.2 Using the External Repository . . . . . . . . . . . . . . . . . . . 262
23 Building and Managing Proles with YaST 265
23.1 Adding a Prole Using the Wizard . . . . . . . . . . . . . . . . . 267
23.2 Manually Adding a Prole . . . . . . . . . . . . . . . . . . . . . 275
23.3 EditingProles ......................... 275
23.4 Deleting a Prole . . . . . . . . . . . . . . . . . . . . . . . . 281
23.5 Updating Proles from Log Entries . . . . . . . . . . . . . . . . . 281
23.6 Managing Novell AppArmor and Security Event Status . . . . . . . . . 283
24 Building Proles from the Command Line 287
24.1 Checking the AppArmor Module Status . . . . . . . . . . . . . . . 287
24.2 Building AppArmor Proles . . . . . . . . . . . . . . . . . . . . 289
24.3 Adding or Creating an AppArmor Prole . . . . . . . . . . . . . . 290
24.4 Editing an AppArmor Prole . . . . . . . . . . . . . . . . . . . . 290
24.5 Deleting an AppArmor Prole . . . . . . . . . . . . . . . . . . . 290
24.6 Two Methods of Proling . . . . . . . . . . . . . . . . . . . . . 291
24.7 Important Filenames and Directories . . . . . . . . . . . . . . . . 312
25 Proling Your Web Applications Using ChangeHat 315
25.1 Apache ChangeHat . . . . . . . . . . . . . . . . . . . . . . . . 316
25.2 Conguring Apache for mod_apparmor . . . . . . . . . . . . . . . 322
26 Conning Users with pam_apparmor 327
27 Managing Proled Applications 329
27.1 Monitoring Your Secured Applications . . . . . . . . . . . . . . . 329
27.2 Conguring Security Event Notication . . . . . . . . . . . . . . . 330
27.3 Conguring Reports . . . . . . . . . . . . . . . . . . . . . . . 333

27.4 Conguring and Using the AppArmor Desktop Monitor Applet . . . . . 353
27.5 Reacting to Security Event Rejections . . . . . . . . . . . . . . . . 354
27.6 Maintaining Your Security Proles . . . . . . . . . . . . . . . . . 354
28 Support 357
28.1 Updating Novell AppArmor Online . . . . . . . . . . . . . . . . . 357
28.2 Using the Man Pages . . . . . . . . . . . . . . . . . . . . . . . 357
28.3 For More Information . . . . . . . . . . . . . . . . . . . . . . 359
28.4 Troubleshooting......................... 360
28.5 Reporting Bugs for AppArmor . . . . . . . . . . . . . . . . . . . 367
29 AppArmor Glossary 369
Part V The Linux Audit Framework 373
30 Understanding Linux Audit 375
30.1 Introducing the Components of Linux Audit . . . . . . . . . . . . . 378
30.2 Conguring the Audit Daemon . . . . . . . . . . . . . . . . . . . 379
30.3 Controlling the Audit System Using auditctl . . . . . . . . . . . . . 385
30.4 Passing Parameters to the Audit System . . . . . . . . . . . . . . . 387
30.5 Understanding the Audit Logs and Generating Reports . . . . . . . . . 391
30.6 Querying the Audit Daemon Logs with ausearch . . . . . . . . . . . 403
30.7 Analyzing Processes with autrace . . . . . . . . . . . . . . . . . . 407
30.8 Visualizing Audit Data . . . . . . . . . . . . . . . . . . . . . . 408
31 Setting Up the Linux Audit Framework 411
31.1 Determining the Components to Audit . . . . . . . . . . . . . . . 412
31.2 Conguring the Audit Daemon . . . . . . . . . . . . . . . . . . . 413
31.3 Enabling Audit for System Calls . . . . . . . . . . . . . . . . . . 414
31.4 Setting Up Audit Rules . . . . . . . . . . . . . . . . . . . . . . 415
31.5 Conguring Audit Reports . . . . . . . . . . . . . . . . . . . . . 417
31.6 Conguring Log Visualization . . . . . . . . . . . . . . . . . . . 420
32 Introducing an Audit Rule Set 423
32.1 Adding Basic Audit Conguration Parameters . . . . . . . . . . . . 424
32.2 Adding Watches on Audit Log Files and Conguration Files . . . . . . . 425
32.3 Monitoring File System Objects . . . . . . . . . . . . . . . . . . 426
32.4 Monitoring Security Conguration Files and Databases . . . . . . . . . 427
32.5 Monitoring Miscellaneous System Calls . . . . . . . . . . . . . . . 430
32.6 Filtering System Call Arguments . . . . . . . . . . . . . . . . . . 430

32.7 Managing Audit Event Records Using Keys . . . . . . . . . . . . . . 433
33 Useful Resources 435

About This Guide
This manual introduces the basic concepts of system security on SUSE Linux Enterprise
Server. 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:
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.
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.
Storage Administration Guide
Provides information about how to manage storage devices on a SUSE Linux En-
terprise Server.
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 Server 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.
Novell AppArmor Quick Start
Helps you understand the main concepts behind Novell® AppArmor.
Find HTML versions of most SUSE Linux Enterprise Server 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/
xii Security Guide

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
•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
•►amd64 em64t ipf: This paragraph is only relevant for the specied architectures.
The arrows mark the beginning and the end of the text block. ◄
About This Guide xiii

►ipseries zseries: This paragraph is only relevant for the specied architectures.
The arrows mark the beginning and the end of the text block. ◄
•Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a
chapter in another manual.
xiv 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 9, 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 Server 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 Server 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 Server's congu-
ration 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 Server's RPM packages carry
6Security Guide