DE10229114B4 - System and method for managing departments in a trusted operating system - Google Patents

Abstract

method for managing a processor-based system (400), wherein the System by labeling individual kernel resources into several departments (401, 402, 403) that are in at least one configuration file are defined, the departments (401, 402, 403) designate those resources on which in departments are allowed to access contained processes, where the resources are network interfaces and / or processes having, in the compartments (401, 402, 403) contained Processes for accessing system resources according to the rules, that are stored in a rulebase (416) are restricted, the method comprising the step of providing at least a utility (404) executable to at least one To manage department (401, 402, 403).

Description

The The present invention relates generally to computer containment and more specific to a system and procedure that involves an administration of Enable departments in an operating system.

An operating system (OS) is rightfully the most important program that runs on a computer system because the OS is used in running all other programs (commonly referred to as "applications") For example, an application may call an OS routine (eg, via a system call) to store a particular file, and the OS may communicate with the input / output chassis (BIOS BIOS = basic input / output system), dynamic main libraries, drivers, and / or other components of the computer system to properly store the particular file Many different OSs have been developed in the art, such as HP- ^UX® , Linux ^TM , MS- ^DOS® , OS / ^2® , ^Windows® , Unix ^™ , System 8, MPE / iX, Windows ^CE® and Palm ^™ .

1 shows an exemplary system 100 that is an OS 101 includes. As shown, the OS 101 such tasks, such. B. recognizing an input from the keyboard 106 and the mouse 104 , sending an output to the display screen 107 and controlling peripheral devices, such as A disk drive 103 and a printer 105 , To run. Some OSs have relatively complex functions built in; Fax, Data Processing, Disk Compression, and Internet Browser. In general, OSs provide a software platform on which other programs, e.g. B. an application 102 , can be performed. Application programs are generally written to be executed on a particular OS and, therefore, the particular OS implemented on a computer system can largely dictate the types of applications that can be run on such a computer system.

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

