DE10229114A1 - Operating system administering method in computer, involves manipulating compartments of operating system associating with different processes by command-line utility - Google Patents

Abstract

A management system associates different processes to several compartments (401-403) of an operating system (400). A command-line utility (404) is provided for manipulating the compartments. Independent claims are included for the following: (1) system for administering operating system; and (2) computer readable medium storing operating system administration program.

Description

The present invention relates generally to a Computer containment and more specifically on a system and Procedure that involves managing departments in one Enable operating system.

An operating system (OS) is included Right the most important program on a computer system is running because the OS is executing everyone else Programs (commonly referred to as "applications" be used). In general, the OS offers one Functionality that the applications can then use. To the For example, an application can run an OS routine (e.g. via a system call) to get a special file save, and the OS can be / Output basic system (BIOS; BIOS = basic input / output system), dynamic main libraries, drivers and / or other components of the computer system interact to the save special file properly. Lots different OS's have been developed in the prior art which, for example, HP-UX®, Linux ™, MS-DOS®, OS / 2®, Windows®, Unix ™, System 8, MPE / iX, Windows CE® and Palm ™ include.

Fig. 1 shows an exemplary system 100, the OS 101 comprises a. As shown, the OS 101 can perform such tasks as: B. Detection of an input from the keyboard 106 and the mouse 104 , sending an output to the display screen 107 and control of peripheral devices such as. B. a disk drive 103 and a printer 105 . In some OSs, relatively complex functions are integrated, which can only be done by separate programs, such as. B. faxing, data processing, disk compression, and Internet browser were executed. In general, OS's provide a software platform on which other programs, e.g. B. an application 102 can be executed. Application programs are generally written to run on a particular OS, and therefore the particular OS that is implemented on a computer system can largely dictate the types of applications that can be run on such a computer system.

The application 102 running on a computer system 100 may depend on operating system routines to perform basic tasks such as recognizing an input from the keyboard 106 and the mouse 104 and sending an output to the display screen 102 . The OS 101 has sets of routines for performing various tasks (e.g., low level operations). Operating systems include e.g. B. Generally routines for performing such tasks as creating a directory, opening a file, closing a file and saving a file. Application 102 can call certain OS routines to perform the desired tasks by making a system call. This means that the applications generally call OS routines via system calls. A user can also interact with the OS 101 through a set of commands. For example, the DOS operating system contains commands such as: B. COPY (copy) and RENAME (rename) for copying files or changing the names of files. The commands are accepted and executed by a part of the operating system called the command processor or command line interpreter. In addition, a graphical user interface can be provided to enable a user to issue commands by pointing and clicking on objects that e.g. B. appear on the display screen.

In addition to the ones described above, the OS's can do many Show areas of responsibility. For example, the OS's also have the responsibility to ensure that different applications and users at the same time work, not interfere with each other. The OS's can also have responsibility for security, e.g. B. to ensure that unauthorized users do not access the System (or at least on prohibited sections of the system) access. For example, "trustworthy" (secure) OS's that include security mechanisms in the same State of the art has been developed such. B. those who for handling and processing classified governmental (e.g. military) information are designed. A type of security mechanism that can be implemented is a testing of Operating system routines (referred to as "events" can) used by applications and / or users become. For example, the OS's generally collect the Test data regarding the use of a Operating system routine through a system call (or "syscall") passed through an application is made that is called. Assume that e.g. B. an application makes a system call, to open a special file, a test program such test data in the operating system for the system call, such as the date and time when the system call was made name of the file to be opened and Result of the system call (e.g. system file successful or opened unsuccessfully), collect. Such testing can be considered Part of the security mechanism to be executed is included in the OS, for example. Other security mechanisms can in addition to or instead of such a test feature be implemented.

Specifically, trustworthy OS's include those unrestricted Hewlett-Packard CMW (compartment mode work station = departmental mode workstation), Hewlett-Packard Virtual Vault, Sun Trusted Solaris and SCO CMW are owned by general security mechanisms, such as B. testing of at least security-related events.

The central one, as is well known to experts Module of an OS the operating system kernel. in the generally this is the part of the OS that comes first is loaded and typically in main memory located. Typically, the kernel is for such tasks as memory management, Process and task management and plate management, responsible. The operating system core of an OS is often for a lot of the security measures by a such OS are provided responsible.

The way in which security measures in an OS are implemented, prepares a system administrator often difficulties / complex effort in managing a Systems, performing such tasks as Add new applications to the system etc. etc. The means that you often rely on system administrators leaves when it comes to proper configuration of System resources and / or security mechanisms in properly / safely. For example, they are Applications that form electronic services in general sophisticated and contain many lines of code that are common have one or more bugs, causing the Applications become more vulnerable to attack. When a electronic service is offered on the Internet, it is one large group of potential attackers exposed to the be able to probe the service for weaknesses, and as a result of these bugs it has become known that Security breaches have occurred. Once an application has been endangered (e.g. by a Buffer overflow attack), it can be done in several different ways an attacker can be used to protect the security of the System hurt.

More and more individual machines are being used to make several Services at the same time (e.g. ISP, ASP, xSP- Service delivery), and therefore it always will more important that not only the security of the host platform is protected against application-endangering attacks, but also that the applications in the event of an attack are adequately protected from each other.

One of the most effective ways to protect yourself from a Application risk at OS level includes operating system Core-forced or forced controls, because the in Control systems are not implemented by the operating system kernel an application or a user from the user room can be turned off or undermined. The controls are typically irrelevant in all applications the level of security and / or security desired by everyone individual application code, applicable. Be accordingly the controls may be unnecessary in some cases used (they can overuse certain applications protect).

In general, there can be two basic security goals that are desirable at the system level to adequate protection against application risks and their Impact. First, applications in be protected as much as possible from an attack. For example, exposed interfaces to the Applications are kept as tight as possible, and the Access to such interfaces should be well controlled his. Second, the amount of damage that a can cause endangered application to the system on which be as limited as possible.

The above two requirements can be met by the Use of a "containment" can be achieved. In general an application is contained when in the same strict Checks are carried out on which Resources they can access and what type of access it owns even if the application has been compromised. Containment also protects an application from external ones Attacks and interference. Therefore, the Containment functionality the potential, many of the potential At least to mitigate an attacker's exploitation actions.

• 1. Mißbrauch eines Privilegs, um direkten Zugriff auf geschützte Systembetriebsmittel zu erlangen. Wenn eine Anwendung mit speziellen Privilegien arbeitet (z. B. eine Anwendung, die als Wurzel auf einem Unix- Standard-Betriebssystem läuft), dann kann ein Angreifer versuchen, dieses Privileg auf unerwünschte Weise zu benutzen. Zum Beispiel könnte der Angreifer dieses Privileg verwenden, um Zugriff auf geschützte operierende Betriebsmittel zu erlangen oder um mit anderen Anwendungen zu interferieren, die auf der gleichen Maschine arbeiten.
• 2. Untergrabung von anwendungsforcierten Zugriffssteuerungen. Bei dieser Art von Angriff wird ein Zugriff auf legitime Betriebsmittel erlangt (d. h. Betriebsmittel, die durch die Anwendung freigelegt werden sollen), dies jedoch in unerlaubter Weise. Zum Beispiel ist ein Webserver, der eine Zugriffskontrolle auf seinen Inhalt forciert, bevor er diesen anbietet, eine Anwendung, die für diese Art von Angriff anfällig ist. Da der Webserver einen ungesteuerten direkten Zugriff auf den Inhalt aufweist, tut dies auch der Angreifer, der die Kontrolle über den Webserver erlangt hat, in der gleichen Weise.
• 3. Bereitstellung von falschen entscheidungstragenden Sicherheitsinformationen: Diese Art von Angriff ist gewöhnlich ein indirekter Angriff, bei dem die gefährdete Anwendung, im Gegensatz zum Hauptdienst, üblicherweise ein Unterstützungsdienst (wie z. B. ein Autorisierungsdienst) ist. Der gefährdete Sicherheitsdienst kann dann verwendet werden, um falsche oder gefälschte Informationen zu liefern, wodurch einem Angreifer ermöglicht wird, Zugriff auf den Hauptdienst zu erlangen. Daher handelt es sich hierbei um eine weitere Möglichkeit, mit der ein Angreifer unautorisierten Zugriff auf Betriebsmittel, die durch die Anwendung legitim freigelegt wurden, erlangen kann.
• 4. Illegale Verwendung von ungeschützten Systembetriebsmitteln. Ein Angreifer erlangt Zugriff auf lokale Betriebsmittel der Maschine, die nicht geschützt sind, aber normalerweise nichtsdestotrotz durch die Anwendung freigelegt werden würden. Typischerweise würden solche lokalen Betriebsmittel dann verwendet werden, um weitere Angriffe einzuleiten. Zum Beispiel könnte ein Angreifer einen Schalenzugriff (bzw. Shell- Zugriff) auf das Host-System erlangen, und von dort aus könnten dann inszenierte Angriffe auf andere Anwendungen in der Maschine oder im Netzwerk eingeleitet werden.

The most common attacks that follow an application's threat can broadly be categorized as one of four types, as follows (although the consequences of a particular attack can be a combination of any or all of these types):

• 1. Abuse of privilege to gain direct access to protected system resources. If an application works with special privileges (eg an application that is rooted on a standard Unix operating system), an attacker could try to use this privilege in an undesirable way. For example, the attacker could use this privilege to gain access to protected operating resources or to interfere with other applications working on the same machine.
• 2. Undermining application-driven access controls. This type of attack accesses legitimate resources (that is, resources that are intended to be exposed by the application), but in an unauthorized manner. For example, a web server that enforces access control to its content before offering it is an application susceptible to this type of attack. Since the web server has uncontrolled direct access to the content, the attacker who has gained control of the web server does the same.
• 3. Providing false decision-making security information: This type of attack is usually an indirect attack in which the application at risk, unlike the main service, is usually a support service (such as an authorization service). The vulnerable security service can then be used to provide false or bogus information, allowing an attacker to gain access to the main service. This is another way that an attacker can gain unauthorized access to resources that have been legitimately exposed by the application.
• 4. Illegal use of unprotected system resources. An attacker gains access to the machine's local resources that are not protected but would normally still be exposed by the application. Typically, such local resources would then be used to initiate further attacks. For example, an attacker could gain shell access to the host system, and from there staged attacks on other applications in the machine or on the network could be initiated.

