• Every extra service on a host is another possible vulnerability
• Separate servers by function
• Keep software up to date
• Use yum or Automatic Updates from Red Hat Network to stay current
• Limit access to critical servers
2-3
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <[email protected]> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Basic Principles of Host Security
Only run services that are necessary and in use on the servers. Every network-accessible service is potentially another way for the attacker to penetrate the system. Furthermore, these services should only be accessible by hosts that need to access them. On a public web server, that may be the entire Internet. On a private file server, that may only be selected workstations.
To keep the number of different services running on a single server to a minimum, it may be a good idea to separate servers by function. That means, if possible, the mail server should not also be the web server. If the mail server is a separate machine from the web server, that may mean a Sendmail exploit that compromises the mail server does not also result in the web server being compromised.
The software packages for those services should be kept up to date. Older versions of software may be vulnerable to security bugs or buffer overflows that have been repaired in newer releases. One easy way to do this is to take advantage of Red Hat Network. Every Red Hat Enterprise Linux host comes with a Red Hat Network entitlement. For a workstation, Automatic Updates initiated by rhnsd may help to keep the host up to date with low administrative overhead. For a critical server, it may be more desirable to use the yum (RHEL5) or up2date (RHEL4 and earlier) utility to manually update the server during a scheduled downtime, to avoid service disruptions due to unexpected changes in how the software behaves. A test lab can be used to test software updates before they are applied to production servers.
Limit user-level access to the servers. Once an attacker can log onto a system, there are many more ways that system can be attacked in an effort to gain root access. An unprivileged account may be used as a stepping stone to further control.
Copyright © 2007 Red Hat, Inc. All rights reserved
RHS333-RHEL5-en-1-20070604 Unit 2 Page 22
SELinux
• Mandatory Access Control (MAC) -vs- Discretionary Access
Control (DAC)
• A rule set called the policy determines how strict the control
• Processes are either restricted or unconfined
• The policy defines which resources a restricted process is
allowed to access
• Any action that is not explicitly allowed is, by default, denied
2-4
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <[email protected]> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
In an effort to deal with ever increasing threats to their data systems, the US government assigned the National Security Agency (NSA) the task of developing a single set of rules that all other agencies would follow in handling confidential information. By evaluating previous breaches, the NSA determined that a major hurdle to securing data was internal users bypassing local security. In some cases, users would inadvertently open access to a system. A classic example would be a user executing the command chmod 777 ~. To the user, this may seem an easy way to allow co-workers to share files. They may not realize that this gives everyone in the world access to potentially confidential information.
In more extreme cases, users would intentionally disable security for more insidious reasons. Both of these situations are examples of a user having the discretion to control the access to their system. The NSA felt the solution was to have systems implement Mandatory Access Control (MAC) over the users. In MAC, a set of rules, known as the
policy, identify what a process is allowed to do. Anything that is not explicitly permitted is, by default, denied. Ideally,
different policies could be implemented depending upon how strict the security needs.
The NSA's first implementation of MAC was a system called Mach, which introduced the concept of Type
Enforcement (TE). Objects (files, directories, resources) were assigned a type value. Users and processes were also
assigned a type value. The policy contains rules that allow a user or process to access objects. It was possible for a policy to be so strict, it was difficult to manage, so occasionally users and processes were allowed to be unconfined. This meant the policy did not apply to that user or process.
The NSA decided Mach made a better security framework than operating system. To get this framework deployed on production systems, the NSA needed access to the OS source code. They took advantage of the open source Linux kernel, and developed a set of patches to enable MAC. These patches became known as Security Enhanced Linux, or SELinux for short. They were later refined and incorporated into the kernel source by Red Hat.