In addition to those described above, the OSs can have many responsibilities. For example, the OSs may also have the responsibility of ensuring that different applications and users operating at the same time do not interfere with each other. The OSs may also be responsible for security, such as: To ensure that unauthorized users are not accessing the system (or at least forbidden portions of the system). For example, "trusted" (secure) OSs that include security mechanisms therein have been developed in the art, such as those designed to handle and process classified governmental (e.g., military) information. One type of security mechanism that may be implemented is testing operating system routines (which may be referred to as "events") used by applications and / or users. For example, the OSs generally collect the audit data relating to the use of an operating system routine called via a system call (or "syscall") made by an application. For example, assume that an application makes a system call To open a special file, a test program in the operating system can use such check data for the system call, such as the date and time when the system call was made, the name of the file to be opened, and the result of the system call (eg, system file successful or Such checking may be carried out as part of the security mechanism included in the OS, for example, Other security mechanisms may be in addition to or in lieu of such Be implemented test characteristic.

specially include trusted OSs, including those without limitation Hewlett-Packard CMW (compartment mode work station), Hewlett-Packard's Virtual Vault, Sun Trusted Solaris, and SCO CMW belong, in general Security mechanisms, such. B. checking at least safety-relevant Events.

As As is well known to those skilled in the art, the central module is one OS of the kernel. In general, it is this is the part of the OS that loads first and is typically in the Main memory is located. Typically, the operating system kernel for such Tasks such as memory management, process and task management and disk management, responsible. The operating system kernel of a OSs are common for one large part the security measures, which are provided by such an OS, responsible.

The Way in which security measures are implemented in an OS are often a system administrator's troubles / complexities Effort in managing a system, in addition to the execution of such Tasks like adding new applications to the system etc. etc. belongs. That means you often get up System administrators leaves when it's about a proper configuration of system resources and / or security mechanisms in proper / secure Way goes. For example, the applications are electronic Services are generally demanding and contain many Lines of code that are common have one or more bugs, causing the applications vulnerable for attacks become. If an electronic service is offered on the internet, he is a big one Group of potential attackers exposed to the service Can probe vulnerabilities and as a result of these bugs it has become known that security breaches occurred. Once an application has been compromised (eg by a buffer overflow attack), It can be done in several different ways by an attacker used to violate the security of the system.

It More and more single machines are used to provide multiple services to host at the same time (eg ISP, ASP, xSP service provisioning), and therefore it is becoming more and more important that not only safety the host platform is protected from exploitable attacks, but also that the Applications in the event of an attack are adequately protected from each other.

A the most effective ways to protect against an OS threat, operating system core-enforced or forced controls because they are implemented in the kernel Controls not by an application or a user from the User room can be turned off or undermined. typically, are the controls in all applications, regardless of the grade the and / or the desired Security of every single application code, applicable. Corresponding In some cases, the controls may become unnecessary used (they can over-protect certain applications).

in the general can two basic security objectives are identified at the system level desirable are an adequate one Protection against application hazard and their effects. First, applications should be in highest possible Dimensions protected from attack become. For example, exposed interfaces to the applications should be as close as possible should be kept, and access to such interfaces should be well controlled. Second, the extent of the damage, an endangered application on the system can be limited to the greatest possible extent.

The above two requirements can be achieved by using a "containment". In general, an application is contained when strict in the same Checks are made as to which equipment she can access and what kind of access she has, too if the application is compromised has been. A containment protects an application also against external attacks and interference. Therefore the containment functionality has the potential many of the potential exploitation actions of an attacker, at least to reduce.

• 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 endanger an application can be broadly categorized as one of four types, as follows (although the consequences of a specific 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 (for example, an application that runs as root on a Unix standard operating system), then an attacker can try to get that privilege unwanted Way to use. For example, the attacker could use this privilege to gain access to protected operating resources or to interfere with other applications that operate on the same machine.
• 2. Underride application-enforced access controls. This type of attack will gain access to legitimate resources (ie resources that are to be exposed by the application), but in an unauthorized manner. For example, a web server that forces access control to its content before offering it is an application that is vulnerable to this type of attack. Since the web server has uncontrolled direct access to the content, so does the attacker who has gained control of the web server in the same way.
• 3. Providing Wrong Decision-Making Security Information: This type of attack is usually an indirect attack in which the vulnerable application, unlike the main service, is typically a support service (such as an authorization service). The compromised security service can then be used to provide false or forged information, allowing an attacker to gain access to the main service. Therefore, this is another way 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 local resources of the machine that are not protected but would normally be exposed by the application nonetheless. 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 then staged attacks on other applications in the machine or on the network could then be initiated.

at a containment has the abuse a privilege to gain direct access to protected system resources much less serious consequences than without containment because, even if one Attacker exploits an application privilege, the resources, on which can be accessed, are bound by what is in the containment area the application available has been made. Similarly, in the case of unprotected equipment, the one containment use access to the network from an application be blocked or at least very strictly controlled. With regard to the provision of wrong decision makers Safety information mitigates the potential damage, what is done by ensuring that will that the only access to the support services from the legitimate clients, d. H. the application services, which limits the exposure of applications to the attack.

A Reduction or prevention an attack of the second type, d. H. an undercutting of application-enforced Access controls usually become on application concept or reached at least at configuration level. When using a containment can However, precautions must be taken to ensure that access to protected resources from a big, untrusted Application (for example, a web server) out by a smaller, more trustworthy one Application must go.

Therefore, the use of containment in an operating system effectively increases the security of the applications and limits potential harm that can be caused by an attacker in the event that an application is compromised. With reference to 2 is an exemplary architecture 200 to the multi-service host on an operating system with the mitigation functionality shown. 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 can not interfere with the processing of another application or gain access to its (possibly sensitive) data. The containment is used to ensure that only the interfaces (input and output) that require a particular application to function are uncovered by the operating system, reducing the amount of attack on a particular application and also the extent of damage that can be done if the application would be compromised. Therefore, the containment helps to preserve the overall integrity of the host platform.

OS kernel-enforced mitigation mechanisms in OSs have been available for several years, typically in OSs designed to handle and process classified (military) information. Such OSs are often referred to as "trusted operating systems." The mitigation functionality is usually achieved through a combination of Mandatory Access Controls (MAC) and privileges, and the MAC protection schemes enforce a special policy System resource access control, such as files, processes, and network connections, is enforced by the kernel of the operating system can not be turned off by a user or a vulnerable application.

The Complexity / difficulty with which a system administrator can manage a system including the Management of security mechanisms, such as As a containment, faced In general, it is through the tools / techniques that one gets System administrator to manage security mechanisms (e.g. For manipulating security mechanism configurations) disposal stand, increased. This means, the existence System administrator frequently with relatively complex and / or user-unfriendly interfaces for configuring system resources and security mechanisms an OS must interact. There are also techniques for configuring security mechanisms generally inefficient, are for a system administrator in unwanted Time consuming and labor intensive in performing the tasks that for configuring (eg manipulating) security mechanisms necessary, such. For example, those for implementing containment in a system.

One trustworthy Operating system called KeyKOS or KeySAFE and The departments used is at "The KeyKOS / KeySAFE System Design; SED009-01; Agorics, Inc., CA, March 1989, pages 1 to 21 described.

Out The UNIX operating system is also aware of a "chmod" command through which an access mode a file or directory can be changed.

It is an object of the present invention, a method and a To create a system that allows easy and trouble-free management enable departments in a trusted operating system.

These The object is achieved by a method according to claim 1 and a system according to claim 7 solved.

According to one embodiment becomes a method for managing a processor-based system discloses implementing at least one department for storing at least one process and providing has at least one operating system command line utility, which is executable for manipulating the departments. According to one another embodiment discloses a system having at least one processor, and an operating system that implements at least one department, the at least one process running on the system can be assigned. The system also has at least a configuration file that defines the departments, and a Device to run the administration of the departments on without requiring a user the configuration files in which such compartments are defined are edited. Another embodiment provides a computer-readable medium containing instructions through running a processor can be included, wherein such a computer-readable medium is a library of software functions for managing at least one department by an operating system is implemented. Such a library of Software features includes at least one command-line utility that can be manipulated of the departments can be.

preferred embodiments The present invention will be described below with reference to FIG the enclosed drawings closer explained. Show it:

1 an exemplary prior art computer system that includes an operating system;

2 a schematic representation of an exemplary multi-service hosting architecture on an operating system implementing containment functionality;

3 an exemplary schematic representation of an OS implementation of departments;

4 a schematic representation of an exemplary architecture of a trusted Linux host operating system that can implement departments, wherein various embodiments of the present invention can be implemented in such an exemplary architecture;

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

6 schematically the effect of the following rule in an exemplary OS implementation: HOST * → COMPARTMENT × METHOD TCP PRT 80;

7 in schematic outline an exemplary configuration of Apache and two Tomcat Java Vms;

8th schematically an exemplary trusted gateway system;

9 an exemplary departmental management flow of a typical prior art method for managing departments by editing a configuration file and booting the system;

10 an exemplary departmental management flow according to at least one embodiment of the present invention;

11 an exemplary operational flow for creating a department and then renaming it according to an embodiment of the present invention;

12 an exemplary operation flow for switching from one department to another according to an embodiment of the present invention; and

13 an exemplary operational flow that uses a departmental management utility to switch to another department and execute a command in the same according to an embodiment of the present invention.

As As described above, containment is an effective safety mechanism to implement in a system. As more fully explained below can be a containment functionality in one System implemented by the departments used in the system become. In general, the departments refer to groups of processes or threads that rely on accessing to specific subsets are limited by system resources of a computer system. Therefore, the departments are semi-isolated sections of a system. An operating system to support a For example, a plurality of processes (eg, applications) may be implemented be implemented in a system, wherein at least a part of the processes is provided with a label or a label, each one Labeling or each label a logically protected computing environment or "department." Each process with the same label or same label may be same Department belong. In certain implementations, the mitigation functionality may be through a mandatory protection of processes, files and network resources be provided, with the basic concept on the department based. Services and processes (such as applications) on the system can be found in separate departments. The processes in each department can only a direct access to the resources in that department to have. Access to other resources, whether local or TV, can only over well-controlled communication interfaces are allowed. exemplary Implementations of departments in a system are described below in more detail described.

According to different embodiments The present invention will be an efficient and user-friendly possibility for managing (eg manipulating) departments in an OS disclosed. More specifically, utilities such. For example, command-line utilities, provided that allow that commands executed by the user room of an OS to manage the departments. According to at least one embodiment command-line utilities are provided that allow that commands are executed to the departments and / or rules that contain such departments define, dynamically manipulate.

For a better understanding of the present invention, it is appropriate for the reader to understand the use of departments in an OS. Accordingly, an exemplary OS implementing departments therein as well as exemplary departmental arrangements are described below 3 - 8th described. Although a specific OS architecture and methods for implementing divisions within such an OS are described below, it is to be understood that the described OS and departmental implementations are intended to be exemplary only to the reader to help understand certain aspects of the present invention, and for that reason, the present invention should not be limited to the specific OS and / or departmental implementations described below. Rather, any OS and method for implementing departments that is 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 implementing departments, techniques for managing (eg, manipulating) such departments are described. A prior art method for managing departments by editing a configuration data and booting the system is described in connection with 9 described. Exemplary methods for managing (e.g., manipulating) departments using utilities in accordance with certain embodiments of the present invention will be described below 10 - 13 described.

I. Exemplary OS architecture and department implementation

According to an exemplary OS in which various embodiments of the present invention may be implemented, containment functionality is achieved by means of a prescribed protection of kernel-level processes, files, and network resources. Different types of prescribed controls can be used, such as: For example, those of traditional trusted OSs. The key concept of a trusted OS is often the "department," and various services and processes (eg, applications) on a system can be executed in separate departments 3 Figure 2 shows an exemplary schematic representation of an OS implementation of departments that provides a very simplified example of the concept of the departments. As shown, the system can 300 have an OS running on it and implementing two compartments shown as Department A and Division B. In the example of 3 the processes X and Y are contained in the department A, and the process Z is contained in the department B, respectively, contained. The system 300 can have various resources, which can be used as equipment A, equipment B and equipment C in 3 and the departments may be implemented to designate the resources that the processes contained therein are allowed to access. Such resources A, B and C may include network interfaces, processes, files and / or other types of system resources. According to particular implementations, any number of system resources may be organized in accordance with a department access control. For example, system resources associated with TCP / IP networking, routing tables, route caches, shared memory, message queues, semaphores, process / subprocess handling, and user ID (UID) handling may be provided by the Use of departments be limited.

At the in 3 In the example shown, the processes X and Y contained in the section A have access to the resource A and the resource B, but not to the resource C. Further, the process Z included in the department B has a Access to resource B and resource C, but not resource A. Thus, the bins can be used as a security mechanism that protects the applications from attack and limits the amount of damage that can result to a system at risk during a compromised process an endangered process in a department limits its access to those resources that the department is allowed to access.

According to one Exemplary OS implementation can be relatively simple prescribed Access controls and a process label are used to create the concept of a department. In the following An example implementation of a trusted OS will be described in each process System assigned a label, and the processes with the same Include caption to the same department. There are mandatory tests on Kernel level enforced to ensure that the processes from one department not with processes from another department can interfere. The prescribed access controls are relative in the sense simply designed that Labels either match or not do. Further, in this example, there is no hierarchical arrangement of labels in the system, as in some known trusted Operating systems is the case. Unlike traditional ones trusted OSs do not use the labels in this example, to directly control access to the main file system. Instead of its a file system protection is achieved by another section of the main file system is assigned to each department. Everyone 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 to the Section of the file system associated with this department.

The term "chroot" as used herein refers to a command to change the active root zelverzeichnisses. That is, the "chroot" is a command that is executed to modify a user's active root directory, for example, in a typical Unix system, the root directory is displayed as "/". Thus, the command "cd /" is normally executed to go to the root directory of the file system The chroot command can be executed to change a user's active root directory For example, the command "chroot / home" changes an active root directory Then, executing the cd / command causes the "/ home" directory to be modified rather than "/" because "/ home" is now the user's active root directory In another example, the chroot instruction can be used to specify a particular section as the active root directory For example, the command "chroot / compt / FOO" changes the active root directory to the section FOO. Thus, while the "cd /" is being executed to switch to the active root directory (which is changed by the chroot command), the chroot command may be used as another security mechanism, for example, the chroot command may be used. to effectively prevent a user (or process) from escaping from the active root directory specified by the chroot command, that is, for example, that a user (or process) is not from the active root directory specified by the chroot command (eg, section FOO) can escape to the actual root directory ("/") of the system. Once the active directory of a user (or process) has been changed via the chroot command, this is considered to be chrooted. Accordingly, the ability of a process to transition from root to root via the kernel controls in this exemplary implementation is removed so that the chroot can not escape. This exemplary implementation provides the ability to make at least selected files in the chroot immutable.

at These exemplary OS architectures are flexible ways of communication between the departments and the network resources over close, kernel-level interfaces with TCP / UDP as well as most IPC mechanisms intended. Access to these communication interfaces will be determined by rules established by the security administrator a "per department" basis may be specified it is, in contrast to conventional ones trusted Operating systems, not in this exemplary implementation necessary, the mandatory access controls with a privilege or department regarding the use of trusted Turn off proxies at the user level to prevent communication between the departments and network resources.

The exemplary implementation sees a trusted OS before that, a containment offers, but also has sufficient flexibility, to make application integration relatively straightforward, thereby reducing the overall administrative costs and the expense of using and running a trusted one Operating system, often usual trusted OSs is reduced. Although again a specific Example of the architecture and implementation that the departments use, described herein, and the one preferred architecture and implementation, in the embodiments of the present invention Invention can be implemented It is noted that each OS architecture and Any method for implementing departments, now known are discovered (for example, traditional trusted OSs) or later are within the scope of the present invention to move, and that certain embodiments of the present invention implemented in any such OS architecture could be.

The OS architecture and implementation of a specific example to implement departments will now be described in more detail. In the The following description describes in detail a trusted Linux OS. its system by modification to the Linux-based kernel for Support the containment of user-level services, such as As HTTP servers realized is. One skilled in the art will understand, however, that in connection with a such trustworthy Linux OS described principles to other types of OS can be applied to the same or similar effects to achieve.

With reference to 4 Figure 2 illustrates an exemplary architecture of a trusted Linux host OS that implements departments to mitigate. The system 400 includes a plurality of compartments. In this example are a WEB department 401 , an FTP department 402 and a SYSTEM department 403 shown. Each department can be assigned to different executing processes or sub-processes. Consequently, with reference to 4 , indicates a Linux base operating system kernel 400 generally a TCP / IP network device 406 , UNIX domain socket 408 , an intermediate process communication device 410 (eg a Sys V IPC device), a file access module 412 and other subsystem 408 on. The trusted Linux OS also has operating system core extensions 415 in the form of a security module 421 , a device configuration module 418 , a rules database 416 and kernel modules 422 on. As shown, at least some of the Linux kernel subsystems are 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, the security module takes 421 Authorize access control decisions and is responsible for promoting the concept of a department, thereby providing containment.

The security module 421 additionally consult the rule database 416 when a decision is made. The rule database 416 Contains information about permissible communication paths between departments, providing narrow, well-controlled interfaces to and from a department. Consequently, the processes of the departments are to access system resources according to the rules set out in the rules database 416 are stored, limited. The rule database 416 may have separate tables for TCP / IP network resource rules and for file system resource rules. The various 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 policies may be stored on the file system. 4 also illustrates how the kernel extensions 415 from the user room 420 be managed through a series of customized system calls. As described in more detail below, such customized system calls may include some to the rule table 416 to manipulate, and others to operate the processes in special departments and to configure network interfaces.

As described in more detail below, the system department 403 Processes include the command-line utilities 404 to modify the departments or rules assigned to such departments. According to various embodiments of the present invention, the command line utilities 404 Commands for managing departments (e.g., manipulating departments and / or departmental rules) include. As in the exemplary system of 4 shown is the stable storage database 405 can be implemented in the user space and includes information identifying department names and a corresponding number map for each department (e.g., in the file "cmap.txt"). Thus, each department can be assigned user friendly names, and also on each department a respective number may be mapped for internal processing by the system 400 is used. Furthermore, the security module includes 421 preferably a memory 421A that has the department name and the number mapping that is the security module 421 enable the appropriate rules in the rulebase 416 identify that apply to a specific department requesting access to the system resources.

During operation, each of the operating system kernel modules of the system interacts 400 advantageously with the security module 421 , The security module 421 drives the departmental scheme to prevent unauthorized access to the system resources. Specially uses the security module 421 the device configuration module 418 and the rules database 416 to facilitate departmental restrictions. The security module 421 can determine what resources the system 400 via the device configuration module 418 be available. The security module 421 also receives the identification of a department and the identification of a system resource to be accessed by a routine of an operating system kernel module. The security module 421 searches the rulebase 416 to locate an applicable rule. The security module 421 Enables or disables access based on an applicable rule or on a default rule if no applicable rule has been located.

With brief reference to 5 For example, an example of the use of departments in an operating system according to an example implementation is shown. As shown, the system call commands (syscall commands) 509 be used to allow a user the rules in a rule machine 506 (in the kernel 501 is executed) from the user room 502 from manipulating. A program 507 or a file 508 can z. For example, such syscall commands 509 Run to the desired rules in the rule machine 506 to implement, to define the containment of the departments. The example of 5 also includes a process 503 which is assigned to a special department. The process 503 carries a code in the user space 502 which is a hardware-enforced mode of operation that controls the operations of the process 503 limits. The process 503 may include code operable to attempt access to a protected resource (eg, opening a particular file) in accordance with a departmental scheme and request access to a particular resource. That means the process 503 requests (eg via a customized syscall), a communication access 505 to obtain a desired resource. The access control logic 504 is in the kernel 501 running to the rule machine 506 access to determine whether the process 503 the requested access should be granted. More specifically, the access control logic receives 504 a department identifier or a label of the process 503 and uses such a department identifier to the rulebase 506 to search to determine if the department, the process 503 is assigned, the access to the special equipment is allowed. In accordance with at least one implementation, a hash table may be used to perform the lookup of a rule. Depending on the purpose of the system, such internal hash tables may be configured such that the introduced rules are on average one level deep in each hash log area, causing the rule lookup routines to behave in the order of O (1). Accordingly, rule lookup can be performed relatively quickly and efficiently. Depending on the rules that apply to the department in which the process 503 is defined, the access control logic can 504 a communication access 505 grant or such communication access to the process 503 deny. If access is denied, the access control logic transfers 504 the processing control to the exception handling module 510 That's an exception (for example, an error message) to the process 503 returns and / or the operation of the process 503 established.

With reference to 4 For example, various user room services may be implemented in the exemplary architecture shown, for which the departments may be used. The user room services, such as For example, the web servers running in 4 are operated unmodified on the platform, but have a departmental label associated with them via the command line interface with the security extensions. The security module 421 is then responsible for creating the mandatory access controls to the user room services based on their created departmental label. It is therefore understood that the user space services may 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 4 uses an operating system kernel module (eg security module 421 ), which may be referred to as "ins", to implement customized system calls that allow for the insertion / deletion of rules or other functions, such as labeling of network interfaces Such ins module implements various interfaces via customized system calls to enable:

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

According to certain embodiments of the present invention described in this exemplary architecture are implemented, the main client of the ins module is the tlutils collection command-line utilities, which are discussed in more detail below are described.

The Ins module implements an interface to add / delete Rules in the kernel about customized System calls. It leads the translation between simplified rules of a higher level in primitive forms which are better understood by the kernel lookup routines. (This module is provided by the utilities at tlutils user level called to manipulate rules in the kernel.)

at These exemplary implementation are modifications to the Linux standard kernel sources have been made to a label on different data types. as well as to add access control checks that near such tagged data types were made. Each tagged Contains data type an additional struct-csecinfo data member used to hold a department number to keep. There is a chance that the tagged data types could be extended to keep other security attributes. In general, that will Add this data member usually at the extreme Executed at the end of a data structure, To avoid problems that are based on the usual procedure refer to the pointer between two or more differently named Structures that begin with common entries.

The mere effect of labeling individual kernel resources involves a very simple implementation of a partitioned system in which processes and the data they generate / consume are isolated from each other. In this exemplary implementation, such isolation should not be strictly designed in the sense that many hidden channels exist. The isolation in this exemplary implementation is simply to serve as an obvious form of conflict and / or conflict to protect an interaction between logically distinct groups of processes.

at At least one implementation can be done before a department assumed root identity be sealed. This means, that individual Departments may optionally be registered as "sealed" can, to process in this department before a successful call from setuid (0) and related system calls, such as: Setuid (0), and also before a run of SUID root binary numbers to protect. This can be for services, which can be accessed externally, and generally for buffer overflow attacks, for example, to execute a malicious one Codes lead can, susceptible are to be used. If such services are limited to initially to be operated as a pseudo-user (non-root user), and if the department in which it is carried out is sealed, then Any attempt will be to root identity through either buffer overflow attacks and / or execution to accept stranger instructions fail. Note that everyone existing process, which is operated as a root will continue to do so.

It can implemented different types of services in the departments be. The kernel modifications, which are described above, serve to support the Hosting individual services at the user level in a secure department. Next to it are layout, position and conventions, which when adding or Remove services in this exemplary embodiment of the invention are 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 each be assigned to a department. However, what an end user considers to be a service can actually end up using multiple departments. An example would be the use of a department to host an externally accessible web server with a narrow interface to another department hosting 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 executing the CGI binary numbers; and
• - As many departments as necessary to properly categorize each CGI binary, while the trusted gateway attacks / executes the CGI binary numbers in its configured departments.

In this exemplary implementation, each department has a name and is classified as a chroot-enabled environment. 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, there are also the following subdirectories:

• 1. / bin - various scripts and command line utilities for managing departments may be installed in / bin in accordance with particular implementations of the present invention; and
• 2. / etc / tlinux / rules - Files containing rules for each registered department on the system may be located in / etc / tlinux / rules according to 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 generally start / stop a department in this exemplary implementation Each department prefers to agree with some basic characteristics:

• 1. Being chroot-capable according to your department position / compt / <name>. However, it is not mandatory for a department to have a "chroot" to start, rather it provides an additional security feature that is not required in all implementations of the present invention.
• 2. Supply / etc / tlinux / init / <name> / startup and / etc / tlinux / init / <name> / shutdown to start / stop the department identified by <name>.
• 3. Startup (or startup) and shutdown (or closing) scripts are responsible for introducing rules, creating routing tables, attaching file systems (eg, / proc), and other pro-service initialization steps.

in the general, if the department should be externally visible, should the processes in this department are not operated by default as root, and the department should be "sealed" after initialization, sometimes This is because of the way the precursor application is integrated In this case, it is not possible to / will be provided with ports desirable is, if possible many skills in order to prevent the processes from the "chroot prison", for example, cap mknod, escape.

Because the departments may exist as chrooted environments according to the / compt directory, application integration may require the usual methods used to ensure that they operate in a chrooted environment. One common method involves preparing a cpio archive of a minimally-operating department that contains a minimal RPM database of installed software. It is common practice 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 needed, eg. Httpd.conf] root @ tlinux # [Generate startup / shutdown scripts in / compt / app1]

The last two steps can into the RPM installation phase to get integrated. Reductions in platinum space can be caused by an investigation can be achieved, namely by selective uninstalling from unused packages over the rpm command. additional Posts in the / dev directory of the department can be created as needed, however, in most cases, / dev is essentially left alone. Further automation can be achieved by using a web-based Interface with the process described above is provided to all necessary parameters for to provide any type of application to be installed. At the compiled binary numbers are generally no changes necessary, unless it is necessary, department-conscious variants to install such applications.

Once the rules are in place (for example, in the rulebase 416 from 4 ), to define the containment of departments, such departments can be used by the OS to perform security checks. In this exemplary implementation, there exists a function "cnet_chk_attr ()" that implements a yes / no security check for the subsystems that are protected in the operating system kernel .. Calls to this function are made by the appropriate points in the kernel sources to provide the required departmental This feature is based on the affected subsystem and can easily implement divergent constraints or rule conventions, depending on the subsystem of the operation being queried at that time, for example, most subsystems implement simple partitioning where only objects / resources However, in certain cases, the use of a non-privileged department 0 and / or a wildcard department - 1L may be used, for example, department 0 as a default "sandbox" for unclassified assimilated resources / services; a placeholder department for Beaufsichti purposes, such. B. List processes on the subsystem before shutting down.

As in the example of 5 are shown, access control checks at appropriate points in the operating system kernel (through the access control logic 504 ). More specifically, in this exemplary implementation, such access control checks will be through the use of hooks for a dynamically loadable security module 421 ( 4 ) that runs a table of rules (rulebase 416 from 4 ), which indicates which departments on the resources of another Ab allowed to share. This is done in a transparent manner for the working applications.

m:

unterstützter Betriebssystemkern-Mechanismus, z. B. tcp, udp, msg (Nachrichtenwarteschlange), shm (gemeinsamer Speicher) etc.;

attr:

Attribute, die das Verfahren m weiter qualifizieren; oder

n:

eine benannte Netzwerkschnittstelle, falls zutreffend, z. B. eth0.

Every security check can consult a table of rules. Each rule can take the following form:
Source → Determination method m [attr] [netdev n]
in which:
Source / destination can be:
COMPARTMENT (a designated department);
HOST (a fixed IPv4 address);
NETWORK (an IPv4 subnet);

m:

supported kernel mechanism, eg. 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. Eg eth0.

An example of such a rule that allows processes in the department named "WEB" to access shared memory segments, eg, using shmat / shmdt (), from the department named "CGI." allowed, would look like this:
COMPARTMENT: WEB → COMPARTMENT: CGI METHOD shm

It There are also certain implicit rules that allow some Communications take place in a department, e.g. B. could one Process allowed become the process identifiers of processes resident in the same department. this makes possible a net minimum of functionality in an otherwise unconfigured one Department. An exception is the department 0, which is relatively unprivileged is and in the more restrictions be valid. The department 0 can be used to control the sub-processes at operating system kernel level (such as the swapper or the outsourcer) to host or accommodate.

In Lack of a rule that explicitly allows a cross-departmental Access takes place, all these attempts fail. The net effect The rules involve the promotion of mandatory segmentation all departments except those who have been explicitly allowed on the resources to access another department.

The rules are inherently directive, which has the effect of being consistent with the connect / accept behavior of the TCP socket connections. A rule is used to specify allowed HTTP inbound 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 allowed, as in the example in 6 is shown is shown. The directionality of the rules allows the backflow of packets to occur to properly establish the incoming connection without allowing the outgoing connections to take place.

Of the above-described solution paragraph has a number of advantages. For example, he allows a complete control over each supported Subsystem and the ability to unsupported, z. B. hardware-driven card-to-card transfers, herauszukompilieren. Furthermore, this approach sees a relatively extensive Namespace repartition before, without the need for user space commands, such as Ps, netstat, route, ipcs etc., to change. Depending on the department, in which is currently a process located, changed the list of visible identifiers according to the specifications the rules. Examples of namespaces include a process table via / proc, SysV IPC resource identifier, Active, closed and dormant pedestals (all domains) and routing table entries.

It should be noted that the system of 4 just as an example. The present invention is not limited to any particular department or containment scheme. Specifically, the numerous approaches can be used to prevent processes associated with a department from accessing system resources. For example, access control at the user level may be implemented by several methods. A strace () mechanism can be used to track every system call of a given process. The strace () mechanism examines each system call and its arguments. The strace () mechanism returns the system call according to the rules set in a Rulebase are defined, either free or disabling the same. It is also possible to use a system call wrapping. In system call wrap, wrapper functions examine calls and arguments using a dynamically linked shared library. The wrapper functions also either enable or disable system calls according to the rules defined in a rule database. User-level authorization servers can be used to control access to system resources. The user-level authorization servers may control access to the system resources by providing a controlled data channel to the operating system kernel.

• 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 mehreihigen 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 involves providing a secure Web server platform with support for the containment of arbitrary CGI binary numbers and non-HTTP-related processing (e.g., Java servlets) are partitioned into separate compartments, each having the bare minimum of rules required for operation. 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. The containment or division into departments in such systems could be used to reduce the conflict potential between the services and to control the visibility of output-side hosts on a per-service basis.
• 2. Increased fronts (typically HTTP) over multi-tiered outbound pages including inter-application servers. The division into departments in such systems has the desired effect of factoring out as much of a code as possible, which can be directly accessed by external clients.

With reference to 4 can the system 400 z. B. have a web server platform, each web server can be arranged in its own department, such. For example, the web department 401 , The following description serves to illustrate how the exemplary implementation can be used to partition a setting into divisions comprising an outbound Apache web server configured to handle Java servlets or to operate JSP To delegate files to two separate instances Jakarta / Tomcat, each working in their own department. By default, each department uses a chrooted file system so as not to interfere with the other file systems.

7 Schematic represents the Apache processes that reside in a department (WEB). This section can be accessed externally using the following rule:
HOST * → COMPARTMENT WEB METHOD TCP PORT 80 NETDEV eth0

The presence of the NETDEV component typically 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 output-side networks through inbound network interfaces. The WEB department is allowed to communicate with two separate instances of Jakarta / Tomcat (TOMCAT1 and TOMCAT2) via two rules that have the following form:
COMPARTMENT: WEB → COMPARTMENT: TOMCAT1 METHOD TCP PORT 8007
COMPARTMENT: WEB → COMPARTMENT: TOMCAT2 METHOD TCP PORT 8008

The servlets in TOMCAT1 may access an output host named Server1 using the following rule:
COMPARTMENT: TOMCAT1 → HOST: SERVER1 METHOD TCP .....

TOMCAT2 however, may not access any output host, which through the absence of additional Rules are reflected. The kernel will be any Try to deny this type of TOMCAT2. This allows the selective change the view of an output-side network depending on which services be hosted, and the restriction the visibility of outbound hosts on a per-department basis.

It would also be valuable to note that the above four rules are all that is necessary for this exemplary configuration. In the absence of other rules, the servlets running in Java VM can not initiate outbound connections; in particular, it can not be used to initiate attacks on the internal output network on the eth1 interface. In addition, it can not access resources from other departments (for example, shared memory segments, UNIX domains socket etc.) can still be accessed directly by remote hosts. In this case, mandatory restrictions on the behavior of Apache and Jakarta / Tomcat have been imposed without recompiling or modifying their sources.

It should be noted that the departments can be used in a gateway-type system (dual-interface host connected to both internal and external networks). With reference to 8th is a gateway system 800 (which is connected to both an internal and external network).

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

As in 8th 2, service0 and service1 are only allowed to access the network subnet1 through the network interface eth0. Therefore, attempts to access Host0 / Host1 succeed because they are Subnet1, but then attempts to access Subnet2 via eth1 fail. Further, the service N is only allowed to access eth1 on HostX. Therefore, any attempt to access HostN through ServiceN will fail even if HostN is on the same subnet as HostX, and any attempt by Service N to access any host on Subnet1 will fail. The constraints can be specified (by rules or routing tables) by the subnet or by the specific host, which in turn can be qualified by a specific subnet.

Thus, in the exemplary implementation described above, access control checks may be made in the operating system kernel / operating system of a gateway system so that they can not be bypassed by the user space processes. As further described above, the operating system kernel (the gateway system) may be provided with means for affixing a label or label to each working process / thread, the tags / tags fictively indicating to which bin a process belongs. In certain implementations, such labels may be inherited from a parent process that branches a child. Therefore, a service that has a group of diverted children working together to share the workload, such A group of slave web server processes that have the same labels and are positioned in the same department. The system administrator can, for. 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 named Z. Such rules may be stored in a secure configuration file on the gateway system and loaded into the kernel / operating system setting so that the services that are then started can work. When the services are started, their hiring sequence would specify in which department they would initially be positioned. In this embodiment, the rules are consulted each time a packet is dispatched from or delivered to the department X where additional security checks are imposed, preferably in the protocol stack of the operating system kernel.

at Certain implementations is a separate routing table per department intended. As in the implementation described above every process can Label or a caption (which he inherited from his parents can have). Start processes with specific names with a designated label by a system administrator has been configured. Instead of specifying rules, as in the above implementation, a set of Configuration files may be provided (one for each department) that the respective guidance table for Configure the department by entering the desired routing table entries. Because the gateway system contains an unnamed number of departments could, the guide table of each department is by default preferably empty (ie no entries).

The Use of routing tables instead of explicit rules be achieved because of the lack of a consistent route so is interpreted that the Remote host trying to reach, supposedly out of reach is. The routes that actually match stand for the acceptance of the attempt to access those remote hosts. As in the rules in the first exemplary implementation, the above is described the route entries on a per-host basis (IP address basis) or per subnet basis be specified. All this is required to make such routing entries on one Pro departmental base to specify the same functionality as at to achieve the first exemplary implementation.

II. Departmental Administration according to different embodiments the invention

in the The above has been a review of a Exemplary OS architecture for implementing departments intended. It should be noted that certain execution examples of the present invention in any OS and departmental architecture can be implemented and therefore not the exemplary implementation described above limited are.

in view of the fact that the Departments are an important security mechanism in trusted OSs create, it is desirable an efficient and user-friendly mechanism for managing to own such departments. For example, it could be for one now and then Users, such as As a system administrator, be desirable departments to manipulate, for. For example, to add a new department, one Removing department, renaming a department etc. Additionally it for a user desirable be to manipulate rules that define the containment of departments. Such manipulation of departments and the manipulation of Rules that containment of such departments are intended to be used as used herein Term "departmental administration" includes.

There are several problems with traditional methods of managing departments. One prior art method for managing departments is in 9 shown. Traditionally, the departments are 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 in 9 requires management of departments in prior art systems, e.g. For example, manipulating a department that a user (eg, system administrator) the configuration file in which the departments are defined (step 901 ) edited. Likewise, manipulating rules that define containment of a department requires that a user edit the configuration file in which such rules are provided. That is, at step 902 a user may use a text editor to view and edit a configuration file to manipulate the departments and / or the rules.

Of course, even to edit the configuration file, the correct configuration file must first be determined, located in the system files, and opened for editing. Once the configuration file is open for editing, the user may edit the file (eg, 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 the name of a department. As another example of adding a department, the user would have to edit the configuration file by inserting a corresponding text therein for defining a new department to be created. Once the user edits the configuration file, the edits made to the configuration file must be made in step 902 get saved. In order for the changes made to the configuration file to be applied within the system, it is typically necessary to boot the system (step 903 ). More specifically, the systems typically access the configuration file after booting, and the changes made to the configuration file during the system runtime are not applied to the system until it has been booted.

The method described above for managing departments is problematic for several reasons. In the first place, such a prior art departmental management method requires a user to edit a configuration file. Given the size and amount of information that may be included in such a configuration file, the proper editing of the configuration file to achieve a desired result involves considerable complexity / difficulty. In addition, editing a configuration file is an inefficient method of manipulating departments, since a user must determine the appropriate configuration file to be edited, open the file, and properly edit the file (which contains a large amount of information N, which the user must parse to ensure that it has been properly edited to achieve the desired result). Further, such a prior art technique typically requires that the system be booted in order for the changes made to the configuration file to be applied to the operation of the system. In addition to the inefficiency and unwanted interruption due to such system booting, errors that result from editing the configuration file will not be discovered until such booting has been performed. Further, if an error encountered in the configuration file is fatal in that the system can not be booted, then eventually a rescue of the system must be performed by recharging the entire OS.

Embodiments of the present invention facilitate the requirement of editing 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 departmental administration. 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 containment of departments may be manipulated via command line utilities. Additionally, in accordance with certain embodiments of the present invention, the executed utilities allow departments and rules to be dynamically manipulated. That is, no system boot is required to apply the actions requested by using the utilities during system operation. 10 FIG. 12 shows an exemplary departmental management flow according to at least one embodiment of the present invention. As shown, to manipulate a department and / or rule, a user must have a command-line utility in step 1001 and the actions generated by such a utility will be in step during operation of the system 1002 dynamically applied.

According to one embodiment The present invention is departmental management utilities provided that include a number of command line tools, to create, manage and remove departments. A exemplary list of utilities used in at least one embodiment The present invention is available, as well as an overview of the functionality which is executed by each utility will be explained below provided. It should be noted that the names of the utilities in the various embodiments can change without their functionality to change. Therefore, the present invention is not limited to specific ones, below described but rather serve such exemplary utilities as examples illustrating the revelation rendering many other types of departmental administration utilities allows where it is desirable is, that you be implemented within a given system.

As in more detail below is described according to the various Embodiments of present invention a sequence of departmental administration utilities intended. According to certain embodiments Such departmental administration utilities have command-line utilities referred to herein as "tl" utilities can be designated (eg, "tlrules" and "tlcomp" utilities, which are described below). Various examples of such Utilities for manipulating departmental rules and manipulating of departments according to the embodiments of the present invention are described below. It should However, it should be noted that such utilities, though specific utilities and their functionality are to serve as examples that reflect the revelation many other departmental administration utilities are enabled in similar Way can be implemented.

exemplary Utilities for manipulating departmental rules

In accordance with at least one embodiment of the present invention, "tlrules" utilities are provided for manipulating departmental rules Such "tlrules" utilities may include command-line utilities for adding, deleting, and listing rules. In the exemplary implementation described in above 4 such "tlrules" can be used as command line utilities 440 be implemented, which can be executed to departmental rules (for example, in the rulebase 416 ) via a / proc / tlx interface provided by a kernel 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 may 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: Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and ALL.

A departmental management utility that can be used to manipulate departments is a command-line utility that can be executed to provide rules for controlling the communication (or access) of a department with a resource (e.g., 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 take the form of, for example, "rules, rule description". The rules are z. For example, according to one embodiment, set to control the communication of departments with each other and with the network interfaces. The tlrules utility can be run to perform such tasks as listing all the rules currently being configured on the system, loading rules from a file, loading rules from the command line, and deleting rules contained in a file For example, on the command line are specified to execute. In the exemplary implementation that is in 4 By default, the tlrules and associated command-line utilities compute 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 in the command line). For example, to add multiple rules contained in a file, the "tlrules - a rulefile.txt" command can be executed, adding rules contained in the "rulefile.txt" file. On the other hand, to add a rule that allows the department "dev" to query the DNS server on the host 192.168.10.3, the following command can be executed:
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 found by listing the Rule is issued using the tlrules-1 command, which returns rules in a standard format with the rule reference issued as a comment at the end of each rule). As another example, the rule that allows the dev department to To query the DNS server on the 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"

When another example to delete all rules in the file "rulefile.txt" can the command "tlrules - d rulefile.txt" is executed.

In at least one embodiment cause syntax errors or semantic errors caused by tlrules detected have 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, it will the number of lines of the faulty line found in the error message.

• 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 The present invention is known as "tlutils", which interfaces with the Ins operating system kernel module (the above 4 is described). Its most important function is the provision of various administrative scripts with the ability to span processes in a given department and to set the departmental 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

At least an embodiment In the present invention, the "tlcomp" utilities are for manipulating a Department provided. Such "tlcomp" utilities can be command-line utilities z. For adding, Clear and rename departments. Various specific Examples of such tlcomp utilities are described below.

A first departmental management utility that can be used to manipulate departments is a command-line utility for adding / creating a new department in a system. According to one embodiment, such a command-line utility may be called "tlcompadd", and the use of such a utility may take the form of, for example, "tlcompadd [compartment name]" or "tlcompadd [option flags] [compartment]." In this example, tlcompadd adds a specified department names as argument add a new department with such a specified name to the system, more specifically the department with the specified name of stable storage database (stable storage 405 from 4 ) on the system and provides a reference in memory at the kernel level (memory 421A from 4 ). In at least one embodiment, once the department has been generated via the tlcompadd command, it is immediately available to the system for use. As a result, the divisions can be dynamically generated by the user space of the OS without requiring booting of the system to make the generated divisions available for use.

According to at least one embodiment, the department name may include a hyphen (-) and an underscore (_) in all alphanumeric characters (A - Z and 0 - 9). The department name specified by the user provides a user-friendly presentation of the department. However, as in the exemplary implementation of 4 In at least one embodiment, an internal database is stored both in memory (eg memory 421A in 4 ) and stable storage that maps the user-friendly name to a number that identifies the department (eg, a text file "cmap.txt"). 405 in 4 ).