With containment, the abuse of a privilege has to Get direct access to protected System resources a lot less serious consequences than without Containment because even if an attacker is one Application privilege uses the resources that are accessed can be bound by what is in the containment area of the Application has been made available. Similarly can in the case of unprotected equipment that a Use containment to access the network from be blocked from an application or at least very be strictly controlled. In terms of Providing wrong decision-makers Security information mitigates the potential damage, which is done by ensuring that the only access to support services from the legitimate clients from d. H. the application services, thereby exposing applications to the attack is restricted.

A reduction or prevention of an attack by the second Types, d. H. an undermining of application-forced Access controls, is usually based on application concept or at least reached at configuration level. at However, using containment can take precautions be taken that access to protected resources from a large, untrustworthy application (e.g. a web server) by a smaller, must go to more trustworthy application.

Therefore, using containment in an operating system effectively increases application security and mitigates possible damage that can be done by an attacker in the event an application is compromised. Referring to FIG. 2, an exemplary architecture 200 is illustrated functionality containment for multiservice host on an operating system with the. Containment is used in the illustrated example to ensure that the applications (shown as Service 0, Service 1, ..., Service N) are kept separate from each other and from critical system resources. An application cannot interfere with the processing of another application or gain access to its (possibly sensitive) data. Containment is used to ensure that only the interfaces (input and output) that require a particular application to function are exposed by the operating system, thereby increasing the amount of attack on a particular application and the amount of damage that can be caused if the application would be compromised. Therefore, containment helps maintain the overall integrity of the host platform.

Operating system core-containing containment mechanisms in OS's have been used for several years, typically in OS's Handling and processing classified (military) information was designed, available. Such OS's are often called "Trusted Operating Systems" (trusted operating systems). The containment Functionality is usually through a combination of prescribed access controls (MAC; MAC = Mandatory Access Controls) and privileges achieved. The MAC Protection schemes enforce a special policy of the Access control for system resources, such as. B. Files, processes and network connections. This policy is forced by the operating system kernel and cannot by a user or a vulnerable application turned off.

The complexity / difficulty with which a System administrator when managing a system including the Management of security mechanisms, such as B. one Containment, which is generally faced by the Tools / techniques that a system administrator can use to Manage security mechanisms (e.g. for manipulation of security mechanism configurations) standing, increased. That is, a system administrator often with relatively complex and / or user-unfriendly Interfaces for configuring system resources and security mechanisms of an OS must interact. Techniques for configuring Security mechanisms in general are inefficient for you System administrator unwanted time and labor intensive when performing the tasks required to configure (e.g. manipulation) of security mechanisms necessary are, such as B. that to implement containment in one system.

It is an object of the present invention, a system and methods for managing departments in one trusted operating system with improved To create properties.

This object is achieved by a method according to claim 1 or 9, a system according to claim 10 and a Computer-readable medium according to claim 20 solved.

According to one embodiment, a method for Managing a processor-based system reveals that Implement at least one department to Retain at least one process and deploy at least one operating system command line utility has that executable to manipulate the departments is. According to a further exemplary embodiment, a System disclosed, which has at least one processor, and an operating system that has at least one department implemented at least one process on the system can be executed, can be assigned. The system points furthermore at least one configuration file which the Departments defined, and a facility to run the Manage departments without requiring a User the configuration files in which such subjects are defined, edited. Another embodiment provides a computer-readable medium that contains instructions, which can be executed by a processor, such a computer readable medium being a library software functions to manage at least one Department that has an operating system is implemented. Such a library of software functions includes at least one command line utility for Manipulating the departments can be done.

Preferred embodiments of the present invention are referred to below with reference to the enclosed Drawings explained in more detail. Show it:

Fig. 1 illustrates an exemplary computer system of the prior art, comprising an operating system;

Fig. 2 is a schematic illustration of an exemplary architecture for multi-service-hosting on an operating system that implements a mitigation functionality;

Figure 3 is an exemplary schematic representation of an OS implementation of sections.

Is a schematic illustration of an exemplary architecture of a trusted Linux host operating system can implement the sections 4, wherein various embodiments of the present invention may be implemented in such an exemplary architecture.

FIG. 5 shows an example of using departments in an OS according to the exemplary implementation of FIG. 4;

Fig. 6 in schematic outline the effect of the following rule in an exemplary OS implementation: HOST * → COMPARTMENT x METHOD TCP PRT 80;

FIG. 7 shows a schematic configuration of an exemplary configuration of Apache and two Tomcat Java Vms;

Fig. An exemplary trusted in schematic trains 8 gateway system;

Figure 9 is an exemplary Abteilungsverwaltungsfluß a typical method of the prior art to manage compartments by editing a configuration file and boot (or initialization) of the system.

FIG. 10 is an exemplary Abteilungsverwaltungsfluß according to at least one embodiment of the present invention;

FIG. 11 is an exemplary operational flow for generating a division and subsequent rename the same according to an embodiment of the present invention;

Figure 12 is an exemplary operational flow for switching from one department to another in accordance with an embodiment of the present invention. and

Fig. 13 shows an exemplary operation flow that utilizes utility department management, in order to switch to another department and execute a command in the same according to an embodiment of the present invention.

As described above, containment is a effective security mechanism to implement in one System. As described in more detail below, containment functionality in one system be implemented using the departments in the system. In general, the departments refer to groups of processes or sub-processes (threads) that are based on the Access certain subsets of system resources of a computer system are limited. Therefore, they are Departments semi-isolated sections of a system. On Operating system to support a variety of processes (e.g. applications) can, for example, on a system be implemented, at least part of the processes is provided with a label or a label, where each label or label is a logical one protected computing environment or "department". Everyone Process with the same label or the same The label can belong to the same department. With certain The containment functionality can be implemented through prescribed protection of processes, files and Network resources are provided, the basic concept based on the department. Services and Processes (e.g. applications) on the system can be carried out in separate departments. The processes in everyone Department can only have direct access to the Have resources in that department. Access to other resources, whether local or remote, can only be accessed via well controlled communication interfaces allowed become. Exemplary implementations of departments in One system is described in more detail below.

According to various embodiments of the present Invention becomes efficient and user-friendly Ability to manage (e.g. manipulate) Departments disclosed in an OS. Utilities are more special, such as B. Command line utilities provided the allow commands to be executed from the user space of an OS to manage the departments. According to at least In one embodiment, command line utilities are provided that allow commands to be executed to the departments and / or rules that contain the define such departments to dynamically manipulate.

For a better understanding of the present invention, it is appropriate that the reader understand the use of departments in an OS. Accordingly, an exemplary OS that implements departments therein and exemplary departmental arrangements are described below in connection with FIGS. 3-8. Although a specific OS architecture and methods for implementing departments within such an OS are described below, it is to be understood that the described OS and department implementations are intended to be exemplary only to help the reader understand certain aspects of the present invention Understand, and for this reason, the present invention is not intended to be limited to the specific OS and / or departmental implementations described below. Rather, any OS and method for implementing departments that is currently known or later disclosed should be within the scope of the present invention as defined by the appended claims. After providing an example of an OS architecture that implements departments, techniques for managing (e.g., manipulating) such departments are described. A prior art method of managing departments by editing configuration data and booting the system is described in connection with FIG. 9. Exemplary methods of managing (e.g., manipulating) departments using utilities in accordance with certain embodiments of the present invention are subsequently described in connection with FIGS. 10-13.

I. Exemplary OS architecture and department implementation

According to an exemplary OS, in which various exemplary embodiments of the present invention can be implemented, containment functionality is achieved by means of prescribed protection of processes, files and network resources at the operating system kernel level. Various types of mandatory controls can be used, such as: B. those of traditional trustworthy OS's. The key concept of a trustworthy OS is often the "department", and different services and processes (e.g. applications) on one system can be carried out in separate departments. Referring to FIG. 3, an exemplary schematic representation of an OS implementation of departments is shown, which provides a very simplified example of the concept of the departments. As shown, system 300 may have an OS running thereon that implements two compartments, shown as Department A and Department B. In the example of FIG. 3, processes X and Y are contained in department A and process Z is contained in department B. System 300 may include various resources, shown as resource A, resource B, and resource C in FIG. 3, and the departments may be implemented to designate those resources that the processes therein may access. Such resources A, B, and C may include network interfaces, processes, files, and / or other types of system resources. According to certain implementations, any number of system resources can be organized according to departmental access control. For example, system resources associated with a TCP / IP network operation, routing tables, routing caches, shared memory, message queues, semaphores, process / thread handling, and user ID (UID) handling can be handled by the Use of departments may be restricted.

In the example shown in FIG. 3, processes X and Y contained in department A have access to resource A and resource B, but not to resource C. Furthermore, process Z, which is shown in FIG Section B includes access to resource B and resource C, but not to resource A. As a result, the compartments can be used as a security mechanism that protects the applications from attacks and the extent of damage caused by a vulnerable process to the system can result, while an endangered process in a department limits its access to the resources that the department is allowed to access.

