SELinux by Example: Using Security Enhanced Linux SELinux: NSA's Open Source Security Enhanced Linux Linux Socket Programming by Example. Just like SELinux (Security Enhanced. Linux), SELinux by Example seems overly complex on the surface. The reader should certainly already have some. SELinux by Example - Ebook download as PDF File .pdf), Text File .txt) or read book online. SELinux by Example: Using Security Enhanced Linux.
|Language:||English, Spanish, Portuguese|
|Distribution:||Free* [*Registration needed]|
SELinux by Example. Using Security Enhanced Linux. Frank Mayer, Karl MacMillan, David Caplan. #-#. Upper Saddle River, NJ • Boston • Indianapolis • San. SELinux by Example: Using Security Enhanced Linux by David Caplan, Frank Mayer, Karl MacMillan. In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts1 set. The If the remote machine is aracer.mobi and your username on that Security-Enhanced Linux (SELinux) is an implementation of a mandatory.
This blog post will provide some details about the technology behind SELinux, its Android implementation as well as the different options to create, extend or remove policies. The content below mainly comes from Android website but we tried to shorten it to get to the point and to give examples from our BSP. What is SELinux? In a DAC system, a concept of ownership exists, whereby an owner of a particular resource controls access permissions associated with it.
This is generally coarse-grained and subject to unintended privilege escalation. A MAC system, however, consults a central authority for a decision on all access attempts. SELinux has been implemented as part of the Linux Security Module LSM framework, which recognizes various kernel objects, and sensitive actions performed on them.
At the point at which each of these actions would be performed, an LSM hook function is called to determine whether or not the action should be allowed based on the information for it stored in an opaque security object. SELinux provides an implementation for these hooks and management of these security objects, which combine with its own policy, to determine the access decisions.
Enforcement levels Become familiar with the following terms to understand how SELinux can be implemented to varying strengths. Permissive — SELinux security policy is not enforced, only logged. Enforcing — Security policy is enforced and logged. This choice is binary and determines whether your policy takes action or merely allows you to gather potential failures. Permissive is especially useful during implementation.
Unconfined — A very light policy that prohibits certain tasks and provides a temporary stop-gap during development. Confined — A custom-written policy designed for the service. That policy should define precisely what is allowed.
Unconfined policies are available to help implement SELinux in Android quickly. They are suitable for most root-level applications. But they should be converted to confined policies wherever possible over time to restrict each application to precisely the resources it needs.
Ideally, your policy is both in enforcing mode and confined. Unconfined policies in enforcement mode can mask potential violations that would have been logged in permissive mode with a confined policy.
Therefore, we strongly recommend partners implement true confined policies. Labels, rules and domains SELinux depends upon labels to match actions and policies. Labels determine what is allowed. Sockets, files, and processes all have labels in SELinux. SELinux decisions are based fundamentally on labels assigned to these objects and the policy defining how they may interact.
The objects are mapped to classes and the different types of access for each class are represented by permissions. The policy rules come in the form: allow domains types:classes permissions;, where: Domain — A label for the process or set of processes. Also called a domain type as it is just a type for a process. Type — A label for the object e. The goal of SELinux is to provide this improved security in a mainstream operating system that is. SELinux adds a flexible. Most MA C features implemented so far are a form of multilevel security modeled after governmental classification controls.
SELinux implements a more flexible form of MA C called type enforcement and an optional form of multilevel security. O perating systems have two forms of access control: Summary A pplication software is flawed and will remain flawed for the foreseeable future.
The reference monitor concept is a common means of describing access control in operating systems. DA C has a fundamental weakness in that it is subject to a variety of malicious software attacks. In a reference monitor. Real security cannot be achieved without better underlying operating system security. MA C is a way to avoid these weaknesses. Using Security Enhanced Linux Exercises 1.
Set up an SELinux system and install the strict example policy using the instructions in A ppendix A. Using Security Enhanced Linux Chapter 2.
This chapter focuses on the primary access control feature of SELinux. Gaining a conceptual understanding is necessary to effectively use and apply SELinux access controls.
Concepts In this chapter page 16 page 19 page 29 page 31 page 32 page 36 page 37 2. A s noted. Using Security Enhanced Linux 2. For simplicity. Table A nother useful command is id. They have no effect on access control. The user and role identifiers in a security context have little impact in the access control policy for type enforcement except for constraint enforcement.
More specifically. A ny relationship between these two is strictly provided via the login process according to conventions not directly enforced by the SELinux policy. For objects. In SELinux. The namespaces for each identifier are orthogonal. The use of "domain" and "domain type" to mean the type of a process is so common and pervasive that we do not attempt to avoid using the term domain. These attributes are protected by the kernel and set via a number of controlled means. Security Contexts for Type Enforcement A ll operating system access control is based on some type of access control attribute associated with objects and subjects.
A security context has three elements: The latter determines the file owner and group to decide which set of bits to use on a given access attempt. More on Security Contexts The security context is a simple. The usual format for specifying or displaying a security context is as follows: A s a convention. This means that both the standard Linux and enhanced SELinux access controls must be satisfied to access an object. For now.
Table summarizes the comparison of standard Linux and the added SELinux security attributes and access control. Examining Security Contexts SELinux modifies many system commands by adding the -Z option to display the security contexts of objects and subjects. SELinux uses the security contexts of a process and the object the process accesses. For historical reasons. A ll objects files. A ll objects and subjects have an associated security context. Note SELinux adds type enforcement to standard Linux.
For objects for example. The following. The password program implements its own internal security policy that allows ordinary users to change only their own password while allowing root to change any password. What type enforcement enables us to do is to ensure that only the password program or similar trusted programs can access the shadow file.
In a standard Linux system. SELinux allows no access by default. The way access is granted is by specifying access from a subject type that is. To perform this trusted job.
A depiction of an allow rule 2.
The challenge is determining the many thousands of accesses one must create to permit the system to work while ensuring that only the necessary permissions are granted. This means. The permissions contained within the braces are a subset of the permissions valid for an instance of the file object class. Type enforcement example: Figure depicts how the password program might work in an SELinux system using type enforcement.
In this case. This is just a naming convention used in most SELinux policies. The identifier file is the name of an object class defined in the policy in this case.
This rule has two type identifiers: To further explore type enforcement. Figure depicts the access allowed by the previous allow rule. This example shows the basic syntax of a TE allow rule.
A n allow rule has four elements: Source type s Usually the domain type of a process attempting access Target type s The type of an object being accessed by the process Object class es The class of object that the specified access is permitted Permission s The kind of access that the source type is allowed to the target type for the indicated object classes A s an example.
A s we discuss later. The translation of this rule would be as follows: In standard Linux security.
To illustrate. For ease o of explanation. Using Security Enhanced Linux In this example. Joe would not be a user ID. This could be disastrous. This problem brings us to the issue of domain transitions. If we examine such a file on disk. A s Joe's shell runs other programs. Both are necessary.
So how does Joe change passwords? The way Linux solves this problem is by making passwd a setuid to the root program. If you list the password program file on a typical Linux system.
A s discussed previously. The Problem of Domain Transitions If all we had to do was provide allowed access for processes to objects such as files. In a typical system. Two key things happen as a result of the successful execve call.
This is where type enforcement comes in. Figure shows these steps. Use of the setuid bit is well established in UNIX-like operating systems and is a simple and powerful feature. Domain Transitions A s previously shown in Figure Let's examine this figure in detail. A lthough the password program is fairly simple and highly trusted. Password program security in standard Linux setuid [View full size image] What actually happens when Joe runs the password program is that his shell will make a fork system call to create a near duplicate of itself.
Passwd program security in SELinux domain transitions [View full size image] Now our example is more complicated. This is a violation of the central security engineering principal of least privilege. This duplicate process still has the same real and effective user IDs joe and is still running the shell program bash.
Because root can access all files. What we would really like is a way to ensure least privilege for the password program and any other program that must have some privilege. For truly secure applications. In simple terms. Using Security Enhanced Linux Notice two things about this listing. Providing for secure domain transition is analogous to the concept of setuid programs.
A s a result. In this way. Standard Linux security requires that the calling user ID still joe have x access. The password program needs to run as root to access the shadow file. This is the so-called setuid bit and means that for any process that executes this file. First the s in the x spot for the owner permission. First notice that we have added the three types we showed previously. What this permission does is define which executable files and therefore which programs may "enter" a domain.
First it forks a copy of itself. This concept holds for processes. For a domain transition to succeed. This permission is needed to allow the type of a process' security context to change.
This rule provides a means for the SELinux policy to specify default transitions that should be attempted if an explicit transition was not requested. The execve system call is the only way to change a domain type. Let's look at the rules from Figure Such rules cause a default domain transition to be attempted. A ll Joe wants to do is run the password program.
Joe does not want to know anything about access control or types. Let's add the following type transition rule to the allow rules: Now the issue is how does Joe indicate that he wants a domain transition to occur.
The entrypoint permission is a rather valuable permission in SELinux. The syntax of this rule differs from the allow rule. These three rules together provide the necessary access for a domain transition to occur.
Warning The concept of entrypoint permission is extremely important. For a domain transition. Let's now look at the next allow rules from Figure There are ways that a programmer or user can explicitly request a domain transition if allowed.
Let's now look at the final rule: This is a powerful security control. If you did not fully understand the preceding example. The above rules allow only the domain transition. The SELinux execute file permission is essentially the same permission as x access for files in standard Linux. The process' current domain type has access to the entry point file type. In this final rule. Recall that all system resources are encapsulated in an object class. The first rule is as follows: When all three of these permissions are permitted in a TE policy.
The process' current or old domain type has 3. You must still provide the three types of access required for a domain transition to successfully occur.
Recall our description of how a shell program actually works. The shell "stats" the file before trying to execute. This makes type enforcement less obtrusive to the user. The process' new domain type has enTRypoint access to an executable file type. We need a way to have the system initiate a domain transition by default. This is the first allow rule we have seen that did not provide access to file objects. Default Domain Transitions: Roles limit the types to which a process may transition based on the role identifier in the process' security context.
We also added a new rule. Joe would not be authorized to run the password program even though the TE rules would allow his domain type the access. A lthough according to the type enforcement rules. A policy writer can define roles that are further constrained and then associate these roles to specific users.
Take our password program example in Figure Joe's role must also be allowed to be associated with the new domain type for the transition to occur. Without this role statement. The role statement declares role identifiers and associates types with the declared role. To support MLS. If the high security level is missing. The MLS rules for accessing objects are much the same as discussed in Chapter 1. For the vast majority of security applications.
In recognition of these situations. These sensitivities and categories are used to reflect real information confidentiality or user clearances.. In most SELinux policies. These two security levels are called low or current for processes and high or clearance for processes. In practice. If MLS is enabled. Given the domain relationship. The basic concept of MLS was introduced in Chapter 1.
What causes security levels to be related via dominance rather than equality are the categories. For purposes of this overview. Unlike equality where a level is either higher than. A range of levels is typically used for processes that are considered trusted subjects that is. The security level used by MLS systems is a combination of a hierarchical sensitivity and a set including the null set of nonhierarchical categories.
You need two terminal windows or virtual consoles to do this walkthrough. For our examples. O f course.
A ppendix A. A s an exercise. We have already mentioned the -Z option added to some system commands. Run apol and open the strict policy file. If you examine the security context of these two files.
In the first window. Do you want to choose a different one?
Note In a strict policy such as the one we use for our examples. Changing password for joe current UNIX password: This starts the password program and prompts for the user's current password. To set the system in permissive mode. The configuration file config in that directory indicates the policy to be used and loaded on boot. Do not enter the password.
Commands such as ls and ps display the security contexts of files and processes. If not. You can also configure the system to boot in permissive mode in this file. The simplest way to check the current mode of SELinux is to run the getenforce command. That is why you need to su to root first. Your default context is root: The apol for "analyze policy" tool is a sophisticated SELinux policy analysis tool that we use throughout the book to examine SELinux policies.
In the second terminal. A useful tool for examining the contents of a policy is the policy analysis tool apol created by Tresys Technology and distributed in a package of SELinux tools called SeTools see A ppendix D. A ppendix D provides information on how to obtain the SeTools package. Revisiting the Passwd Example Throughout this chapter. You might also be able to work with other distributions.
Run the command apol to determine whether the tool is present on your system. To witness how the process of domain transitions work.
Because you are in permissive mode. For our exercises. This mode is useful when first learning about SELinux. To return it to enforcing mode. Policy Rules. Take some time to explore the Policy Components and Policy Rules tabs and become familiar with both portions of the policy we discussed in this chapter and the apol tool itself. A nalysis. You will find it useful throughout Part II. Roles are used to associate the allowed domain types into which a process running on behalf of a user may transition.
The capability for a program to enter into a domain that is. The security context contains three elements: SELinux provides an optional MLS access control mechanism that provides further access restrictions for a certain class of data sensitivity applications.
This allows sets of type enforcement allowed capabilities to be grouped together and authorized for a user as a role. O ne of the key benefits of type enforcement is the ability to control which programs may run with a given domain type. Summary SELinux access control is based on a security context associated with all system resources including processes. A ccess is granted for specified object classes using a fine-grained set of permissions defined for each object class.
A ccess is granted between subjects that is. The type identifier is the primary basis for access control. SELinux does not directly use the role identifiers in a security context for access control. MLS also extends the security context to include a current or low security level and an optional high or clearance security level. Why or why not? Can you read For SELinux to allow a domain transition. What are the access permissions required and between what types?
What do the types represent? In answering Q uestion 4. What are the possible states in which SELinux can run and what do each mean? How do the settings in this file differ from using the setenforce command? Extra credit: What is a "domain" and how is it related to or different from a type? What are the access control attributes used by SELinux type enforcement security to control access? What portion of the attribute is used by type enforcement for access control?
Let's assume that we have a file named datafile with the following security attributes: How and why? The SELinux architecture reflects its origins in secure microkernel research.
The SELinux policy language is flexible. Using Security Enhanced Linux Chapter 3. Architecture In this chapter page 40 page 43 page 47 page 53 page 54 3. This architecture is also extensible into user-space servers.
LSM Framework The idea behind the LSM framework is to allow security modules to plug into the kernel that can further restrict the default Linux identity-based discretionary access control DA C security. The Flask architecture has three primary components. General Security Support for the Linux Kernel. Figure illustrates the basic LSM framework. The LSM framework is comprehensive. These hooks are usually placed after the standard Linux access checks but before the actual resource is accessed by the kernel on behalf of the caller.
SELinux is loaded into the kernel as an LSM module and is consulted for additional access validation before the access attempt is allowed.
LSM hook architecture   C. Each LSM hook translates into one or more access permissions for one or more object classes. In its current form. Using Security Enhanced Linux 3. LSM provides a set of hooks in the kernel system call logic.
Examples of kernel object managers include the filesystem. SELinux does not fully implement access revocation on policy change. We expect that there will be further research to improve access revocation in SELinux. Just having a file descriptor does not mean access to the file will be granted. Object managers are responsible for enforcing the policy decisions of the security server for the set of resources they manage.
The LSM hooks then enforce those decisions by allowing or denying access to the kernel resource. The policy used for the security server is embodied in a set of rules that is loaded via the policy management interface. This is no worse than standard Linux. Using Security Enhanced Linux The Flask design makes a strong distinction between security policy decision making and enforcement functions.
For the kernel. In these cases. These rules can differ from system to system. In the LSM architecture. Policy decision making is the job of the security server. The A V C caches decisions made by the security server for subsequent access checks and thus provides significant performance improvements for access validation. The name security server reflects SELinux's micorkenel roots. The A V C is invalidated when a policy is loaded.
The architecture is designed such that the security server could be completely replaced with logic that implements an entirely new access control policy without changing the rest of the architecture. For some resources. The primary goals are as follows: Provide better support for user-space object managers by providing a user-space security server that makes access decisions for the user portion of the policy Provide fine-grained access control for the policy itself by building a policy management server that is a userspace object manager whose object classes represent portions of the policy Collectively.
For kernel resources. This increases storage cost within the kernel for abstraction not related to the kernel and can negatively impact the cost of kernel policy validation for A V C misses. The relationship of class definitions in the policy and with those in the kernel code results in an unfortunate dependency between the userspace policy and the code. The kernel provides no way to manage this possible conflict.
The second weakness with this approach is that kernel security server is managing policy for object classes for object managers that are not in the kernel. Userspace Object Managers O ne of the powerful features of the SELinux architecture is that it can be applied to userspace resources and to kernel resources. The primary difference is that userspace object managers cannot use the kernel A V C.
Each of these servers provides abstract resources windows. The A V C handles cache misses and queries the kernel on behalf of the object manager. This project has two primary goals and a number of secondary goals. This section examines two ways that the SELinux architecture supports userspace servers. Each server must have its own.
A nother difference is that userspace object managers do not have LSM hooks. A lthough straightforward. Policy Server Architecture To address the weaknesses of using the kernel security server for userspace object managers and to enhance the security capabilities of SELinux.
Examples of userspace servers in Linux that can be enhanced to enforce access control over their resources include the X server and database services. The A V C functionality for userspace servers is contained in the library libselinux. The kernel security server contains the entire security policy. Userspace object managers using kernel security server [View full size image] In this method. Figure depicts the architecture of the policy server. A t the time of this writing.
A V Cs in various userspace object managers register with the USSS and not the kernel for policy update and cache coherency functions. You can check the status of this work at http: With the PMS. The policy server architecture has a number of strengths in addition to the removal of the kernel's responsibility for userspace resources and the fine-grained access for policy management. The second major function of the PMS is to split the system policy into kernel and user portions and load them respectively into the kernel security server and userspace security server USSS.
The PMS is itself a userspace object manager in that it creates object classes representing policy resources and enforces a fine-grained access control policy over those resources. Using Security Enhanced Linux In the policy server architecture.
Because the PMS is a running server. The difference between the two approaches is masked by libselinux providing backward compatibility with existing work. Better yet. Userspace object managers query the USSS and not the kernel.
This feature alone provides significant security enhancement for SELinux. Higher-level languages and other more abstract ways to create policies are being developed. This source file. The multilevel security MLS policy. A separate related mechanism.
The next section contains the type enforcement statements. We discuss constraints in Chapter 7. This is the section that policy writers spend most of their time writing. Using and applying SELinux is all about writing and understanding policies.
We discuss types and the core TE rules in detail in Chapter 5. Organization of policy source file policy. It contains all the type declarations and all the TE rules including all allow. We discuss the specific object classes and their associated permissions in Chapter 4. This section also contains rules and declarations for roles and users in the policy. This section tells SELinux how to treat filesystems for the purpose of labeling and contains the rules for labeling transient objects that are created at runtime.
In the previous section. You can think of the checkpolicy language as analogous to assembly language. These and other topics relating to object labeling are discussed in Chapter The Native SELinux Policy Language Compiler The primary way to construct a policy file for the kernel is to compile it from a source policy file using the checkpolicy program.
O ne strength of SELinux is that its policy rules are not static. Constraints provide a means of further limiting the TE policy beyond what the TE rules permit. Figure illustrates the primary sections of a policy source file expected by checkpolicy. Roles and users. In Part II of this book. This section also defines the permissions for each object class.
In this section. The language syntax supported by checkpolicy is the native. A ll objects must be labeled with a security context for SELinux to enforce access control. The policy. The subset of the policy language includes most of the type enforcement. Figure shows this type of construction. These changes differ for base and nonbase modules.
We suggest you experiment with policy writing with the system in permissive mode setenforce 0 until you become more familiar with the policy language and its ramifications. Loadable Policy Modules A new method for creating a modular policy is called loadable modules. Because SELinux policies are usually quite large and complex. In the loadable module case. The policy modules are essentially concatenated together into a single large source file that is.
You will need to compile your modifications into a complete policy file and experiment with your modifications by loading the new policy into the kernel and experiencing the resulting changes in the kernel's access control enforcement. Build and load process for SELinux policy using source modules [View full size image] Starting from the left side of this figure.
With loadable modules. Building and Installing Monolithic Policies A s you read through the remainder of this book. The original and still widely used method. Fedora Core 5 FC5 has adopted the loadable module infrastructure for future versions. In any case. While you are learning about SELinux and experimenting with the language.
Source modules are combined as text files through a combination of shell scripts. There are a couple of different means to make a policy modular. Loadable modules are also the basis for the policy server discussed earlier in this chapter. Using Security Enhanced Linux Examining the policy. We discuss the languages changes resulting form loadable modules in detail using sidebars throughout Part II.
Before you can complete these actions. You create the base module much like you create the monolithic policy. The example policy build method see Chapter Tip Remember that if you install your policy. The base module uses the same policy language as monolithic policies with minor additions.
You can add all other policy rules in a modular fashion when you install their associated software package. The additional language features are used to manage dependencies between modules. Nonbase that is.
Later in the book. Loadable modules introduce policy syntax changes that are designed to ease the division of the policy into separate. This is a policy that is constructed as a single binary policy file by checkpolicy that is directly loaded into the kernel. The rest of the policy is created as separate loadable modules. Do everything that make policy does plus install the binary policy file such that it will be loaded into the kernel at boot time and the policy configuration files.
Using Security Enhanced Linux the source policy using checkpolicy into a binary policy file assuming no errors! In the policy we use in Part II. Policy source directories usually have a Makefile that automates this process for you. Don't panic. A t this point in this book. SELinux policies tend to be large and complex. A ccess decisions are made by the SELinux security server.
The policy server will also provide fine-grained access control to the policy itself. In the case of loadable modules. A dditional software packages will have their portion of the policy installed as separate loadable modules. This is the method being adopted by FC5. The emerging policy server architecture enhances support for userspace object managers by providing a userspace security server that will enforce all portions of the policy relating to userspace objects.
This approach requires the kernel to hold the policy for all userspace managers and to be aware of all userspace object classes. The security policy enforced by the security server is loaded into the kernel via a privileged userspace interface. A common method is to use source modules. In its basic form. The SELinux framework also supports userspace object managers through the libselinux library.
A second modularity approach provides for loadable modules. The A V C provides performance improvement for access validation. Go to the example policy source directory and make policy to create the policy.
In the LSM framework. Why do you think userspace object managers cannot use the kernel access validation cache like they do the kernel security server? In the policy server architecture. A ny ideas what might be the cause of that difference? Why do you think that is necessary? A lthough SELinux does not fully implement access revocation on policy change. In the kernel. When a new policy is loaded into the kernel. Use apol to examine the number of allow rules in each file and notice the large difference.
Explain the reasons for this difference. Standard Linux access control does not implement access revocation for regular files. Object Classes and Permissions In this chapter page 60 page 61 page 67 page 73 page 84 page 86 page 87 4. A ppendix C. Using Security Enhanced Linux Chapter 4. We discuss the policy language statements that define object classes and permissions the kernel supports and provide an overview of the kernel object classes standard in a SELinux system.
O bject class refers to the entire category of resources files. Each of these permissions. O bject classes represent categories of resources such as files and sockets. A n object class represents all resources of a certain kind for example.
The set of object classes available depends on the version of SELinux and its Linux kernel. A s discussed in Chapter 2. O ften the terms object class and object are used interchangeably. A n instance of an object class for example.
The set of permissions defined for an object class also called an access vector represents all the possible access that can be allowed to the resources represented by that object class. O ver time. The object class file specifies the category of resource. Using Security Enhanced Linux 4. For those kernels that support the Netlink socket.
In this rule. The permissions in this ruleread. Declaring Object Classes O bject classes are declared using the class declaration statement. Class declarations are valid only in monolithic policies and base loadable modules. Common Permissions The common permission statement allows the creation of sets of permissions that we associate as a group with two or more object classes. The full syntax of the common permission statement is shown in the sidebar on page The class declaration statement simply declares an object class name and nothing else.
O bject class names have a separate namespace. It is useful to understand the object class and permission declaration syntax because it allows us to understand the supported object classes and permissions in the policy version we are using.
Unlike other aspects of the SELinux policy language. A dding or changing object classes or permissions requires changes both to the policy and to the system code that will enforce access control based on the new object classes or permissions. It is possible. Adding New Object Classes and Permissions A dding new object classes and changing the permissions on existing object classes are complex tasks that should normally be undertaken only when changing the actual system code itself.
In fact. A common permission statement to declare these file-related permissions in SELinux is as follows: The full syntax of the class declaration statement is as follows: Simply adding an object class or permission to the policy without changing the code will likely have no effect other than wasting kernel memory. For this reason. They are not valid in conditional statements and non-base loadable modules. The first is called common permissions and allows us to create permissions that we associate with an object class as a group.
You can see the full syntax for the class statement in the sidebar on page Notice that the class declaration statement does not end in a semicolon like many other policy statements. The second method is called class-specific permissions and allows us to declare permissions specific to that object class alone. A n example of the type of change that would warrant a change in the object classes and permissions is the addition of a new form of interprocess communication IPC to the kernel.
Class Declaration Statement Syntax The class declaration statement allows you to declare object class names. Common permissions are useful when similar object classes for example. In this partial example. A common permission statement by itself has no effect. Notice that this statement also does not end in a semicolon.
It is possible to have an object class that has only common permissions. The result of this statement is that the valid permissions for the object class dir are all those defined earlier for the common permission file and the five permissions specific to dir. Common permission statements are valid only in monolithic policies and base loadable modules.
Associating Permissions with Object Classes We associate permissions with an object class using the access vector statement. A s with object classes. We use the access vector statement to associate common and class-specific permissions.
The class declaration and access vector statements are distinct despite beginning with the same keyword. This can lead to some confusion if we are not careful. We can also associate common permissions using the optional inherits keyword in the access vector statement. The full syntax for the access vector statement is shown in the sidebar on page The full syntax for the common permission statement is as follows: The access vector statement must provide a previously declared object class name dir and then provide one or more permissions.
O ne or more permission identifiers in a space-separated list. Common permissions can be associated with multiple object classes. The following access vector statement is a complete access vector statement for dir associating the common permission file. The previous access vector statement would result in the dir object class having one class-specific permission: Common Permission Statement Syntax The common permission statement allows you to declare a common permission name that has a set of permissions that can be associated with an object class as a group.
A lthough the names are the same. A t a minimum. They are not valid in conditional statements and nonbase loadable modules.
A ccess vector statements are valid only in monolithic policies and base loadable modules. The full syntax for the access vector statement is as follows: A previously declared common permission set name. Using Security Enhanced Linux Likewise. Character devices are those devices that programs read or write data to or from as a stream of bytes.
This object class controls global operations such as mounting or querying quotas. The most difficult part of writing good policy is understanding the semantics of the object classes and permissions and the implications of those semantics in the context of an application policy on a particular system.
Tools and technology are emerging that use the richness of SELinux to provide sophisticated security without the user needing to be aware of the underlying complexity. This inheritance is not always desirable. File descriptors are handles. Directions in SELinux Networking. In reality. It is important to note. Using this object class it is possible to prevent the usage of file descriptors passed or inherited between processes.
In UNIX-like systems. We discuss the UNIX domain socket object classes and their relationships to socket files in the next section. It is important in many situations to distinguish between regular files and symbolic links to prevent common attacks.
O rdinary files are those files that store data.
Network-Related Object Classes The network-related object classes represent network resource such as network interfaces. This strategy ignores the fact that file descriptors are distinct resources that can be passed between processes. A n FC4 system has more than 40 kernel object classes representing all the resources provided by the kernel.
A ll filesystems of a particular type for example. The number of object classes illustrates a basic philosophy in SELinux to represent the kernel resources as completely and accurately as possible. Slides available at http: File-Related Object Classes The first category of object classes are those related to files and other resources stored in filesystems. Presentation at the Linux Kernel Networking Summit.
Table summarizes the file-related object classes. O ur goal is to describe the object classes and how the system resources are mapped to those object classes.
The filesystem object class represents a mounted filesystem. The current object classes are sufficient to allow comprehensive control over networking on a single system. To ease understanding.