at implementation in an OS architecture, such as the one above described, it may be beneficial to certain departments in a chroot file system. Consequently, at least an embodiment, besides creating a department with a specific department name, an argument (or option flag) that is a chroot file system and initialization scripts for the departments created. The purpose of this is that it is to that effect an additional Security layer provides that Process (e.g. B. an application), which runs in a department, in a chroot area of the File system can run, making everything outside the chroot area of the file system for the Processes in the department is not available. init enable Starting processes in the department (for a more detailed explanation, see tlcompstart below).

Another departmental management utility that can be used to manipulate departments is a command-line utility for renaming an existing existing department. According to one embodiment, such a command line utility may be called "tlcompren", and the use of such a utility may take the form of, for example, "tlcompren [current name] [new name]". In this example, tlcompren, which has a specified current department name and a new department name as arguments, renames the department that has a "current name" argument to a "new name" argument. More specifically, in accordance with at least one embodiment, the internal number representing the department remains the same, while changing the user-friendly name of the department. If the department being renamed has a chroot file system and initialization files, these are also renamed to a "new name" if necessary In at least one embodiment, renaming a section is a dynamic process so that after execution of the telcompren command, direct references to the "new name" can be made.

One another departmental administration utility for manipulating can be used by departments is a command-line utility to remove an existing department from the system. According to one embodiment Such a command-line utility can be called "tlcomprm" and its use such a utility can, for. B. the form of "tlcomprm [option flags] [compartment name] "in this example tlcomprm, which has a specified department name, the specified department from the system. According to at least one embodiment An optional flag may be included to specify that all chroot files and initialization files for one such department also be removed. Preferably removed this command both memory at kernel level as also the stable storage references to a department. Additionally is at at least one embodiment the removal of a compartment is a dynamic process, so that after the To run the tlcomprm command uses the remote department name again can be (eg when adding a new department with such a name), if desired.

