What type of threats is selinux designed to eliminate

The chapter concludes with a survey of resources helpful to SELinux users. Table shows the number of incident reports for through During this four-year period, incident reports increased at an average annual rate of almost 85 percent.

That is, the number of incidents has roughly doubled each year. If this rapid rate of increase continues, the year will see over 10 million incident reports. Table Of course, the number of incident reports is an indirect rather than direct measure of the threat level.

So some might argue that the threat level is unchanged, and the increase in incident reports is due to system administrators reporting a greater proportion of incidents. Not all threats arise from software or the Internet. So-called insider threats , which come from local-area networks or proprietary wide-area networks, can present even more serious risks.

Insiders often attack systems by means other than software vulnerabilities. For instance, employees in two work groups may collude to falsify database records to steal from their employer.

Such threats generally cannot be prevented by purely technical means. Gartner research has estimated that 70 percent of security incident costs are related to breaches committed by insiders. While available evidence does suggest that system administrators have historically been reluctant to report incidents and have become less reluctant lately, evidence also indicates that the threat level is substantial and is rising rapidly.

As an information assurance researcher, I monitor several class-C networks for familiar and novel attacks. My data shows that a typical host on these networks is subject to attack every few seconds.

An unprotected host can succumb to attack in less time than it takes to install a typical operating system or software patch. Therefore, those for whom the confidentiality, integrity, and availability of information are important must invest significant effort to protect their hosts, especially those that connect to the Internet.

Three of the most significant factors that have led to the increased level of software threats are software complexity, network connectivity, and active content and mobile code. Because the human intellect is finite, software developers commit errors and leave omissions during the implementation of software systems.

The defects resulting from their errors and omissions cause software systems to behave in unwanted or unanticipated ways when executed in untested or unanticipated ways. Attackers can often exploit such misbehaviors to compromise systems. As a general principle, the more complex a system, the greater the intellectual demands its implementation imposes upon its developers.

Hence, complex systems tend to have relatively large numbers of defects and be relatively more vulnerable to attacks than smaller, simpler systems. Modern software systems, such as operating systems and standard applications, are large and complex. The Linux operating system, for instance, contains over 30 million source lines of code. And Red Hat Linux 7. A second factor contributing to increased software threats is increased network connectivity and, in particular, the Internet itself.

Connectivity provides a vector whereby attacks successfully launched against one networked host can be launched against others.

The Internet, which interconnects the majority of networks in existence, is the ultimate attack vector. The recent popularity of consumer access to the Internet compounds the threat, since the computers of most consumers are not hardened to resist attack. Unsecured hosts easily fall prey to viruses and worms, many of which install backdoors or Trojan horses that enable compromised systems to be remotely accessed and controlled.

Attackers can launch attacks by using these compromised hosts, thereby hiding their identity from the victims of their attacks and law enforcement. Many attackers attack from across international borders, which complicates the work of law enforcement. Because law enforcement generally has been ineffective in identifying and apprehending all but a handful of notorious computer criminals, attackers have believed themselves to be beyond the reach of prosecution and have acted out their whims and criminal urges with impunity.

The recent advent of wireless connectivity exacerbates the risks, as several of the security facilities commonly used on wireless networks implementing the IEEE A third factor contributing to increased software threats is the use of active content and mobile code. Active content refers to documents that have the capability of triggering actions automatically without the intervention, or possibly even the awareness, of their user.

However, a variety of modern document types can include active content such as Abobe PDF documents, MS Office documents, Java applets, and web pages containing JavaScript code or using browser plug-ins. Even PostScript documents, which are widely thought to be safe, can contain active content. The danger of active content is that users generally perceive documents as benign, passive entities.

One of my research projects involves the use of honeypots to study computer attacks and attackers. A honeypot is a specially instrumented system that is left open to attack. In , I monitored intruders on one of my honeypots, who were discussing the likelihood of their apprehension and prosecution. Mobile code is code designed to be transported across a network for execution on remote hosts. Email clients and web browsers, for example, accept and process a wide variety of mobile code types, including Java and JavaScript programs, Microsoft ActiveX controls, and others.

Unfortunately, active content and mobile code provide more than flexibility and convenience to users: they provide attackers with a flexible and convenient attack vector. Many Internet attacks take the form of active content or mobile code delivered via email. Especially sophisticated malicious code may not even require user action.

Multiple levels of authorization act as bulwarks against the damage done when a program is compromised. Many common operating systems have two primary levels of authorization—one for ordinary users and one for the system administrator. A handful of operating systems, such as those used on PDAs and small computing devices, do not impose any such restrictions. Restricting programs to the few functions they need to perform is called the principle of least privilege.

Operating systems that lack multiple levels of authorization cannot implement the principle of least privilege and are therefore inherently quite insecure.