According to an example OS implementation relatively simple mandatory access controls and one Process labeling used to support the concept of a Department. In the example below Everyone will implement a trustworthy OS Process in the system assigned a label, and the Processes with the same label belong to the same Department. There are mandatory tests on Operating system kernel level enforced to ensure that the processes from one department don't use processes can interfere with another department. The prescribed access controls are relative in the sense simply designed the captions either agree with each other or do not. There is also no hierarchical arrangement of Labels in the system, as in some known ones trusted operating systems. in the Contrary to traditional trustworthy OS's, the Labels in this example are not used to identify the Control access to the main file system directly. Instead of file system protection is achieved by a other section of the main file system of a department is assigned. Any such section of the file system is a "chroot" of the main file system, and the processes, who work in each department only have access on the section of the file system that this department assigned.

The term "chroot" as used herein refers to a command to change the active root directory. That is, the "chroot" is a command that is executed to a user's active root directory change. For example, in a typical Unix system the root directory is displayed as "/". Hence the "Cd /" command normally run to Change root directory of the file system. The chroot command can be run to the active root directory change a user. For example, the Command "Chroot / home" an active root directory User in "/ home". Then executing the Command "cd /" to change to the "/ home" directory, and not to "/", since "/ home" is now the active one Is the user's root directory. As another example, the Chroot command used to make a special Specify department as the active root directory. To the For example, the command "Chroot / compt / FOO" changes the active one Root directory in the FOO department. Consequently, while the "cd /" is running to make it active Change root directory (changed by the chroot command the chroot command can be used as another Security mechanism can be used. For example, the chroot Command can be used to effectively prevent a User (or a process) from the active Root directory specified by the chroot command escapes. That means that e.g. B. a user (or process) not from the active root directory created by the Chroot command (e.g. department FOO) is specified to actual system root directory ("/") escape can. Once a user's active directory (or Process) via which the chroot command has been changed applies this as chrooted. Accordingly, the ability of a process via the operating system kernel controls in this exemplary implementation from one department to go to the root, canceled so that the chroot does not is to escape. This exemplary implementation provides the ability to chroot at least selected files to make unchangeable.

This exemplary OS architecture is flexible Communication channels between the departments and the Network resources over tight, at kernel level controlled interfaces with TCP / UDP and most IPC Mechanisms provided. Access to this Communication interfaces are determined by rules set by the Security administrator on a "per department" basis Basis can be specified. Hence it is in Contrast to traditional trustworthy ones Operating systems, not with this exemplary implementation necessary, the prescribed access controls with a Privilege or department regarding the use of turn off trusted user-level proxies to communication between the departments and the Allow network resources.

The exemplary implementation is clear trusted OS that offers containment, however has sufficient flexibility to To make application integration relatively straightforward, which makes the Total administrative costs and the effort of using and Operating a trusted operating system that is often associated with conventional trusted OSs, is reduced. Although again a specific one Example of the architecture and implementation that the Departments, described herein, and one preferred architecture and implementation form in the Embodiments of the present invention can be implemented, it is pointed out that each OS Architecture and any method of implementing Departments that are now known (e.g. traditional trustworthy OS's) or later discovered yourself within the scope of the present invention should move, and that certain embodiments of the present invention in any such OS architecture can be implemented.

The OS architecture and implementation of a specific one Examples of how to implement departments will now described in more detail. In the description below becomes a trustworthy Linux OS in detail described, whose system by modification to the Linux base Operating system kernel to help contain User level services such as: B. HTTP servers, is realized. However, one skilled in the art will understand that the in Connect to such a trustworthy Linux OS described principles applied to other types of OS can be used to achieve the same or similar effects achieve.

Referring to Fig. 4, an exemplary architecture of a trusted Linux host OS is shown that implements departments to provide containment. System 400 includes a plurality of departments. In this example, a WEB department 401 , an FTP department 402 and a SYSTEM department 403 are shown. Each department can be assigned to different executing processes or sub-processes. Thus, referring to Figure 4, a Linux base operating system core 400 generally includes a TCP / IP network operating device 406 , UNIX domain socket 408 , an interprocess communication device 410 (e.g., a Sys-V-IPC device) ), a file access module 412 and other subsystem 408 . The trustworthy Linux OS additionally has operating system kernel extensions 415 in the form of a security module 421 , a device configuration module 418 , a rule database 416 and operating system kernel modules 422 . As shown, at least some of the Linux kernel subsystems 406 , 408 , 410 , 412, and 414 have been modified to make requests to the security module 421 at the kernel level. In this exemplary implementation, security module 421 makes access control decisions and is responsible for pushing the concept of a department, thereby providing containment. Such an exemplary OS architecture, in which embodiments of the present invention may be implemented, is further described in the co-pending and assigned to the same assignee, US Patent Application entitled "SYSTEM AND PROCEDURE FOR FILE SYSTEM ACCESS CONTROL", the disclosure of which is incorporated herein by reference.

The security module 421 also consults the rules database 416 when a decision is made. The rules database 416 contains information about permitted communication paths between the departments, thereby providing narrow, well-controlled interfaces in and out of a department. As a result, departments' processes of accessing system resources are restricted according to the rules stored in the rules database 416 . The rules database 416 may have separate tables for TCP / IP network resource rules and for file system resource rules. The different components can be stored in different positions. For example, the TCP / IP resource rules may be stored in random access memory, while the file system resource rules may be stored on the file system. Figure 4 also illustrates how the kernel extensions 415 are managed from the user room 420 through a series of bespoke system calls. As described in more detail below, such bespoke system calls may include some to manipulate the rules table 416 and others to operate the processes in special departments and to configure network interfaces.

As described in more detail below, system department 403 may include processes that simplify command line utilities 404 to modify the departments or rules associated with such departments. In accordance with various embodiments of the present invention, command line utilities 404 may include commands to manage departments (e.g., manipulating departments and / or department rules). As shown in the exemplary system of FIG. 4, stable storage database 405 may be implemented in the user space and includes information identifying department names and a corresponding number map for each department (e.g., in the "cmap.txt" file) , As a result, each department can be assigned user-friendly names, and each department can also have a respective number that is used for internal processing by the system 400 . Furthermore, the security module 421 preferably includes a memory 421 A, which has the department name and number of figure which enable the security module 421, to identify the corresponding rules in the rule database 416 that apply to a specific department, which requests access to the system resources.

During operation, each of the operating system kernel modules of system 400 advantageously interacts with security module 421 . Security module 421 drives the departmental schema to prevent unauthorized access to the system resources. Specifically, security module 421 uses device configuration module 418 and rules database 416 to alleviate departmental restrictions. The security module 421 can determine which resources are available to the system 400 through the device configuration module 418 . Security module 421 also receives department identification and system resource identification to be accessed by an operating system kernel module routine. The security module 421 searches the rules database 416 to locate an applicable rule. The security module 421 enables or blocks access based on an applicable rule or based on a default rule if no applicable rule has been located.

Referring briefly to FIG. 5, an example of department usage in an operating system according to an exemplary implementation is shown. As shown, the system call commands (syscall commands) 509 can be used so that a user can manipulate the rules in a rule engine 506 (which is executed in the operating system core 501 ) from the user space 502 . A program 507 or a file 508 can e.g. B. Execute such Syscall commands 509 to implement the desired rules in the rule engine 506 to define the containment of the departments. The example of FIG. 5 also includes a process 503 associated with a particular department. Process 503 executes code in user space 502 , which is a hardware enforced operating mode that restricts process 503 operations. Process 503 may include code that is operable to attempt to access a protected resource (e.g., open a particular file) according to a departmental schema and request access to a specific resource. That is, process 503 requests (e.g., via a bespoke syscall) to get communication access 505 to a desired resource. Access control logic 504 is executed in operating system kernel 501 to access rule engine 506 to determine whether process 503 should be granted the requested access. More specifically, access control logic 504 receives a department identifier or tag from process 503 and uses such a department identifier to search rule database 506 to determine whether the department associated with process 503 is allowed access to the particular resource. In accordance with at least one implementation, a hash table can be used to perform a rule lookup. Depending on the purpose of the system, such internal hash tables can be configured such that the rules introduced are on average one level deep in each hash protocol area, which causes the rule lookup routines to behave in the order of O (1). Accordingly, the rule lookup can be performed relatively quickly and efficiently. Depending on the rules defined for the department in which process 503 is included, access control logic 504 may grant or deny communication access 505 to process 503 . If access is denied, access control logic 504 transfers processing control to exception handling module 510 , which sends an exception (e.g., an error message) back to process 503 and / or stops operation of process 503 .

Referring to FIG. 4 different user space services can be implemented, for which the departments can be used in the illustrated exemplary architecture. The user space services such as For example, the web servers shown in Figure 4 are operated unmodified on the platform, but have department labels associated with them via the command line interface with the security enhancements. The security module 421 is then responsible for applying the prescribed access controls to the user room services based on their department label. It is therefore noted that the user space services can be obtained without having to modify those services in the exemplary implementation shown.

• 1. Einen Aufrufprozess, um Abteilungen zu schalten.
• 2. Einzelne Netzwerkschnittstellen, die einer Abteilungsnummer zugeordnet werden sollen.
• 3. Dienstprogrammfunktionen, wie z. B. Prozeßauflistung mit Abteilungsnummern und Einloggen einer Aktivität für Sicherheitsprüfungen auf Betriebssystemkern-Ebene.

The exemplary implementation of FIG. 4 uses an operating system kernel module (e.g., security module 421 ), which may be referred to as "Ins", to implement bespoke system calls that involve the insertion / deletion of rules or other functions, such as. B. labeling of network interfaces. Such an Ins module implements various interfaces via customized system calls to enable the following:

• 1. A call process to switch departments.
• 2. Individual network interfaces that are to be assigned to a department number.
• 3. Utility functions, such as. B. Process listing with department numbers and logging in of an activity for security checks at the kernel level.

According to certain embodiments of the present Invention in this exemplary architecture are implemented, the main client of the Ins module is the tlutils collection of command line utilities that are described in more detail below.

The Ins module implements an interface to Add / delete rules in the operating system core via customized system calls. It does the translation between simplified rules of a higher level in primitive Forms that are Lookup routines are easier to understand. (This module is through the tlutils user level utilities called to rules in the kernel manipulate.)

In this exemplary implementation Modifications to the Linux standard operating system kernel sources been made to put a label on different Introduce data types as well as access control checks add those close to such labeled data types were made. Each labeled data type contains one additional struct-csecinfo data member that uses to keep a department number. There is Prospect that the labeled data types will be expanded could to keep other security attributes. in the general is adding this data member usually performed at the very end of a data structure, to avoid problems that affect the general refer to the usual procedure for the pointer between two or several structures with different names that start with common entries.

The mere effect of labeling individual ones Operating system kernel resources include a very simple one Implement a departmentalized system in which Processes and the data they generate / consume are isolated from each other. With this exemplary Such isolation should not be implemented in the sense be strictly designed that many hidden channels exist. The isolation in this exemplary Implementation is simply meant to serve obvious forms of an Conflict and / or an interaction between logical to protect different groups of processes.

In at least one implementation, the departments can be sealed from an assumed root identity. The means that individual departments can optionally be "sealed" can be registered to processes in this department before a successful call to setuid (0) - and related system calls, such as B. setuid (0), and also before one Protect executing SUID root binary digits. This for services that can be accessed externally, and generally for buffer overflow attacks that for example, run malicious code can be used. If such Services are initially limited to one Pseudo-user (non-root user) to be operated, and if the department in which it is carried out is sealed, then any attempt to root through either Buffer overflow attacks and / or third-party execution Accepting instructions fails. Note that everyone existing process, which is operated as a root, this will continue to do.

There can be different types of services in the Departments. The operating system kernel Modifications described above are used to support hosting of individual services User level in a protected department. Be next to it now layout, position and conventions when adding or removing services in this exemplary Embodiment of the invention can be used described.

• - eine für die Web-Serverprozesse;
• - eine für den vertrauenswürdigen Gateway-Agenten, der die CGI-Binärzahlen ausführt; und
• - so viele Abteilungen, wie notwendig sind, um jede CGI- Binärzahl ordnungsgemäß zu kategorisieren, während der vertrauenswürdige Gateway die CGI-Binärzahlen in ihren konfigurierten Abteilungen angreift/ausführt.

Individual services can be assigned to a department. However, what an end user sees as a service can actually end up using multiple departments. An example would be to use a department to host an externally accessible web server with a narrow interface to another department that hosts a trusted gateway agent for executing CGI binary numbers in their own individual departments. In this case, at least three departments can be used:

• - one for the web server processes;
• one for the trusted gateway agent that executes the CGI binary numbers; and
• as many departments as are necessary to properly categorize each CGI binary number while the trusted gateway is attacking / executing the CGI binary numbers in their configured departments.

In this exemplary implementation, each department has a name and is located as a chrooted environment under / compt. The examples used in this implementation include:

• 1. /bin - verschiedene Skripten und Befehlszeilendienstprogramme zum Verwalten von Abteilungen können in /bin gemäß bestimmter Implementierungen der vorliegenden Erfindung installiert sein; und
• 2. /etc/tlinux/rules - Dateien, die Regeln für jede registrierte Abteilung auf dem System enthalten, können in /etc/tlinux/rules gemäß bestimmter Implementierungen der vorliegenden Erfindung positioniert sein.

In addition, the following subdirectories also exist:

• 1. / bin - various scripts and command line utilities for managing departments can be installed in / bin in accordance with certain implementations of the present invention; and
• 2. / etc / tlinux / rules - files containing rules for each registered department on the system can be positioned in / etc / tlinux / rules in accordance with certain implementations of the present invention.

• 1. Chroot-fähig sein gemäß ihrer Abteilungsposition /compt/<name>. Es ist jedoch nicht zwingend erforderlich, daß eine Abteilung einen "Chroot" aufweist, um zu starten. Vielmehr ermöglicht dies ein zusätzliches Sicherheitsmerkmal, das nicht in allen Implementierungen der vorliegenden Erfindung erforderlich ist.
• 2. Liefern von /etc/tlinux/init/<name>/startup und /etc/tlinux/init/<name>/shutdown, um die Abteilung, die durch <name> identifiziert ist, zu starten/stoppen.
• 3. Startup- (bzw. Start-) und Shutdown- (bzw. Schließ-)Skripten sind zum Einbringen von Regeln, Erzeugen von Leittabellen, Anbringen von Dateisystemen (z. B. /proc) und anderen Pro-Dienst-Initialisierungsschritten verantwortlich.

In order to support the general start / stop of a department in this exemplary implementation, each department preferably matches some basic characteristics:

• 1. Chroot according to their department position / compt / <name>. However, it is not mandatory for a department to have a "chroot" to start. Rather, this enables an additional security feature that is not required in all implementations of the present invention.
• 2. Provide / etc / tlinux / init / <name> / startup and / etc / tlinux / init / <name> / shutdown to start / stop the department identified by <name>.
• 3. Startup (or start) and shutdown (or close) scripts are responsible for introducing rules, creating control tables, attaching file systems (e.g. / proc) and other pro service initialization steps.

Generally when the department will be visible externally the processes in this department should not by default operated as a root, and the department should be "sealed" after initialization. Sometimes this is due to the way the Forerunner application that is integrated / ported does not possible, in which case it is desirable remove as many skills as possible to prevent that the processes from the "Chroot Prison", e.g. B. cap_mknod, escape.

Since the departments can exist as chrooted environments according to the / compt directory, application integration can require the usual procedures used to ensure that they operate in a chrooted environment. A common procedure involves preparing a cpio archive of a minimally working department that contains a minimal RPM database of installed software. It is common to install the desired application on top of it, and in the case of applications in the form of RPMs, the following steps could be performed:
root @ tlinux # chroot / compt / app1
root @ tlinux # rpm -install <RPM-package-filename>
root @ tlinux # [Change configuration file as required, e.g. B. httpd.conf]
root @ tlinux # [create startup / shutdown scripts in / compt / appl]

The last two steps can be done in the RPM Installation phase can be integrated. Reductions in Disk space can be reached through an examination namely by selectively uninstalling not packages used via the rpm command. Additional entries in The department's / dev directory can be created as needed will, however, will usually be in most cases / dev essentially left alone. Another Automation can be achieved by using a web-based interface with the process described above is provided to all the necessary parameters for each type of application to be installed provide. In general, the compiled binary numbers are no changes necessary unless it is required department-aware variants of such applications to install.

Once the rules are in place (e.g., in the rules database 416 of FIG. 4) to define department containment, such departments can be used by the OS to perform security checks. In this exemplary implementation there is a function "cnet_chk_attr ()" which implements a yes / no security check for the subsystems which are protected in the operating system kernel. Calls to this function are made through the appropriate points in the operating system kernel sources to implement the required departmental behavior. This function is based on the subsystem concerned and can implement slightly different specifications or rule conventions, depending on the subsystem of the operation that is being queried at this time. For example, most subsystems implement simple partitioning, where only objects / resources with exactly the same department number result in a positive return value. In certain cases, however, the use of a non-privilege division 0 and / or a placeholder division - 1L can be used, e.g. B. Division 0 as a default "sandpit" for unclassified resources / services; a placeholder department for oversight purposes, such as B. List processes on the subsystem before shutdown.

As shown in the example of FIG. 5, access control checks are performed at corresponding points in the operating system kernel (by access control logic 504 ). More specifically, in this exemplary implementation, such access control checks are performed using hooks for a dynamically loadable security module 421 ( FIG. 4) that consults a table of rules (rules database 416 of FIG. 4) that indicates which departments on the resources one other department. This is done in a way that is transparent to the working applications.

Each security check can consult a table of rules. Each rule can have the following form:
Source → determination method m [attr] [netdev n]
in which:
Source / target can be the following:
COMPARTMENT (a designated department);
HOST (a fixed IPv4 address);
NETWORK (an IPv4 subnet);
m: supported operating system kernel mechanism, e.g. B. tcp, udp, msg (message queue), shm (shared memory) etc .;
attr: attributes that further qualify the method m; or
n: a named network interface, if applicable, e.g. B. eth0.

An example of such a rule that allows processes in the department named "WEB" to target segments with shared memory, e.g. For example, using shmat / shmdt () from the department named "CGI" would look like this:

COMPARTMENT: WEB → COMPARTMENT: CGI METHOD shm

There are also certain implicit rules that allow some communications in a department take place, e.g. B. could be allowed a process that Process identifier of processes in the same Department reside to see. This enables one Net minimum of functionality in an otherwise unconfigured department. Department 0 is an exception, which is relatively unprivileged and in the more Restrictions apply. Department 0 can be used to the subprocesses at the operating system kernel level (such as the swapper or the outsourcer) or accommodate.

In the absence of a rule that explicitly allows that cross-departmental access fails all these attempts. The net effect of the rules includes the enforcement of a prescribed segmentation of all Departments except those that have been explicitly allowed is on another department's resources access.

The rules are inherently directional, which has the effect of matching the connect / accept behavior of the TCP socket connections. Reference is made to a rule that is used to specify permitted incoming HTTP connections that have the following form:

HOST * → COMPARTMENT X METHOD TCP PORT 80

This rule specifies that only incoming TCP connections on port 80, but no outgoing connections should be permitted, as shown in the example shown in FIG. 6. The directionality of the rules allows the backflow of packets to occur to properly set up the incoming connection without allowing the outgoing connections to take place.

The solution paragraph described above has a number of benefits. For example, it enables one complete control over each supported subsystem and Ability to support unsupported, e.g. B. Hardware Driven Card to compile card transfers. Further sees this approach is a relatively extensive one Namespace partitioning before, without the need to User space commands, such as B. ps, netstat, route, ipcs etc., too change. Depending on the department in which one is located Process currently in progress, the list changes from visible identifiers according to the rules. Examples of namespaces include a process table via / proc, SysV-IPC resource identifier, active, closed and dormant pedestals (all domains) and guide table entries.

It should be noted that the system of Fig. 4 is only an example. The present invention is not limited to any particular divisional or containment scheme. Specifically, the numerous approaches can be used to prevent processes associated with a department from accessing system resources. For example, user level access control can be implemented by several methods. A strace () mechanism can be used to keep track of every system call of a given process. The strace () mechanism examines each system call and its arguments. The strace () mechanism either releases or locks the system call according to the rules defined in a rules database. System call wrapping can also be used. In system call wrapping, rewinder functions examine calls and arguments using a dynamically linked shared library. The wrapper functions also either release or block system calls according to the rules defined in a rule database. Authorization servers at the user level can be used to control access to system resources. Authorization servers at the user level can control access to system resources by providing a controlled data channel to the kernel of the operating system.

• 1. Sicheren Gateway-Systemen, die eine Vielzahl von Diensten, wie z. B. DNS, Sendmail etc., hosten. Die Eindämmung oder die Aufteilung in Abteilungen in solchen Systemen könnte verwendet werden, um das Konfliktpotential zwischen den Diensten zu verringern und die Sichtbarkeit von ausgangsseitigen Hosts auf einer Pro- Dienst-Basis zu steuern.
• 2. Gehäuft auftretenden Vorderseiten (typischerweise HTTP) gegenüber mehrreihigen Ausgangsseiten einschließlich Zwischenanwendungs-Servern. Die Aufteilung in Abteilungen bei solchen Systemen hat den gewünschten Effekt einer Heraus-Faktorisierung eines möglichst großen Teils eines Codes, auf den durch externe Clients direkt zugegriffen werden kann.

One application of the OS architecture described above includes the provision of a secure web server platform with support for contained execution of arbitrary CGI binary numbers and with non-HTTP-related processing (e.g. Java servlets) that are partitioned into separate compartments, each with the bare minimum of rules required to operate. This is a more specific configuration than the general scenario of:

• 1. Secure gateway systems that provide a variety of services, such as B. DNS, Sendmail etc., host. Containment or division into such systems could be used to reduce the potential for conflict between services and to control the visibility of outbound hosts on a per-service basis.
• 2. Frequent front pages (typically HTTP) versus multi-row output pages including inter-application servers. The division into departments in such systems has the desired effect of factoring out as much of the code as possible, which can be accessed directly by external clients.

Referring to FIG. 4, system 400 may e.g. B. have a web server platform, each web server can be arranged in its own department, such as. B. the web department 401 . The following description is illustrative of how the exemplary implementation can be used to split a setting into departments that have an outward Apache web server configured to handle Java servlets or to operate JSP - Delegate files to two separate Jakarta / Tomcat instances, each working in its own department. By default, each department uses a chrooted filesystem so as not to interfere with the other filesystems.

Figure 7 schematically illustrates the Apache processes residing in a department (WEB). This department can be accessed externally using the following rule:

HOST * → COMPARTMENT WEB METHOD TCP PORT 80 NETDEV eth0

The presence of the NETDEV component usually specifies the network interfaces that Apache may use. This is useful when restricting Apache to using only the external interface on the dual / multihome gateway systems. This is to prevent a vulnerable instance of Apache from being used to initiate attacks on outbound networks through inbound network interfaces. The WEB department may communicate with two separate Jakarta / Tomcat instances (TOMCAT1 and TOMCAT2) using two rules, which have the following form:

COMPARTMENT: WEB → COMPARTMENT: TOMCAT1 METHOD TCP PORT 8007

COMPARTMENT: WEB → COMPARTMENT: TOMCAT2 METHOD TCP PORT 8008

The servlets in TOMCAT1 are allowed to access an outgoing host called Server1 using the following rule:

COMPARTMENT: TOMCAT1 → HOST: SERVER1 METHOD TCP. , ,

However, TOMCAT2 is not allowed on any output host access what by the absence of additional Rules is reflected. The operating system core is refuse any attempt at this type of TOMCAT2. This enables the selective change of the view of a output network depending on which services are hosted, and the visibility of outbound hosts on a per department basis.

It would also be worth noting that the previous four Rules are all exemplary for this Configuration is necessary. In the absence of other rules, the Servlets that run in Java VM do not initiate outgoing connections; in particular it cannot used to attack the internal initiate output network on the interface eth1. In addition, it cannot access resources from others Departments (e.g. shared memory segments, UNIX Domain bases etc.) still access directly through remote hosts can be achieved. In this case they are mandatory Apache and Jakarta / Tomcat without recompiling or modifying their Sources have been imposed.

It is pointed out that the departments can be used in a system of the gateway type (host with dual interfaces, which are connected to both internal and external networks). Referring to FIG. 8, a gateway system 800 (connected to both an internal and external network) is shown.

The gateway system 800 hosts several types of services, Service0, Service1,. , ., DienstN, each with a specified output-side host, Host0, Host1,. , ., HostX, HostN, are connected to its function, e.g. B. retrieve records from an output database. Many outbound hosts can exist on an internal network at any time (not all of which should be accessed by the same set of services). It is desirable that when these server processes are compromised, they cannot be used to probe other outbound hosts that should not originally be used by the services. The exemplary implementation limits the damage an attacker can do by limiting the visibility of hosts on the same network.

As shown in Fig. 8, Service0 and Service1 are only allowed to access the network subnet through the network interface eth0. Therefore, attempts to access Host0 / Host1 are successful because they are Subnet1, but then attempts to access Subnet2 through eth1 fail. Furthermore, the serviceN may only access HostX on eth1. Therefore, any attempt to access HostN through ServiceN will fail, even if HostN is on the same subnet as HostX, and any attempt through ServiceN to access any host on Subnet1 will fail. The restrictions can be specified (by rules or guide tables) by the subnet or by the specific host, which in turn can also be qualified by a specific subnet.

Thus, in the exemplary implementation described above, access control checks can be made in the kernel operating system / operating system so that they cannot be bypassed by the user space processes. As further described above, the operating system kernel (of the gateway system) can be provided with a device for attaching a label or a label to each working process / sub-process, the labels / labels fictitiously indicating to which department a process belongs. In certain implementations, such labels can be inherited from a parent process that branches a child. Therefore, a service that has a group of forked children who work together to share the workload, such as B. a group of slave web server processes that have the same labels and are positioned in the same department. The system administrator can e.g. B. Specify rules in the following form:
Department X → Host Y [using the network interface Z] or
Department X → Subnet Y [using the network interface Z]
the processes in a named department X allow access to either a host or a subnet Y, which is optionally restricted by the use of only one network interface called Z. Such rules may be stored in a secure configuration file on the gateway system and loaded into the operating system kernel / operating system setting so that the services that are then started can work. When the services are started, their hiring sequence would specify which department they would initially be positioned in. In this embodiment, the rules are consulted each time a package is sent from or delivered to Department X by imposing additional security checks, preferably in the operating system kernel protocol stack.

In certain implementations there is a separate one Guide table provided per department. As with the previous one Implementation described, each process can have a label or a label (which he inherited from his parents can have). Processes with specific names start with a labeled label marked by a System administrator has been configured. Instead of rules too specify as in the above implementation can be a set of configuration files be provided (one for each department) that the respective Guide table for the department by introducing the Configure the desired control table entries. Because that Gateway system an unnamed number of departments could contain is the guidance table of each department by default, preferably empty (i.e. no entries).

The use of guide tables instead of explicit ones Rules can be achieved because of the lack of one corresponding route is interpreted so that the Fernhost you are trying to reach, supposedly out of reach is. The routes that actually match are in place for the acceptance of the attempt on that remote host access. As with the rules in the first exemplary Implementation described above can Route entries on a per-host basis (IP address Basis) or a per-subnet basis. Alles this is required to make such route entries on a Specify per department basis to be the same Functionality like the first exemplary To achieve implementation.

II. Department management according to various Embodiments of the invention

Above was an overview of an exemplary OS architecture for implementing departments intended. It should be noted that certain Embodiments of the present invention in any OS and a departmental architecture can be implemented and therefore not to the one described above exemplary implementation are limited.

Given that the departments have one important security mechanism in trustworthy OS's create, it is desirable to have an efficient and user-friendly mechanism for managing such departments to own. For example, it could occasionally be used for a user such as B. a system administrator, it would be desirable to manipulate departments, e.g. Legs add a new department, remove a department, renaming a department etc. In addition, it can be used for be desirable for a user to manipulate rules, that define departmental containment. Such Manipulation of departments and the manipulation of Rules that define the containment of such departments, are intended in the term used herein "Department management" should be included.

There are several problems with traditional departmental management techniques. A prior art method for managing departments is shown in FIG. 9. The departments are traditionally defined in a configuration file that the OS uses after booting a computer system to determine the departments that are available in such an OS. As shown in Fig. 9, the management of departments in prior art systems, e.g. For example, manipulating a department so that a user (e.g. system administrator) edits the configuration file in which the departments are defined (step 901 ). Likewise, manipulating rules that define departmental containment requires that a user edit the configuration file that contains such rules. That is, at step 902, a user can use a text editor to view and edit a configuration file to manipulate the departments and / or the rules.

Even to edit the configuration file, the correct configuration file must of course first be determined, localized in the system files and opened for editing. Once the configuration file is open for editing, the user can edit the file (e.g. insert and / or remove text in the file) to manipulate the departments and / or rules. For example, to rename a department, the user would have to search the configuration file, which may have a large amount of text, and edit the appropriate sections of the configuration file to change a department's name. As another example of adding a department, the user would have to edit the configuration file by including appropriate text in it to define a new department to be created. Once the user edits the configuration file, the edits made to the configuration file must be saved in step 902 . In order for the changes made to the configuration file to be applied within the system, a system boot is typically required (step 903 ). More specifically, the systems typically access the configuration file after booting, and the changes made to the configuration file during system runtime are not applied to the system until it is booted.

The above described method for managing Divisions are problematic for several reasons. At first Position requires such a departmental management process state of the art that a user a Configuration file edited. Given the size and amount of Information contained in such a configuration file can be included is with proper editing the configuration file to achieve a desired one Result in extensive complexity / difficulty connected. In addition, editing one Configuration file an inefficient method of manipulating Departments because a user has the appropriate Determine the configuration file to be edited, the Open the file and edit the file properly (the can contain a large amount of information that the User needs to parse to make sure that it has been properly edited in order to to achieve the desired result). It also requires one Prior art methods typically that System is booted so that the configuration file changes made to the operation of the system be applied. In addition to inefficiency and undesirable Interruption due to such a system boot Errors that occurred when editing the configuration file can only be discovered when such a boot is executed has been. Furthermore, if one in the configuration file error encountered is fatal in that the system can no longer be booted, then you may have to System rescue can be performed by the entire OS is recharged.

The embodiments of the present invention facilitate the requirement to edit a configuration file for managing departments by providing utilities that are used in the user space of an OS (e.g. command line utilities) that enable department management. According to at least one embodiment, z. For example, command line utilities are provided that allow a user to manipulate departments by performing such tasks as creating, renaming, or removing departments. Likewise, in certain embodiments, the rules that define departmental containment can be manipulated through command line utilities. In addition, the utilities executed in accordance with certain embodiments of the present invention allow departments and rules to be dynamically manipulated. That is, no system boot is required for the actions requested by using the utilities to be applied while the system is operating. Fig. 10 shows an exemplary Abteilungsverwaltungsfluß according to at least one embodiment of the present invention. As shown, a user to manipulate a department and / or rule must run a command line utility in step 1001 and the actions generated by such a utility are dynamically applied during operation of the system in step 1002 .

According to an embodiment of the present invention Department management utilities are provided that include a number of command line tools to Create, manage and remove departments. A exemplary list of utilities included in at least an embodiment of the present invention Is available, as well as an overview of the Functionality that is performed by each utility provided below. It should be noted that the names of the utilities in different Embodiments can change without their Change functionality. Therefore, the present invention is not to specific utilities described below limited, but rather serve such exemplary Utilities as examples that the revelation play, causing many other types of Department management utilities are enabled where it it is desirable that they be within a given system be implemented.

As described in more detail below, according to the various embodiments of the present Invention a series of departmental administrative Utilities provided. According to certain Embodiments have such departmental management Utilities command line utilities that may be referred to herein as "tl" utilities (e.g. "tlrules" and "tlcomp" utilities, below are described). Different examples of such Department rule manipulation utilities and to manipulate departments according to the Embodiments of the present invention are below described. However, it should be noted that such utilities, although specific utilities and their functionality are described as examples serve that reflect the revelation, whereby many other departmental management utilities that can be implemented in a similar manner.

Exemplary utilities for manipulating department rules

According to at least one embodiment of the present invention, "tlrules" utilities are provided for manipulating departmental rules. Such "tlrules" utilities can include command line utilities for adding, deleting, and listing rules. In the exemplary implementation described above in FIG. 4, such "tlrules" may be implemented as command line utilities 440 that may be executed to maintain departmental rules (e.g., in rules database 416 ) via a / proc / tlx interface to manipulate, which is provided by an operating system core loadable module. The rules can either be entered on the command line or read from a text file.

According to the exemplary implementation described above, the rules can take the following format:
<rule> :: = <source>[<port>] → <destination>[<port>]
<method list><netdev>
if:
<identifier> = = (<compartment> _ <host> _ <net>) [<port>]
<compartment> = = "COMPARTMENT"<comp_name>
<host> = = "HOST"<host_name>
<net> = = "NET"<ip_addr><netmask>
<net> = = "NET"<ip_addr>"/"<bits>
<comp_name> = = a valid name of a department
<host_name> = = a known host name or IP address
<ip_addr> = = an IP address in the form of abcd
<netmask> = = a valid netmask in the form abcd
<bits> = = The number of leftmost bits in the netmask. , , from 0 to 31
<method list> = = A list of comma-separated methods (in this exemplary embodiment, the supported methods include: TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and ALL.

A department management utility that can be used to manipulate departments is a command line utility that can be executed to set rules for controlling communication (or access) of a department with a resource (e.g., with other departments and / or Network interfaces). As described above, such a command line utility may be referred to as "tlrules" in one embodiment, and the use of such a utility may e.g. B. take the form of "tlrules, rule description '". The rules are e.g. B. set according to an embodiment to control the communication of departments with each other and with the network interfaces. The tlrules utility can be used to perform such tasks as listing all rules currently configured on the system, loading rules from a file, loading rules from the command line, and deleting rules that are contained in a file or are specified on the command line, for example. In the exemplary implementation shown in FIG. 4, the tlrules and associated command line utilities default to finding the department map file "cmap.txt" (in stable storage 405 ) in the / etc / tlinux / conf directory.

To add a rule, the user can type "tlrules - a <filename>" (to read a rule from a text file if <filename> is a file containing rules in the format described above) or "tlrules - a rule" (to enter a rule on the command line). For example, to add multiple rules contained in a file, the "tlrules - a rulefile.txt" command can be run, thereby adding rules contained in the "rulefile.txt" file. On the other hand, to add a rule that allows the "dev" department to query the DNS server on host 192.168.10.3, the following command can be run:
tlrules - a "COMPARTMENT dev → HOST 192.168.10.3 PORT 53 METHOD udp NETDEV any"

To delete a rule, the user can enter "tlrules - d <filename>" or "tlrules - d rule" or "tlrules - d ref" (in this form, a rule can only be deleted by its reference number, which can be obtained by listing the Rule is output using the tlrules-1 command, which outputs rules in a standard format with the rule reference output as a comment at the end of each rule). As another example, to query the rule that allows the "dev" department to query the DNS server on host 192.168.10.3, the following command is executed:

tlrules - d "COMPARTMENT dev → HOST 192.168.10.3 PORT 53 METHOD udp NETDEV any"

As another example, all the rules in the file To delete "rulefile.txt", the command "tlrules - d rulefile.txt ".

In at least one embodiment Syntax errors or semantic errors detected by tlrules an error report, and the command ends immediately, and no rules are added or deleted. If a text file is used to enter the rules the number of lines of the faulty line in the Error message found.

• 1. "tlnetcfg setdev eth0 0xFFFF0000" - stellt die Abteilungszahl der eth0-Netzwerkschnittstelle auf 0xFFFF0000 ein.
• 2. "tlsetcomp WEB - p cap_mknod - c /bin/bash" - schaltet zur Abteilungs-WEB um, entfernt die cap_mknod- Fähigkeit und ruft Bash auf.

Another command line utility provided by this exemplary embodiment of the present invention is known as "tlutils" which provides an interface with the Ins operating system kernel module (described above in FIG. 4). Its most important function is to provide various administrative scripts with the ability to span processes in a given department and set the department number of interfaces. Examples of this use include:

• 1. "tlnetcfg setdev eth0 0xFFFF0000" - sets the department number of the eth0 network interface to 0xFFFF0000.
• 2. "tlsetcomp WEB - p cap_mknod - c / bin / bash" - switches to the department WEB, removes the cap_mknod capability and calls Bash.

Exemplary utilities for manipulating departments

According to at least one embodiment of the present Invention are the "tlcomp" utilities for Manipulating a department provided. Such "tlcomp" - Utilities can use command line utilities such as: B. for adding, deleting and renaming departments exhibit. Various specific examples of such tlcomp utilities are described below.

A first department management utility that can be used to manipulate departments is a command line utility for adding / creating a new department in a system. In one embodiment, such a command line utility may be called "tlcompadd" and the use of such a utility may take the form of "tlcompadd [compartment name]" or "tlcompadd [option flags] [compartment]", for example. In this example, tlcompadd adds a new department to the system with a specified department name as an argument. More specifically, the department with the specified name of the stable memory database (stable memory 405 of FIG. 4) is added to the system and provides a reference in memory at the kernel level (memory 421 A of FIG. 4). In at least one embodiment, the department is immediately available to the system for use as soon as it has been created via the tlcompadd command. As a result, the departments can be dynamically created from the user space of the OS without requiring the system to boot so that the created departments are available for use.

In accordance with at least one embodiment, the department name can have a hyphen (-) and underscore (_) in all alphanumeric characters (AZ and 0-9). The department name specified by the user provides a user-friendly representation of the department. However, as described in the exemplary implementation of FIG. 4, in at least one embodiment, an internal database is maintained both in memory (e.g., memory 421 A in FIG. 4) and stable storage that maps the user-friendly name to one Maps number that identifies the department (e.g., a text file "cmap.txt" 405 in Fig. 4).

When implemented in an OS architecture like that, described above, it may be advantageous certain departments in a chroot filesystem produce. Consequently, in at least one embodiment, in addition to creating a department with a specific one Department names, an argument (or an option flag) be provided that a chroot filesystem and Initialization scripts generated for the departments. The purpose of this is that there is an additional layer of security in that provides that a process (e.g. an application) that is in a department runs in a chroot area of the File system can run, which means everything outside the chroot Area of the file system for the processes in the department not available. Enable initialization scripts starting processes in the department (for a see tlcompstart below for a more detailed explanation).

Another departmental management utility designed for Manipulating departments can be used is a Command line utility to rename a existing existing department. According to one Embodiment can do such a command line utility Be called "tlcompren", and the use of such Utility can e.g. B. the form of "tlcompren [current name] [new name] ". Named in this example tlcompren that has a specified current Has department names and a new department name as arguments, the department that has a "current name" argument into a "new name" argument. More specifically remains in accordance at least one embodiment, the internal number that the department represents the same during the user friendly name of the department is changed. If the Department that is renamed a chroot filesystem and Has initialization files, these are also included Renamed to a "new name" as required. At least one embodiment is renaming a department around a dynamic process, so that after the Executing the tlcompren command, immediate references to the "new name" can be made.

Another departmental management utility designed for Manipulating departments can be used is a Command line utility to remove an existing one Department out of the system. According to one embodiment can such a command line utility "tlcomprm" be called, and the use of such Utility can e.g. B. the form of "tlcomprm [option flags] Accept [compartment name] ". Removed in this example tlcomprm, which is a specified department name has the specified department from the system. According to at least one embodiment can be an optional Flag to specify that all chroot Files and initialization files for such Department can also be removed. Preferably removed this command both memory at the kernel level as well as the stable storage references to one Department. In addition, at least one Embodiment the removal of a department a dynamic Process so that after executing the tlcomprm command the Name of the removed department can be reused (e.g. when adding a new department with a such names) if desired.

Another departmental management utility designed for Manipulating departments can be used is a Command line utility to switch one current department to an identification department. Hence if a user (e.g. system administrator) is currently in a special department, the user can use such a command line utility to become a other "destination" department. According to one Embodiment can Command line utility can be called "tlsetcomp" and use a such a utility can e.g. B. the form of "tlsetcomp [destination compartment] [option flags] [command to execute] ". In this example, tlsetcomp switches the has a destination department name that logs in Process of the user from a current department to one Determination Division. By default, the User login shell when running in the "Determination department" and without options simply to the new one Department around. Optionally, an argument such as B. -p, be included to some skills for example Drop or add "Destination Department". For example, the command "tlsetcomp [destination compartment] -p - chown "can be used to Process of a user from a current department a determination department, but the Determination department does not execute the "chown" command change the ownership of files. According to at least one embodiment include the Dropping skills available options those which is usually in the Linux / Unix file "Capabilities.h." are located.

The tlsetcomp command can also be used to to switch departments as well as a command in the Identification department. For example, the Tlsetcomp [destination compartment] -c / bin / ps-ef command to be used to switch to the identification department and execute the ps command to run all processes in the List "Destination Department".

Another departmental management utility designed for Manipulating departments can be used is a Command line utility that can be run to the current department in which the login process of the User is included. According to one Embodiment can do such a command line utility be called "tlgetcomp", which is the current department in which is the user's login shell displays. Consequently, a user can e.g. B. the tlgetcomp- Execute command to display the department in which the user's login shell is currently located. The User can then use the tlsetcomp command to go to a to switch to another department if the tlgetcomp- Command then runs the new department the user has switched to.

• 1. Starten eines abteilungsspezifischen Prozesses, wie z. B. eines Webservers;
• 2. Laden der Kommunikationsregeln, die für die Abteilung spezifisch sind;
• 3. Konfigurieren von Dateisystem-Schutzregeln, die für die Abteilung spezifisch sind; und
• 4. Versiegeln der Abteilung, um die Ausführung von suid- Skripten oder den Übergang zur Wurzel von Nichtwurzelprozessen in der Abteilung zu stoppen.

Another department management utility that can be used to manipulate departments is a command line utility for executing a department startup script. Such a department start script can initiate at least some of the following tasks:

• 1. Start a department-specific process, such as B. a web server;
• 2. Load communication rules that are specific to the department;
• 3. Configure file system protection rules specific to the department; and
• 4. Seal the department to stop the execution of suid scripts or the transition to the root of non-root processes in the department.

As described above, according to one Embodiment such a position of the start script for a department: / etc / tlinux / init / <compartment name> / startup. According to one embodiment, such Command line utility to initiate a startup script a department called "tlcompstart", and the Using such a utility can, for example Take the form "tlcompstart [compartment name]". To the For example, the command "tlcompstart web" runs the start script for the "web" department that goes to the chroot area of the File system for the department "Web" can switch and then the processes that deliver websites start up.

• 1. Entsiegeln der Abteilung;
• 2. Entladen der Dateisystemregeln;
• 3. Entfernen der Kommunikationsregeln; und
• 4. Stoppen des anwendungsspezifischen Prozesses, wie z. B. eines Webservers.

Likewise, a department management utility that can be used to manipulate departments is a command line utility that executes a shutdown script to shutdown a department. In one embodiment, such a command line utility may be called "tlcompstop", and the use of such a utility may take the form of "tlcompstop [compartment name]", for example. The tlcompstop utility typically reverses the tlcompstart command described above. For example, tlcompstop can initiate one or more of the following tasks:

• 1. Unseal the department;
• 2. Unload the file system rules;
• 3. Remove the communication rules; and
• 4. Stop the application-specific process, such as B. a web server.

As described above, according to at least an embodiment such a position of the shutdown Scripts for a department: / etc / tlinux / init / <compartment name> / shutdown. The start and shutdown Scripts can contain text and certain commands Include commands that are part of the department utilities, such as B. tlrules.

Another departmental management utility designed for Manipulating departments can be used is a Command line utility that can be run to all departments currently contained in one system are to be listed. According to one embodiment, a such command line utility "tlcompstat." called become. Similarly, a departmental administration Utility can be provided that can be run to all processes that work on the system (or ) and list the name of the department in which every department is running. According to one Embodiment can do such a command line utility "Tlprocstat." to be named.

Another departmental management utility designed for Manipulating departments can be used is a Command line utility executable to a Seal department. According to one embodiment can such a command line utility "tlcompseal" be called, and the use of such For example, utility can take the form "tlcompseal Accept [compartment name] ". This utility delivers additional security feature. By sealing one Department becomes the ability for processes in the department to go to a root (e.g. "su-root") or suid- Execute programs or scripts, locked. The command "tlcompseal web" seals z. B. the web department, so that no process carried out in it to one Root can pass over.

On the other hand, a utility program can be provided to to unseal a department. According to one Embodiment can do such a command line utility Be called "tlcompunseal" and the use of such For example, utility can take the form "tlcompunseal [compartment name] ". This utility will executed to unseal a sealed department the transition to a root (eg "su root") and the Allow suid programs or scripts to run when this is the file system access control lists (ACLs; ACL = access control list).

Yet another department management utility, the can be used to manipulate departments a command line utility that will run can to an input file that has a department name and contains a number mapping in the OS. According to one Embodiment can Command line utility can be called "tlregcompas" and use Such a utility can take the form, for example Accept "tlregcompas [file name]". This command can can be used for example during system booting. At a Embodiment are e.g. B. all departments in Operating system kernel level storage and in a stable Storage saved in a file. If the system boots, the tlregcompas command can be used to load the stable storage entries into memory.

In at least one embodiment, they all cause Syntax errors or semantic errors caused by tlcomp be detected, an error report, and the command will hired immediately and no departments are manipulated (e.g. added or deleted).

Various utilities, the examples of various command line utilities are above described by an OS according to various Embodiments of the present invention may be available can. Accordingly, various allow Embodiments of the present invention that the Department management (e.g. manipulation of rules and / or Departments) from the user room in more efficient and can be run in a user-friendly manner. One user z. B. do not edit a configuration file in the such rules and / or departments are defined, but can run command line utilities instead, a desired administrative action (e.g. add or Delete a rule and / or department). It it is also pointed out that further Department management utilities in addition to those mentioned above are described in certain embodiments of the present invention may be included. Besides those Command line utilities that are featured above Manipulating departments are described for example command line utilities to run a such manipulation, such as. B. rescaling one existing department, adding a process to a Department and removing a process from a department, be provided.

In addition to enabling an efficient and user-friendly procedure for managing departments, can in certain embodiments error prevention checks made by the departmental management utilities to help a user make mistakes avoid using it otherwise while executing the Department management would face. Traditionally must a user e.g. B. edit a configuration to a Add department in a system. If the user makes a mistake in the configuration file, e.g. B. Duplicate a department name (i.e., rename the department added department like an existing one Department), such an error will not the user displayed. Furthermore, the in a configuration file in Prior art systems changes typically only effective after the system boots has been. Consequently, the user can only post the error discover a boot of the system, or alternatively can the error can be fatal in that the system does not boot what requires the operating system must be reinstalled on the system.

Examples of error prevention checks by the Department management utilities in certain Embodiments of the present invention executed can include, for example, the review of a duplication of the department name and the Check that there is enough memory. Although these exemplary error prevention tests below are described in more detail, that to support the user many other types of Error Prevention Checks by the Departmental Management Utilities in various embodiments can be executed. In one embodiment the duplication of the department name by a Utility checked (e.g. the tlcompadd or tlcompren- Utilities) that calls Ins to verify that a name is not already in the "Ins" security module exist. In addition, the one just performed Utility when adding a new department (e.g. with the tlcompadd command) to check ensure that there is sufficient memory to store the "Ins" security module the new name and Add number mapping.

As a security check, only users with a proper permission all or all of the Department management utilities described above (e.g. to manipulate rules and / or departments) To run. According to at least one embodiment the user permission to use such departmental Utilities such as adding a department etc. execute when the user is at the root of the system and a or set for the user ID has set "admin bit" set. The admin bit is a special bit that is part of the login process of the User is set. The bit can only be done by logging in through secure channels that are controlled become. Such secure channels are through a secure one Shell connection "SSH" (SSH = secure shell) or by physical Log in to the machine's console included.

Various embodiments of the present invention further improve the efficiency of department management by allowing rules and / or departments to be dynamically manipulated (as described above) without requiring the system to boot, thereby reducing the actions taken through the utilities have become effective in the system. As described above in Fig. 9, prior art systems generally require a user to edit a configuration file to manipulate departments and / or department rules, and the system typically must be booted before the changes made to the Configuration file have been made to take effect in the system. Various embodiments of the present invention enable utilities to be used to manipulate departments and / or departmental rules in a dynamic manner that does not require system booting for such manipulation to take effect in the system.

For example, in at least one embodiment, a configuration file includes text (e.g., commands, etc.) that provides details that allow the system to boot with the correct number of departments. That is, the configuration file is used as a reference to booting the system to enable the system to identify the departments that exist on it. If, during system runtime, a user uses a department management utility to add a new department (e.g., using the tlcompadd command line utility described above), such a utility is run to the number representing the new department automatically and stores such a number and the user-friendly name of the department in memory 421 A (of FIG. 4). At this point, a user with the correct permission is immediately able to query the department by name and can add rules for such department. The utility can also update the configuration file to reflect such departmental manipulation (e.g. adding a new department) so that if the system were to be booted it would recognize the correct state of the departments, thereby reducing the manipulation (s ) that have been made since the previous boot are reflected. Similarly, departmental rules can be manipulated in a dynamic manner. The department rules can e.g. B. added via the "tlrules" command described above, which can be executed to add the desired rule for a department to the rule database 416 ( FIG. 4), and such a rule added will therefore take immediate effect. After an access request has been received via the "tlrules" command after adding a rule, e.g. For example, security module 421 approaches rule database 416 , which includes the newly added rule that can be used to determine whether access is allowed for the requesting department. Therefore, the utilities are preferably executable to enable dynamic behavior of the department manipulation actions without the need to boot the system.

Referring to FIG. 11, an exemplary work flow diagram for creating and then renaming a department according to an embodiment of the present invention is shown. In operation block 1101 , the "tlcompadd comp" command is executed to create a new department called "comp." add. As described above, according to at least one embodiment, the effect of executing this command comprises generating a number that is used internally to refer to the new department named "comp." To refer. In at least one embodiment, the department "comp" and its generated number are stored in a configuration file and copied to the system kernel level memory to make the new department available in a dynamic manner.

The command "tlcompren comp comp2" is then carried out in block 1102 of this example in order to rename the department "comp" to "comp2". In accordance with at least one exemplary embodiment, renaming a department changes the name in the configuration file and the name-to-number mapping in the operating system kernel level memory.

Referring to FIG. 12, another exemplary work flow diagram is provided that provides an example of switching a user's login process from one department to another in accordance with an embodiment of the present invention. In the example of FIG. 12, operation block 1201 is executed first by executing the "tlgetcomp" command. The "tlgetcomp" command is executed to display the current department, which in this example is returned as "system". At block 1202 , the "tlsetcomp web" command is executed to switch from the "System" department to the "Web" department. It is pointed out that for the actual success of such a switch from the "system" department to the "web" department, the "web" department must exist on the system (e.g. added previously via the tlcompadd command is). In accordance with at least one embodiment, a process structure includes a field that represents the department to which the process belongs (or in which it is contained). For example, if a user logs on to the console by default in a Linux system, the log-in process structure of the user has an additional field called "dev" (ie department "dev"). When the user then starts a web daemon, the field in the process structure will also have the designation "dev", since it is a child process that was created by the user logging in process. In at least one embodiment, the access control uses the name provided in the department that identifies the field of the process structure. For example, when a syscall is received by a process with a department identifier of "dev", a lookup is performed by security module 421 to confirm whether "dev" is allowed to perform the requested syscall. When the user runs tlsetcomp, the department-identifying name is changed dynamically in the process, and the rules are then applied to the department.

Furthermore, in at least one embodiment, the switch from one department to another department as a result of the command line utility (e.g., "tlsetcomp") executed occurs in a manner that is transparent to the user / application using such a command line utility is. In accordance with at least one embodiment, such a change of departments occurs dynamically so that when the "tlgetcomp" command is executed again in block 1203 , the department name "web" is displayed as the current department. Therefore, the "tlgetcomp" command executed in block 1203 confirms that the current department is now "web" and not "system".

As another example, another exemplary work flow diagram is provided in FIG. 13 that provides an example of using a department management utility to switch to another department and execute a command therein. From time to time, it may be desirable to initiate the execution of a process in one department from another department. For example, a web server may be included in a system that should be running within the "web" department, but the user's login process may currently be in the "system" department. Unlike switching to the web department to start the web server, it may be more efficient to allow the user to initiate the web server in the web department from the system department. Therefore, at least one embodiment of the present invention provides a command that can be used to effectively move from a first department to a second department, execute a desired command in the second department, and return to the first department.

In the example of FIG. 13, work block 1301 is executed first by executing the "tlgetcomp" command. The "tlgetcomp" command is executed to display the current department, which in this example is returned as "system". Therefore, the current department of the login process is "System" (for example, the user's login process has a label that reads "System"). In block 1302 , the command "tlsetcomp web -c / bin / httpd - start" is executed. The command from block 1302 is executed to switch from the "System" department to the "Web" department, to execute the command to start the web server daemon, whereupon tlsetcomp ends and the web server daemon on the web Department leaves working. In accordance with at least one embodiment, the "tlsetcomp" command is executed in the "System" department to initiate a child process (the web daemon), but shortly before it changes the label in the process structure from "System" to "Web" to start the web daemon as a child in the web department. It then returns to the "system" before the "tlsetcomp" command is terminated. Therefore, when the "tlgetcomp" command is executed again in block 1303 , the department name "System" is displayed as the current department.

Claims (24)

1. A method for managing a processor-based system ( 400 ), the method comprising the following steps:
Implementing at least one department ( 401 ) to contain at least one process executable on the processor-based system; and
Providing at least one operating system command line service facility ( 404 ) that is executable to manipulate the at least one department ( 401 ). 2. The method of claim 1, wherein the at least one department ( 401 ) defines whether the at least one process contained therein is allowed access to special system resources. 3. The method of claim 1 or 2, wherein the at least one process is labeled to identify the department ( 401 ) in which it is contained. 4. The method according to any one of claims 1 to 3, wherein the at least one command line service device ( 404 ) is executable to manipulate the at least one department ( 401 ) comprises at least one command line service device ( 404 ) that is executable to at least one type of departmental manipulation selected from the group consisting of the following steps:
Adding a New Department ( 401 ), Renaming an Existing Department, Removing an Existing Department, Rescaling an Existing Department, Adding a Process to a Department, and Removing a Process from a Department. 5. The method according to any one of claims 1 to 4, wherein the step of implementing comprises the following step:
Define the at least one department ( 401 ) in at least one configuration file. 6. The method of claim 5, wherein the at least one command line service facility ( 404 ) is executable to manipulate the at least one department ( 401 ) without requiring a user to edit the at least one configuration file. 7. The method according to any one of claims 1 to 6, wherein the step of implementing comprises the following step:
Providing at least one rule that defines containment by the at least one department ( 401 ) in at least one configuration file. 8. The method of claim 7, further comprising the step of:
Providing at least one command line service facility ( 404 ) executable to manipulate the at least one rule. The method of claim 8, wherein the at least one command line service device ( 404 ) executable to manipulate the at least one rule comprises at least one command line service device executable to perform the at least one type of rule manipulation resulting from the Group is selected, which consists of the following steps:
Add a new rule for a special department ( 401 ), remove an existing rule for a special department and list all rules for a special department. 10. System with the following features:
at least one processor;
an operating system that implements at least one department ( 401 ) that can be associated with at least one process executable on the system;
at least one configuration file defining the at least one department ( 401 ); and
means for performing management of the at least one department ( 401 ) without requiring the user to edit the at least one configuration file in which the at least one department is defined. 11. The system of claim 10, wherein the means for performing administration of the at least one department ( 401 ) further enables administrative actions initiated through the means for performing administration to be performed dynamically without requiring the system must be rebooted for the administrative actions to take effect in the system. 12. The system of claim 10 or 11, wherein the step performing management of the at least one Department the step of manipulating the least has a department. 13. The system of claim 12, wherein the step of manipulating the at least one compartment ( 401 ) comprises at least one type of manipulation selected from the group of the following steps:
Add a new department, rename an existing department and remove an existing department, rescale an existing department, add a process to a department and remove a process from a department. The system of claim 12 or 13, wherein the means for performing management of the at least one department ( 402 ) further enables manipulation of the at least one department ( 401 ) to be performed dynamically without requiring the system to be rebooted must be done for the department manipulation to take effect in the system. The system of any of claims 10 to 14, wherein the step of performing management of the at least one department ( 401 ) includes the step of switching from a first department to a second department. 16. The system according to any one of claims 10 to 15, further comprising:
at least one configuration file comprising at least one rule defining containment of the at least one department ( 401 ). 17. The system of claim 16, wherein the step of performing management of the at least one department ( 401 ) comprises the step of manipulating the at least one rule. 18. The system of claim 17, wherein the step of manipulating the at least one rule comprises at least one type of manipulation selected from the group of the following steps:
Add a new rule for a special department ( 401 ), remove an existing rule for a special department and list all rules for a special department. 19. The system of any one of claims 10 to 18, wherein the means for performing management comprises at least one operating system command line service means ( 404 ) executable to manage the at least one department ( 401 ). 20. A computer readable medium comprising instructions that can be executed by a processor, the computer readable medium having the following features:
a library of software functions for managing at least one department ( 401 ) implemented by an operating system, wherein at least one process can be assigned to the at least one department and the at least one department has accessibility to resources for the at least one process that is assigned to it is defined; and
wherein the library of software functions includes at least one command line service facility ( 404 ) executable to manipulate the at least one department ( 401 ). The computer readable medium of claim 20, wherein at least one command line service device ( 404 ) executable to manipulate the at least one department comprises at least one type of manipulation selected from the group of the following steps:
Add a new department, rename an existing department, remove an existing department, rescale an existing department, add a process to a department and remove a process from a department. 22. Computer-readable medium according to claim 20 or 21, which has at least one configuration file on one System is implemented to at least one Define department. The computer readable medium of claim 22, wherein the at least one command line service facility ( 404 ) is executable to manipulate the at least one department ( 401 ) without requiring a user to edit the at least one configuration file. 24. Computer-readable medium according to one of claims 20 to 23, in which at least one rule is implemented in order to define the accessibility to resources which are permitted for the at least one department ( 401 ), and in which the library of software functions furthermore at least a command line utility ( 404 ) executable to manipulate the at least one rule.