One another departmental administration utility for manipulating of Departments is a command-line utility for switching from a current department to a destination department. Consequently, if a user (for example, system administrator) is currently in a special department, the user can do such Use the command-line utility to switch to another "destination" policy. According to one embodiment Such a command-line utility can be called "tlsetcomp" and its use such a utility can, for. For example, the form of "tlsetcomp [destination compartment] [option flags] [command to execute] " For example, tlsetcomp switches a destination department name comprising the login process of the user from a current department to a destination department. By default, switches the log-in shell of the user when running in the "determination department" and without options Just move to the new department. Optionally, an argument such as z. For example, -p may be included to drop some capabilities for, for example, the "determination department" or add. For example, the command "tlsetcomp [destination compartment] -p - chown "to be used to the login process of a User from a current department to a destination department However, the determination department can not execute the "chown" command to switch the ownership to change files. At least an embodiment include the options available for dropping abilities those who are usually in the Linux / Unix "capabilities.h." file.

Further The tlsetcomp command can be used to both departments to switch as well as to execute a command in the destination department. To the For example, the command "tlsetcomp [destination compartment] -c / bin / ps-ef "can be used to go to the destination department to switch and execute the ps command to list all the processes in the "determination section".

One another departmental administration utility for manipulating can be used by departments is a command-line utility, that's done can be to the current department, in the user's login process is included. According to one embodiment such a command-line utility can be called "tlsetcomp", which is the current department, where the login log of the user is located. Consequently, a user z. For example, to run the tlgetcomp command to display the department, where the user's login shell is currently located. Of the User can then use the tlsetcomp command to move to another To switch to the new department when the tlgetcomp command is subsequently executed indicates that 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 departmental management utility that can be used to manipulate departments is a command-line utility for executing a startup script of a department. Such a departmental startup script can initiate at least some of the following tasks:

