About This Guide

While in most cases in this document reference will be made to a single server target or host, the scope can generally be applied to more than one machine. We generally assume that the security target can cover one or more systems running SUSE Linux Enterprise Server.

We explicitly do not make any assumptions about the hostility of the network that the systems are connected to, or the cooperative nature of the users that leverage the services provided by the systems.

In turn, this means that you partially define your context on your own when reading through this document. You will need to broaden the meaning of individual portions to adopt it to your environment. In some cases, such as the use case of a server that is exposed to the Internet, this document may even be insufficient or incomplete; however, it may still serve as a good starting point on your journey towards an increased level of confidence that your system will behave like you want it to.

About trust: Trust relationships exist among all systems that participate in networked transactions. In this way, the trust relationship between the people that use the systems is transported across these systems. The chain that is formed by your trust relationships is only as strong as the weakest link. It is good practice to graphically visualize the trust relationships with the services in a schematic overview or map of your network. Generally, it is up to the owner of a resource to enforce the policies imposed on that resource; this would usually be the server that provides the resource. The client that opens a connection to request the resource can only be made responsible for the actions that it performs. This refers to the action of opening the connection to start with, but to nothing else as such.

The case of hostile users is special and unique: The Human Resources department may be able to solve some of your security problems in your computing environment at least as well as some technical measures can. Please make sure that the necessary regulations in your environment fit your needs, and that they back your intentions instead of obstructing them if you need to work around a missing support from your HR department (and your management).

Persons that have administrative privileges on a system are automatically considered trusted.

A Linux system - without any additional security frameworks such as SELinux - is a single level security system: From a security policy perspective there is only the superuser (root) and non-privileged users. System users are non-root user IDs that have access to files specific to their purpose. The separation of administrative duties is complicated by this simplicity. Some tools help: Make use of sudo(8) for administrative tasks, but be aware that once the privilege boundary is crossed, a program running with root privileges does not enforce any file access policies for non-privileged users any more. vi(1) that runs as root can read and write to any file in the system.

Another tool to mitigate the risk of abuse or accidental misuse of administrative privileges is NetIQ's Privileged User Manager product. More information is available here:

Physical security of the server is another assumption made here, where the server is protected from theft and manipulation by unauthorized persons. A common sobering thought amongst security professionals is the “ten-second Denial of Service”: Unplug the wires and reboot the server. Physical security must be ensured and physical access must be controlled. Otherwise, all assumptions about at least the availability of these systems are void.

Note: Cryptography

The use of cryptography to protect the confidentiality of transactions with the services that your system provides is generally encouraged. The need to implement cryptographic enhancements is strongly dependent on the operational environments of all participating systems. Keep in mind that you need to verify all of the possible security benefits that cryptography can provide, for all of your services, and that these benefits are not delivered automatically just by turning on the “encrypt” option of your service (if you can enjoy the idyllic situation where encryption is available as a button to check):

Confidentiality

Protection against reading the content of a transaction

Privacy

Protection against knowing that a transaction exists, and some properties that it may have, such as size, identities of involved parties, their presence, ...

Integrity

Protection against alteration of content. Be aware that cryptography does not automatically provide this kind of protection.

Authenticity

Protection against identity fraud. Cryptography that does not know about identities of participating entities cannot deliver this value.

Keep in mind that encryption of data for confidentiality purposes can merely reduce the size of the data to protect from the actual size to the size of the key that is used to encrypt the data. This results in a key exchange problem for encrypted transactions, and in a key management problem for encrypted data storage. Since data is (typically, there are exceptions!) processed in clear, you need your vault unlocked while data within is being worked with. The encryption of such data on the file system or block device layer helps against the theft of the system, but it does not help the confidentiality of the data while the system is running.

If you want to implement a consistent security policy covering multiple hosts on a network then organizational procedures must ensure that all those hosts can be trusted and are configured with compatible security configurations enforcing an organization wide security policy. Isolation of groups of systems that maintain data of the same trust domain can provide an adequate means of control; ultimately, the access controls to these systems, both for end users and for other systems, need to be carefully designed, configured, inspected and monitored.

Important: Trusting Data

Data can only be trusted to the degree that is associated with the domain it comes from. If data leaves the domain in which security policies can be enforced, it should consequently be associated with the trust of the target domain.

For a review of industry best practices on security, the development of sound security processes, controls, development, reviews, audit practices and incident management, you can review a public RFC (request for comments). RFC 2196 is the ongoing work of the world-wide community and individual security and process experts. You can review it online here: http://www.faqs.org/rfcs/rfc2196.html. An RFC is an open and living document that invites comments and review. Enhancements and improvements are welcome; you will find instructions on where to send those suggestions within the document itself.

This guide provides initial guidance on how to set up and secure a SUSE Linux Enterprise Server installation but it is not intended to be the only information required for a system administrator to learn how to operate Linux securely. Assumptions are made within this guide that the reader has knowledge and understanding of operating security principles in general, and of Linux administrative commands and configuration options in particular.

Part I, “Common Criteria” contains a reference to Common Criteria and SUSE Linux Enterprise Server. Part II, “General System Security and Service Protection Methods” contains more general system security and service protection schemes.

당사에서는 여러 언어로 작성된 HTML 및 PDF 버전의 설명서를 제공합니다. 이 제품에 대해 다음과 같은 사용자와 관리자용 설명서가 제공됩니다.

HTML 버전으로 작성된 대부분의 제품 설명서는 /usr/share/doc/manual의 설치된 시스템 또는 데스크톱의 도움말 센터에서 찾으십시오. 최신 설명서 업데이트는 제품 설명서의 PDF 또는 HTML 버전을 다운로드할 수 있는 http://www.suse.com/doc에서 찾으십시오.

여러 피드백 채널을 사용할 수 있습니다.

본 설명서에서는 다음과 같은 인쇄 규칙이 사용됩니다.