When an attacker compromises a program running under a single-level operating system, the attacker gains the ability to perform any operation of which the system is capable. However, an attacker who compromises a program on a system that has multiple levels of authorization obtains only the privilege to perform those operations for which the program is authorized. If the program performs tasks related to system administration, the attacker may gain wide-ranging privileges.

However, if the program performs relatively mundane tasks, the attacker may achieve relatively little beyond gaining the ability to disrupt operation of the compromised program. Nevertheless, an attacker who compromises even a program that confers few privileges may achieve a significant victory, because the attacker can use the privileges conferred by the program as a beachhead from which to attack programs conferring additional or greater privileges.

Alternatively, the attacker may intentionally disrupt operation of the compromised program in what is called a denial of service.

Most users configure Apache to run as an ordinary user, rather than as the system administrator. So, attackers who successfully exploited a web server using the Apache OpenSSL attack generally obtained only limited privileges.

Unlike the Apache web service, which is available to remote users, the ptrace facility is available only to local users. Successful compromise of an Apache web server enabled attackers to access the ptrace facility and exploit a ptrace defect that conferred full system administration privileges.

When a software vendor learns that one of its products is vulnerable to attack, the vendor will generally issue a patch. Users can install the patch, which modifies the vulnerable product in a way intended to eliminate—or at least mitigate—the vulnerability. Occasionally, a patch alleged to eliminate a vulnerability will fail to actually do so.

Worse yet, occasionally a patch will introduce one or more new vulnerabilities. So patches are sometimes less than ideal solutions. But, as a means of defending against software attacks, patches suffer from a more fundamental flaw.

The essential problem with patches is that they are a reactive, rather than proactive, response. Patching is thus a continual process consisting of the following steps, known as the patch cycle :. It may seem odd that security researchers publish vulnerabilities rather than privately inform vendors of them, because publication of a vulnerability may help attackers discover a way to exploit it.

Indeed, most security researchers do prefer to inform vendors of vulnerabilities privately rather than publicly. But many vendors consistently fail to release patches in a timely manner. Each domain or type can be associated with any number of attributes. When a rule is written that specifies an attribute name, that name is automatically expanded to the list of domains or types associated with the attribute.

Use the syntax above to create avc rules that comprise the essence of an SELinux policy. The most common example of one of these rules is an allow rule, such as:.

In practice, this rule may be extended to include other permissions:. Platform apps built into the system run under a separate label and are granted a distinct set of permissions. Access to the following generic labels should never be directly allowed to domains; instead, a more specific type should be created for the object or objects:.

Content and code samples on this page are subject to the licenses described in the Content License. Docs Getting Started About. Core Topics Architecture. Overview Security Overview. Android Security Bulletins. Android Automotive. Application Signing. Protected Confirmation. Identity Credential. Trusty TEE. Verified Boot. Though there are many other security standards that affect our customers, we selected PCI-DSS based on a review of customer support cases, feedback, and general inquiries we received.

The items we selected from this standard are also accepted industry practices, such as:. It was released under an open source license in , and integrated into the Linux kernel in SELinux works by layering additional access controls on top of the traditional discretionary access controls that have been the basis of UNIX and Linux security for decades.

SELinux access controls provide both increased granularity as well as a single security policy that is applied across the entire system and enforced by the RHEL kernel. SELinux enforces the security policy on applications bundled with Red Hat Enterprise Linux as well as any custom, third-party, and independent software vendor ISV applications.

In addition to applications on the host system, SELinux access controls provide separation and controlled sharing between RHEL-hosted virtual machines and containers. The SELinux security policy functions as a whitelist for user and application behavior. Access to files, local interprocess communications IPC mechanisms, the network, and various other system resources can all be restricted on a per-domain basis.

SELinux also allows the administrator to put individual SELinux domains, as well as the entire system, into permissive mode where SELinux-based access denials are logged, but the access is still permitted. This eases policy development and troubleshooting. While SELinux is an important part of Red Hat Enterprise Linux security capabilities, there are many other security technologies and widely accepted practices that should also be employed.

Data encryption, malware scanning, firewalls, and other network security mechanisms remain an important part of an overall security strategy. SELinux is a way to augment existing security solutions, and is not a replacement for current security measures that may be in place.

Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Given that, by default, it denies access to any resource rather than permits access, SELinux immediately meets industry-accepted system hardening standards, and may help mitigate certain classes of security vulnerabilities. It also helps meet the more granular requirements under 2. At a system-configuration level, SELinux can prevent unauthorized overwriting of files—even when a specific user or role would normally be authorized to write to the directory containing cryptographic keys.

In the default targeted policy, some applications run in a confined SELinux domain where SELinux policy restricts those applications to a particular set of behaviors.