• 1. Start a department-specific process, such. A web server;
• 2. Loading the communication rules that are specific to the department;
• 3. Configure file system protection rules that are 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 location of the startup script for a department is / etc / tlinux / init / <compartment name> / startup. According to one embodiment, such a command line utility may be used to initiate a startup script of a partition "tlcomp For example, the use of such a utility may take the form of "tlcompstart [compartment name]". For example, the command "tlcompstart web" executes the start script for the "web" department, which can switch to the chroot area of the file system for the department "web" and then start the processes that provide web pages.

• 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 departmental management utility that can be used to manipulate departments is a command-line utility that executes a shutdown script to shut down a department. According to one embodiment, such a command-line utility may be called "tlcompstop" and the use of such a utility may take the form "tlcompstop [compartment name]", for example. The utility tlcompstop typically reverses the tlcompstart command described above. For example, tlcompstop can initiate one or more of the following tasks:

• 1. unsealing the department;
• 2. unload the file system rules;
• 3. removing the communication rules; and
• 4. Stop the application-specific process, such as a web server.

As described above is according to at least one embodiment such a shutdown script location for a department: / etc / tlinux / init / <compartment name> / shutdown. The above Startup and shutdown scripts described above can be text and specific Commands that include commands that are part of the departmental utilities are, such. B. tlrules have.

