Patent Application
20080209501
The present invention is generally directed to computer security. More particularly, it is directed to implementing mandatory access control in a computer, and applications thereof.
Many computer operating systems have a security mechanism commonly referred to as access control. There are two main types of access control—discretionary access control and mandatory access control.
Under discretionary access control, system resources have security attributes (e.g., passwords and/or access control lists) associated with them. Access to system resources is controlled based on these security attributes, which are used to protect the system resources (e.g., files) owned by one user from unauthorized access by other users. A weakness associated with discretionary access control is that the security attributes assigned to each system resource are specified by the resource owner and can be modified or removed at will. During a computer attack, an attacker may be able to alter discretionary access control security attributes and thereby gain access to any or all system resources.
Under mandatory access control, access to system resources is controlled by security attributes that cannot be modified or removed during normal operation. In this way, mandatory access control offers a greater level of security compared to discretionary access control.
An example of mandatory access control is type enforcement. Type enforcement is implemented, for example, in security-enhanced Linux (SELinux). In type enforcement, both applications and system resources are assigned a type. Access for a type enforcement system such as SELinux is defined by a collection of rules contained in a file called a policy. A policy file is loaded into the operating system kernel of a machine during the boot process. The type attributes assigned to applications and system resources cannot be changed during normal operation.
Although mandatory access control such as type enforcement provides a greater level of security than discretionary access control, configuring the policy is difficult. The policy language of SELinux, for example, includes many complexities that must be well understood by a system developer before the system developer can create an effective security-enhanced system. Many system developers, however, do not have such an understanding. Therefore, many system developers cannot take advantage of the enhanced security offered by mandatory access control such as type enforcement.
What are needed are new techniques and tools for implementing mandatory access control that overcome the deficiencies noted above.
The present invention provides systems and methods for implementing mandatory access control in a computer, and applications thereof. In an embodiment, the present invention provides a security policy generator. The security policy generator generates security policies for one or more machines of a network based on a single set of enterprise configuration parameters. The enterprise configuration parameters may include, but are not limited to, IP addresses, ports, and network interfaces corresponding to the deployment environment. This single set of enterprise configuration parameters comprises relatively few lines of text compared to a typical security policy file.
The present invention makes it possible to easily configure, change, and adapt mandatory access control security policies to enforce application-specific security goals across multiple networked systems to create a single, distributed, secure enterprise. With the present invention, a network administrator, for example, can set familiar network and file configuration options that automatically result in security changes without requiring extensive knowledge of the operating system kernel or how to develop a mandatory access control security policy.
Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the relevant art(s) to make and use the invention.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when read in conjunction with the drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
The present invention provides systems and methods for implementing mandatory access control in a computer, and applications thereof. In the detailed description that follows, references to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
In an embodiment, security policy management server 102 includes a security policy generator. The security policy generator generates the security policies for the target machines in network 100. As would be known to persons skilled in the relevant art(s), a typical security policy can include upwards of 50,000 lines of source code. It is a feature of the present invention, however, that network security policies can be generated in a simplified manner.
In an embodiment of the present invention, the security policy generator of security policy management server 102 generates the security policies for the machines of network 100 based on a single set of enterprise configuration parameters (e.g., the IP addresses, ports, and network interfaces corresponding to the deployment environment). This single set of enterprise configuration parameters may comprise, for example, as few as 50 lines of text, as opposed to upwards of 50,000 lines of source code.
As described in more detail below, it is a feature of the present invention that the enterprise configuration parameters needed by the security policy generator to generate the mandatory access control security policies can be provided, for example, by a network administrator responsible for network 100, in the form of a configuration file or by interacting with a graphical user interface (GUI). It is also a feature of the present invention that the security policies generated by the security policy generator can be configured to implement a common security objective for the deployment environment.
In order to better understand the present invention, consider the example multi-tier computer network 200 shown in
As shown in
Because firewalls 213, 215, and 217 do not filter information at the process level, network 200 is vulnerable to attacks that are launched at the process level such as port attacks. For example, an attacker could potentially use a process A executing on Internet server 210a to gain access to a process D executing on back-up server 240c. If process A is corrupted by an attack, process A may perpetuate the attack by transmitting data over a network interface 221 on Internet server 210a that is received by process B over a network interface 229 of application server 220a. Network interfaces 221 and 229 may comprise, for example, Ethernet network interface cards. Process B may further perpetuate the attack by transmitting data over a network interface 231 of application server 220a that is received by process D over a network interface 241 of back-up server 240c. Under a different scenario, an attacker might use process A executing on Internet server 210a to gain access to admin server 250c. As in the previous example, process A executing on Internet server 210a may perpetuate an attack on the application servers by transmitting data to process B executing on application server 220a. As illustrated in
Vulnerability to the above described attacks can be reduced and/or eliminated by implementing mandatory access control such as type enforcement in accordance with the present invention. How mandatory access control works is illustrated by
As will be understood by persons skilled in the relevant art(s) given the description herein, a security policy such as security policy 308 specifies all the permissions granted to processes that execute on a machine such as internet server 210a. In other words, a process running on a machine can only communicate in manners that are allowed by the machine's security policy. A security policy for a machine will specify, for example, (1) whether a first process running on the machine may communicate with a process running on a second machine, or (2) whether the first process may communicate with a second process on the same machine. An example of (1) is described in more detail below with reference to
Security policy 308 allows process A to communicate over network interface 221 with process B at IP address 10.1.6.2 using port 80. When process A attempts to send data to process B on application server 220a, the target IP address and port over which the data will be sent is included with the data, which in the example of
On the receiving side, security policy 408 allows process B to communicate over network interface 229 (using IP address 10.1.6.2 and port 80) with process A at IP address 10.1.6.3. Operating system 406 checks the source IP address of the incoming data and the network interface over which the incoming data is received. Operating system 406 also checks the security policy 408 to determine whether process B is allowed to receive data from that source IP address over that network interface. Because security policy 408 allows process B to receive data from process A at IP address 10.1.6.3 over network interface 229, operating system 406 allows the transmitted data to be received by process B.
As will be understood by persons skilled in the relevant art(s) given the description herein, the cells in column 501 specify the permissions granted to process A with respect to the processes on the other machines in computer network 200. Cell 502, for example, generally specifies the purposes of process A. In the example computer network 200, process A can serve local content to clients. More specifically, process A can act as a server and communicate with web clients over a network interface, and it can use standard UNIX System V (SysV) and file EPC mechanisms. Cells 504, 506, 508, and 510 respectively specify allowed communications (i) between process A (on the Internet server) and process B (on the application server), (ii) between process A and process C (on the application server), (iii) between process A and process D (on the back-end server), and (iv) process A and process E (on the management server). Referring to cell 504, process A can act as a server and communicate over the network to process B. As illustrated by cells 506, 508, and 510, process A shall not interact with process C, process D, or process E. Taken together, the cells of a particular column or a particular row of the matrix specify the security policy for a particular machine (e.g., column 501 specifies the security policy for an Internet server).
As noted herein, in an embodiment of the present invention, a security policy is generated by a security policy generator for each machine of a network. This is accomplished using configurable policy modules, a reference base policy, and enterprise configuration parameters as described in more detail below with reference to
As noted above,
The one or more generated policy modules 604 and 614 corresponding to security policies 602 and 612 include specific network parameters values such as, for example, IP addresses, network interfaces, and ports that may vary between particular implementations or between different deployment environments. While these specific network parameters values may vary, generally speaking, the types of machines and their purposes will not vary for a particular type of computer network. Accordingly, the one or more base policy modules 606 and 616 corresponding to security policies 602 and 612 contain information that does not depend on specific network parameters values.
The one or more base policy modules 606 and 616 corresponding to security policy 602 and security policy 612 are a subset of the policy modules found in 630 for an entire network. Similarly, the one or more generated policy modules 604 and 614 from security policy 602 and security policy 612 are derived from one or more configurable policy modules 618 for the entire network. The enterprise configuration parameters 610 are used in combination with the configurable policy module(s) 618 to generate policies 602 and 612.
The following method can be used to generate the configurable policy module(s) 618 and the reference base policy 630 for a particular type of computer network or network architecture. First, the functionality of the particular network architecture can be exercised for a first deployment environment and audit logs can be generated for each machine in the network of that deployment environment. Second, the audit logs can be analyzed to determine how processes interact with the operating systems and other processes given this network architecture. Third, a security policy can be generated for each machine in the network corresponding to the first deployment environment. That is, the security policy will include policy rules based on the enterprise configuration parameters corresponding to the first deployment environment. Fourth, the first three steps can be repeated for another deployment environment and/or security objective, if necessary. Finally, as illustrated by
Referring to
Embodiments of security policy generator 700 are described below in terms of a particular network architecture corresponding to network software, known as WebSphere provided by International Business Machines (IBM) Corporation of Armonk, N.Y. This is for illustrative purposes only, and not limitation. Other embodiments of security policy generator 700 may be used to create security policies for machines in other network architectures and/or database management systems—such as, for example, the DB2 database management system provided by IBM—without deviating from the spirit and scope of the present invention.
Translator 712 translates enterprise configuration parameters from a format that depends on a particular network architecture (such as WebSphere) to a format that is independent of the particular network architecture.
Input to translator 712 is in the form of an enterprise configuration file 710. The enterprise configuration file 710 includes enterprise configuration parameters, such as IP addresses, network interfaces, and ports. A network administrator, for example, provides the enterprise configuration parameters by manually inputting data into a configuration file or by interacting with a graphical user interface (GUI). The enterprise configuration file 710 comprises relatively few lines of text compared to the security policy generated by security policy generator 700. For example, in a WebSphere deployment in which security policy generator 700 generates a customized SELinux security policy, the enterprise configuration file 710 may comprise approximately 50 lines of text; whereas, the customized SELinux security policy may comprise upwards of 50,000 lines of code (e.g., rules).
The enterprise configuration parameters included in the enterprise configuration file 710 are in a format specific to the particular network architecture of the deployment environment. For example,
Translator 712 translates the enterprise configuration file 810 to form a translated configuration file 814. Translated configuration file 814 includes the enterprise configuration parameters, but is in a format that is independent of the particular kind of network architecture. Referring to the example in
Because translator 712 provides an output that is independent of the particular network architecture, security policy generator 700 can be easily reconfigured to create security policies for any new type of network architecture. For each new type of network architecture, only translator 712 would need to be reconfigured-policy module generator 716 and policy generator 732 would not need to be reconfigured.
Policy module generator 716 generates one or more generated policy modules 720. Each generated policy module 720 comprises a portion of a security policy source file, such as an SELinux source file. The generated policy module(s) 720 include enterprise configuration parameters (such as IP addresses, network interfaces, ports, etc.) corresponding to a particular deployment environment. The generated policy module(s) 720, however, cannot be compiled into an installable binary policy, as described in more detail below.
To generate the generated policy module(s) 720, policy module generator 716 receives several inputs. One of the inputs to policy module generator 716 is the enterprise configuration parameters. In an embodiment, the enterprise configuration parameters are included in an architecture-dependent format as provided, for example, by the enterprise configuration file 710. In another embodiment, the enterprise configuration parameters are included in an architecture-independent format as provided, for example, by the translated configuration file 714. For example,
Another input to policy module generator 716 is the configurable policy module(s) 718. The configurable policy module(s) 718 correspond to a particular type of architecture, such as WebSphere. Each configurable policy module 718 defines access for applications included in that architecture, but does not include information about the enterprise configuration parameters of the specific deployment environment. For example, the configurable policy module corresponding to Internet server 210a may specify that process A may communicate with process B on application server 220a, but would not include, for example, the IP addresses of Internet server 210a or application server 220a. In this way, the configurable policy module(s) 718 are portable between deployment environments. For example, the configurable policy modules corresponding to WebSphere can be used for any WebSphere deployment,
Another input to policy module generator 716 is the reference base policy 730. The reference base policy 730 is a security policy, such as a security policy that is included with SELinux. SELinux is described in more detail, for example, in Bill McCarty, SELinux: NSA's Open Source Security Enhanced Linux (Andy Oram ed., 2005), and Frank Mayer et al., SELinux by Example (Prentice Hall, 2007), the entirety of each of the foregoing is incorporated by reference herein. Policy module generator 716 compares the configurable policy module(s) 718 to the reference base policy 730 to generate the generated policy module(s) 720, as described in more detail below.
Policy generator 732 generates one or more installable binary policies 734 based on the generated policy module(s) 720 and the reference base policy 730. In particular, policy generator 732 generates an installable binary policy for each machine in a network. For the example of
For example,
As described herein, a network administrator can easily create and distribute security policies for each machine in a computer network using security policy generator 700. For example,
After generating the installable binary policies, admin server 250c can distribute the installable binary policies to the machines in network 200. For example, admin server 250c can send the first installable binary policy over a network interface 283 to Internet server 210a via an admin interface 1323. As a result, an installed policy 1361 provides security for process A on Internet server 210a.
Similarly, admin server 250c can send the second, third, and fourth installable binary policies to application server 220a, management server 230 and back-up server 240c via admin interfaces 233, 273, and 1343, respectively. As a result, an installed policy 1380 provides security for processes B and C on application server 220a, installed policy 1386 provides security for process E on management server 230, and installed policy 1388 provides security for process D on back-up server 240c.
Thus, as described herein, security policy generator 700 allows a network administrator to easily create and distribute security policies for each machine in a network.
Various aspects of the present invention can be implemented by software, firmware, hardware, or a combination thereof.
Computer system 1400 includes one or more processors, such as processor 1404. Processor 1404 can be a special purpose or a general purpose processor. Processor 1404 is connected to a communication infrastructure 1406 (for example, a bus or network). Computer system 1400 may also include a graphics processing system 1402 for rendering images to an associated display 1430.
Computer system 1400 also includes a main memory 1408, preferably random access memory (RAM), and may also include a secondary memory 1410. Secondary memory 1410 may include, for example, a hard disk drive 1412 and/or a removable storage drive 1414. Removable storage drive 1414 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive 1414 reads from and/or writes to a removable storage unit 1418 in a well known manner. Removable storage unit 1418 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 1414. As will be appreciated by persons skilled in the relevant art(s), removable storage unit 1418 includes a computer usable storage medium having stored therein computer software and/or data.
In alternative implementations, secondary memory 1410 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1400. Such means may include, for example, a removable storage unit 1422 and an interface 1420. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 1422 and interfaces 1420 which allow software and data to be transferred from the removable storage unit 1422 to computer system 1400.
Computer system 1400 may also include a communications interface 1424. Communications interface 1424 allows software and data to be transferred between computer system 1400 and external devices. Communications interface 1424 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface 1424 are in the form of signals 1428 which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 1424. These signals 1428 are provided to communications interface 1424 via a communications path 1426. Communications path 1426 carries signals 1428 and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels.
In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage unit 1418, removable storage unit 1422, a hard disk installed in hard disk drive 1412, and signals 1428. Computer program medium and computer usable medium can also refer to memories, such as main memory 1408 and secondary memory 1410, which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system 1400.
Computer programs (also called computer control logic) are stored in main memory 1408 and/or secondary memory 1410. Computer programs may also be received via communications interface 1424. Such computer programs, when executed, enable computer system 1400 to implement embodiments of the present invention as discussed herein, such as security policy generator 700 of
Various systems and methods for implementing mandatory access control in a computer, and applications thereof, have been described in detail herein. It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way. Furthermore, although aspects of the present invention have been described with reference to SELinux, the invention is not limited to the Linux operating system or SELinux. Based on the description contained herein, a person skilled in the relevant art(s) will appreciate that embodiments of the present invention can be implemented with regard to other operating systems.