One another departmental administration utility for manipulating can be used by departments is a command-line utility, that's done can be to all departments currently included in a system are to list. According to one embodiment Such a command-line utility can be called "tlcompseat." Likewise, a departmental management utility may be provided which accomplished can be used to all processes that work on the system (or accomplished ), and to list the name of the department in which each department is performed. According to one embodiment such a command-line utility can be called "tlprocstat."

One another departmental administration utility for manipulating can be used by departments is a command-line utility, the executable is to seal a department. According to one embodiment such a command-line utility can be called "tlcompseal" and the use of such a utility may be, for example the form "tlcompseal [compartment name] "accept. This utility provides an additional security feature. By sealing a department, the ability for processes in the department, to go to a root (eg "su-root") or suid programs or scripts perform, blocked. The command "tlcompseal web "sealed z. B. the web department, so that no Process, which is executed in the same becomes, can go to a root.

on the other hand a utility may be provided to unseal a department. According to one embodiment such a command-line utility can be called "tlcompunseal", and the use of such a utility may, for example the form "tlcompunseal [compartment name] "accept. This utility is run to a sealed department to unseal the transition to a root (eg "su root ") and the execution of to allow suid programs or scripts if this is the file system access control lists (ACLs; ACL = access control list).

Yet another departmental administration utility for manipulating can be used by departments is a command-line utility, that's done can be an input file that has a department name and contains a number mapping in the OS, to load. According to one embodiment such a command-line utility can be called "tregregs", and the use of such a utility may be, for example the form "tlregcompas [file name] "accept. For example, this command can be used during system boot. In one embodiment are z. For example, all departments in kernel level memory and stored in a stable storage 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, all syntax errors or semantic errors cause which are detected by tlcomp will report an error, and the command will be set immediately and no departments will be manipulated (eg added or deleted).

Various Utilities that include examples of various command-line utilities, are described above, which by an OS according to various Ausfüh approximately examples of the present invention available could be. Accordingly allow various embodiments the present invention, that the Department management (eg manipulation of rules and / or departments) from the user room in an efficient and user-friendly way accomplished can be. A user must, for. B. edit any configuration file in which such rules and / or Departments are defined, but instead can use command-line utilities To run, to a desired Administrative action (for example, Add or delete a rule and / or department). It is also pointed out that more Departmental Administration Utilities in addition to those listed above are described in certain embodiments of the present invention Invention may be included. Beside those command-line utilities that are predisposed to manipulate For example, commands can be used by command-line utilities to run such manipulation, such. B. rescaling an existing one Department, Add a process to a department and remove a process from a department, be provided.

Next enabling an efficient and easy-to-use method of administration of departments, can in certain embodiments Error prevention checks by the departmental administration utilities are made to helping a user to avoid mistakes with which he otherwise during of performing departmental administration. Traditionally, a user has to z. For example, edit a configuration to a department in a system add. If the user makes a mistake in the configuration file, such as B. Duplicating a department name (i.e., naming the department name) newly added Department as an already existing department), becomes such one Error not displayed to the user. Furthermore, the at a Configuration file made in systems of the prior art Changes typically only after the system has been booted. Consequently, can the user does not discover the error until after booting the system, or alternatively, the error may be fatal in that the System does not boot, what requires that Operating system must be reinstalled on the system.

Examples of error prevention tests, those defined by the departmental administration utilities in certain embodiments of the present invention for example, checking for Duplicate the department name and check that there is enough memory is. Although these exemplary error prevention tests are described in more detail below It should be noted that in support of the Many other types of error prevention checks by the departmental administration utilities in various embodiments accomplished can be. In one embodiment the duplication of the department name is checked by a utility (eg the tlcompadd or tlcompren utilities), that invokes "lns" to verify the existence Name not already in the "ins" security module exist. additionally can do that Utility when adding Check a new department (for example, with the tlcompadd command) to check ensure that sufficient There is memory available to give the "lns" security module the new name and password Add number image.

When a safety check allowed to only users with a proper permission all or the whole Part of the departmental administration utilities described above (eg for manipulating rules and / or departments). At least an embodiment the user has permission to use such departmental administration utilities Add to carry out a department, etc., if the user is located in the root on the system and on for the User ID has set or set "admin bit" set The admin bit is on special bit, that within the user's login process is set. The bit can only be accessed by logging in through secure Channels, which are controlled to be obtained. Such secure channels are over one secure shell connection "SSH" (SSH = secure shell) or by physically logging into the console of the machine.

Various embodiments of the present invention further enhance the efficiency of departmental management by allowing rules and / or departments to be dynamically manipulated (as described above) without requiring booting of the system so that the actions taken via the utilities became effective in the system. As above at 9 Generally, prior art systems require a user to edit a configuration file to manipulate the departments and / or departmental rules, and the system must be typi It may be necessary to boot before the changes made to the configuration file take effect in the system. Various embodiments of the present invention allow utility programs to be used to manipulate departments and / or departmental rules in a dynamic manner that does not require booting of the system for such manipulation to take effect in the system.

For example, in at least one embodiment, a configuration file includes text (eg, 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 reference to booting the system to allow the system to identify the departments that exist on it. If during the system runtime a user uses a departmental administration utility to add a new department (e.g., when using the tlcompadd command-line utility described above), such a utility will run automatically to automatically identify the number that represents the new department and stores such a number as well as the user-friendly name of the department in the memory 421A (from 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 a department. The utility may also update the configuration file to reflect such departmental manipulation (eg, adding a new department) so that if the system was to be booted, it would detect the proper state of the departments, thereby reducing the tampering (s) ) that have been made since the previous boot. Similarly, departmental rules can be manipulated in a dynamic manner. The departmental rules can z. For example, via the "tlrules" command described above, which can be executed to set the desired rule for a department to the rulebase 416 ( 4 ), and such a rule added will therefore be immediately effective. For example, after receiving an access request after adding a rule through the "tlrules" command, the security module takes action 421 to the rule database 416 to which includes the newly added rule that can be used to determine whether access is allowed to the requesting department. Therefore, the utilities are preferably executable to enable dynamic behavior of the departmental manipulation actions without having to boot the system.

With reference to 11 FIG. 12 is an exemplary work flow diagram for creating a department and then renaming it according to an embodiment of the present invention. In the operation block 1101 executes the "tlcompadd comp" command to create a new department named "comp." add. As described above, the effect of executing this command in accordance with at least one embodiment includes generating a number that is internally used to refer to the new department named "comp." In at least one embodiment, the department " comp "and its generated number are stored in a configuration file and copied to the operating system kernel level memory of the system to dynamically make the new department available.

Subsequently, in the block 1102 In this example, the command "tlcompren comp comp2" is executed to rename the comp section "comp" to "comp2." According to at least one embodiment, renaming a section names the configuration file and name-by-number mapping in the operating system kernel. Layer memory changed.

With reference to 12 Another exemplary workflow chart is provided that provides an example of switching a user's login process from one department to another according to one embodiment of the present invention. In the example of 12 becomes the operation block 1201 executed first by running the "tlgetcomp" command The "tlgetcomp" command is executed to display the current department, which in this example is sent back as "system" 1202 the "tlgetcomp web" command is executed to switch from the "system" section to the "web" section It should be noted that for the actual success of such a change from the "system" section to the "web" Department, the "Web" department must exist on the system (eg, previously added via the tlcompadd command). In accordance with at least one embodiment, a field is included in a process structure representing the department to which the process belongs (or is contained). For example, if a user logs in to the console by default in a Linux system, the user's login process structure has an additional field named "dev" (ie, department "dev"). When the user then launches a web daemon, the field in the process tree will also be called "dev" because it is a child process spawned by the user's login process Access control 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 look-up operation is made by the security module 421 executed to confirm whether "dev" is allowed to execute the requested syscall When the user executes the tlsetcomp, the department identifying name is dynamically changed in the process and the rules are then applied to the department.

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

As another example is in 13 Another exemplary workflow chart is provided that provides an example of using a departmental 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 executed within the "web" department, but the user's login process may currently reside in the "system" department. Unlike a change 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. Thus, at least one embodiment of the present invention provides a command that can be used to effectively switch 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 13 becomes the workblock 1301 first executed by running the "tlgetcomp" command The "tlgetcomp" command is executed to display the current department, which in this example is returned as a "system", so the current section of the login process is "system" (For example, the user's login process has a label labeled "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" section to the "Web" section, to execute the command to start the Web server daemon, and then ends tlsetcomp, leaving the Web server daemon working in the Web department. 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 caption in the process tree from "system" to "web" to start the web daemon as a child in the web department. It then returns to the "system" before exiting the "tlsetcomp" command. Therefore, if the "tlgetcomp" command is again in the block 1303 running, the department name "System" is displayed as the current department.

Claims (14)

Method for managing a processor-based system ( 400 ), whereby the system can be divided into several departments by labeling individual operating system kernels ( 401 . 402 . 403 ) defined in at least one configuration file, the departments ( 401 . 402 . 403 ) designate those resources which are allowed to access processes contained in the departments, where the resources have network interfaces and / or processes, and those in the departments ( 401 . 402 . 403 ) accessing system resources according to the rules set out in a rules database ( 416 ), the method comprising the step of providing at least one utility ( 404 ) executable to at least one department ( 401 . 402 . 403 ) manage. Method according to claim 1, wherein the at least one utility at least one command line service device having. Method according to Claim 2, in which the at least one command line service device ( 404 ) is executable to perform at least one type of departmental manipulation selected from the group consisting of the following steps: adding a new department ( 401 . 402 . 403 ), 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. Method according to Claim 2 or 3, in which the at least one command line service device ( 404 ) is executable to the at least one department ( 401 . 402 . 403 ) without requiring a user to edit the at least one configuration file. Method according to one of claims 1 to 4, further comprising the following step: providing at least one command line service device ( 404 ) that is executable to manipulate the at least one rule. Method according to Claim 5, in which the at least one command line service device ( 404 ) is executable to perform the at least one type of rule manipulation selected from the group consisting of the following steps: adding a new rule for a specific department ( 401 . 402 . 403 ), Removing an existing rule for a specific department and listing all rules for a specific department. A system for carrying out a method according to claim 1, comprising: at least one processor; an operating system that can be deployed by labeling individual kernel resources in departments ( 401 . 402 . 403 ) defined in at least one configuration file, the departments ( 401 . 402 . 403 ) designate those resources which are allowed to access the processes contained in the departments, the resources having network interfaces and / or processes, whereas those in the divisions ( 401 . 402 . 403 ) accessing system resources according to the rules set out in a rules database ( 416 ) are limited; and means for executing administration of the at least one department ( 401 . 402 . 403 ) without requiring the user to edit the at least one configuration file. A system according to claim 7, wherein the means for performing the management of the at least one department ( 401 . 402 . 403 ) also allows administrative actions that are started via the means for executing the administration to be performed dynamically without requiring that the system be rewritten for the management actions to take effect in the system. A system according to claim 7 or 8, wherein the step of managing the at least one department ( 401 . 402 . 403 ) includes at least one type of manipulation selected from the group of the following steps: adding a new department, renaming an existing department and removing an existing department, rescaling an existing department, adding a process to a department, and removing a process from one Department. A system according to any one of claims 7 to 9, wherein the step of carrying out the administration of the at least one department ( 401 . 402 . 403 ) comprises the step of switching from a first department to a second department. A system according to claim 10, wherein the step of carrying out the administration of the at least one department ( 401 . 402 . 403 ) comprises the step of manipulating at least one of the rules. The system of claim 11, 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: adding a new rule for a particular department ( 401 . 402 . 403 ), Removing an existing rule for a specific department and listing all the rules for a specific department. A system according to any of claims 7 to 12, wherein the means for executing the management comprises at least one operating system command line service ( 404 ) that is executable to the at least one department ( 401 . 402 . 403 ) manage. Computer readable medium on which a computer program code stored, which is a method according to one of claims 1 to 6 executes, when running on a computer.