Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: user guide draft: "SELinux Contexts and Attributes" review Date: Wed, 27 Aug 2008 16:54:54 +1000
The following is a draft of the SELinux Contexts and Attributes sections for the SELinux User Guide. Any comments and corrections are appreciated. Thanks. As previously mentioned, on Linux operating systems, files, directories, sockets, devices, and so on, are called objects, and processes, such as a user running a command, the Firefox application, and the Apache HTTP Server, are called subjects. SELinux provides the Type Enforcement security model. To enforce this, subjects and objects are labeled with an SELinux context that contains additional information, such as an SELinux user, role, and type. When running SELinux, all of this information is used to make access control decisions. The following is an example of the additional SELinux information used on Linux operating systems that use SELinux. This information is called the SELinux context, and is viewed using the ls -Z command:
-rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1 SELinux contexts follow the SELinux user:role:type:category syntax: SELinux user: The SELinux user identity is an identity known to the policy that is authorized for a specific set of roles and for a specific MLS range. Each Linux user account is mapped to an SELinux user identity when a user login session is created, and the mapped SELinux user identity is used in the security context for processes in that session in order to bound what roles and levels they can enter[1]. Run the /usr/sbin/semanage login -l command to view a list of mappings between SELinux and Linux user accounts: Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0-s0:c0.c1023 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 test2user user_u s0 xguest xguest_u s0 Output may differ from system to system. The Login Name column lists Linux users, and the the SELinux User column lists which SELinux user is mapped to which Linux user. The SELinux user does not restrict the access subjects have to objects. The last column, MLS/MCS Range, are categories that are used by Multi-Level Security (MLS) and Mutli-Category Security (MCS). MLS and MCS categories are discussed briefly later. role: Part of SELinux is the Role Based Access Control (RBAC) security model. The role is an attribute of RBAC. Roles are associated with domain types, and domain types are associated with SELinux users. Roles are important when writing policies, as they restrict domain transitions, but they do not restrict the access subjects have to objects, and as such, they are not discussed in detail in this guide. type: The type is an attribute of Type Enforcement. The type defines a domain type for subjects, and a type for objects. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific rule exists that allows it. category: The category is an attribute of Multi-Level Security (MLS) and Multi-Category Security (MCS). Categories are used to categorize data, and identify its sensitivity or security level. Standard SELinux policy supports MCS; however, it is not heavily used. MCS allows users, at their own discretion, to add a category to a piece of data, for example, PatientRecord or CompanyConfidential. There is only a single security level, s0. MLS labels data with both categories (CompanyConfidential) and a sensitivity level. MLS enforces the Bell-LaPadula Mandatory Access Model, and is used in Labeled Security Protection Profile (LSPP) environments. Domain Transitions On Linux operating systems that run SELinux, processes, such as a user running the less command, or an Apache HTTP server, are called subjects. An executable object transitions to a subject, and a subject runs in a domain. This transition is called a domain transition. The following example demonstrates a domain transition:
$ ls -Z /usr/bin/passwd
The passwd application needs to access the /etc/shadow object, which is labeled with the shadow_t file type:
$ ls -Z /etc/shadow
2. An SELinux policy rule states that subjects running in the passwd_t domain type are allowed to read and write to objects that are labeled with the shadow_t file type. The /etc/shadow object is the only object that is labeled with the shadow_t file type. 3. When a user runs the /usr/bin/passwd command, the application transitions to a subject (a process), which is running in the passwd_t domain type. With SELinux, since the default action is to deny, and a rule exists that allows (among other things) applications running in the passwd_t domain type to access objects labeled with the shadow_t file type, the passwd application is allowed to access /etc/shadow, and update the user's password. This example is not exhaustive, and is used as a basic example to explain domain transition. Although there is an actual rule that allows subjects running in the passwd_t domain type to access objects labeled with the shadow_t file type, other rules must be met before the object can successfully transition. SELinux Contexts for Subjects On Linux operating systems the run SELinux, when an application is executed, that application transitions to a subject and runs in a domain. The SELinux context for subjects is viewed using the pstree -Z command. For example:
| | `-passwd(`unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023') 4. In the first tab, cancel passwd application. In this example, when the /usr/bin/passwd object, which is labeled with the passwd_exec_t file type, is executed, it transitions to a subject that runs in the passwd_t domain type. Remember: the type defines a domain type for subjects, and a type for objects. To view the SELinux contexts for all subjects, run the pstree -Z command. The following is an example of the pstree -Z output, and may differ on your system: ├─NetworkManager(`system_u:system_r:NetworkManager_t:s0') │ └─{NetworkManager}(`system_u:system_r:NetworkManager_t:s0') ├─acpid(`system_u:system_r:apmd_t:s0') ├─anacron(`system_u:system_r:system_crond_t:s0') ├─atd(`system_u:system_r:crond_t:s0-s0:c0.c1023') ├─auditd(`system_u:system_r:auditd_t:s0') By default, the SELinux targeted policy is used. When using targeted policy, most subjects (processes) use the system_r role. Type enforcement then separates each domain. Run the id command to view the SELinux context associated with your Linux user: uid=500(user) gid=500(group) groups=500(group) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 On Fedora 10, Linux users run unconfined by default. This SELinux context shows that the Linux user is mapped to the SELinux unconfined_u user, running as the unconfined_r role, and is running in the unconfined_t domain type. SELinux rules do not affect Linux users that are running in the unconfined_t domain type; however, UNIX permissions still apply. [1] Smalley, Stephen. "Re: SELinux User Guide: weekly report 20080822". Email to Murray McAllister, 25 August 2008. Any edits were done by Murray McAllister.
-- subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Wed, 27 Aug 2008 09:47:16 -0400
On Wed, 2008-08-27 at 16:54 +1000, Murray McAllister wrote:
As before, this is generally true of operating systems not just Linux.
> SELinux provides the Type Enforcement SELinux provides flexible MAC that can support many different security models, and the example security server included in SELinux provides a combination of role-based access control (RBAC), Type Enforcement (TE), and optionally Multi-Level Security (MLS).
> To enforce this, subjects and objects are labeled with That should be :level or :range rather than just :category, where a level is a sensitivity followed by an optional list of categories.
> SELinux user: The SELinux user identity is an identity known to the Well, it does indirectly, by limiting what roles and levels are accessible to the subject. It also can play a role in the constraints portion of the policy configuration, e.g. refpolicy doesn't allow a process to relabel a file with a different SELinux user identity unless its domain has the can_change_object_identity attribute.
> The last column, MLS/MCS Range, are SELinux users are authorized for roles, and roles are authorized for domain types. Domain types are not directly associated with SELinux users - the role serves as an intermediary.
> Roles Not directly, but indirectly since what roles you can enter determines what domain types you can enter and thus ultimately what object types you can access. The role is a coarse-grained boundary on privilege escalation.
> type: The type is an attribute of Type Enforcement. The type defines a Again, this should be level or range rather than just category, where a level is a sensitivity and an optional list of categories and a range is a current/low level and a clearance/high level. You may wish to note that people who wish to use the MLS restrictions need to install a separate -mls policy package and make it the default.
> Domain Transitions Not sure you need to keep repeating this.
> An executable object transitions to a subject, and a subject runs in a A process in one domain transitions to another domain by executing a new program with the entrypoint type for the new domain.
> The following Also /etc/gshadow. And the backup copies of both files created whenever they are updated (e.g. /etc/shadow-). And any intermediate files created during the update transaction that contain any shadow password data - the point is that any file containing such data ought to be labeled with the shadow_t type so that it can be consistently protected throughout.
> 3. When a user runs the /usr/bin/passwd command, the application The user shell process transitions to the passwd_t domain upon executing the /usr/bin/passwd command.
> With SELinux, since the default action is to deny, and a Not sure what you mean by "the object can successfully transition" - processes transition from one domain to another upon executing a new program.
In the passwd example, the guarantees we are getting from Type
Enforcement are:
> SELinux Contexts for Subjects Again, not sure you need to keep repeating this, and technically it is "the process transitions to a new domain upon executing a program with the entrypoint type for that domain".
> The SELinux context for subjects is viewed using the pstree -Z Or just ps -eZ.
> For example: system_r is for system processes like daemons. Targeted policy used to use system_r for everything and not use any user roles. In F9, it uses unconfined_r for unconfined users.
> Run the id command to view the SELinux context associated with your -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Mon, 01 Sep 2008 17:03:46 +1000
Stephen Smalley wrote: > On Wed, 2008-08-27 at 16:54 +1000, Murray McAllister wrote: >> Hi, >> >> The following is a draft of the SELinux Contexts and Attributes sections >> for the SELinux User Guide. Any comments and corrections are appreciated. >> >> Thanks. >> >> As previously mentioned, on Linux operating systems, files, directories, >> sockets, devices, and so on, are called objects, and processes, such as >> a user running a command, the Firefox application, and the Apache HTTP >> Server, are called subjects. > > As before, this is generally true of operating systems not just Linux. > >> SELinux provides the Type Enforcement >> security model. > > SELinux provides flexible MAC that can support many different security > models, and the example security server included in SELinux provides a > combination of role-based access control (RBAC), Type Enforcement (TE), > and optionally Multi-Level Security (MLS). How about: ...SELinux provides flexible MAC that supports a variety of different security models. On Fedora 10, SELinux provides a combination of role-based access control (RBAC), Type Enforcement® (TE), and optionally, Multi-Level Security (MLS). Subjects and objects are labeled with an SELinux context that contains additional information, such as an SELinux user, role, and a type. When running SELinux, all of this information is used to make access control decisions. > >> To enforce this, subjects and objects are labeled with >> an SELinux context that contains additional information, such as an >> SELinux user, role, and type. When running SELinux, all of this >> information is used to make access control decisions. >> >> The following is an example of the additional SELinux information used >> on Linux operating systems that use SELinux. This information is called >> the SELinux context, and is viewed using the ls -Z command: >> >> -rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1 >> >> SELinux contexts follow the SELinux user:role:type:category syntax: > > That should be :level or :range rather than just :category, where a > level is a sensitivity followed by an optional list of categories. How about "...role:type:sensitivity"? > >> SELinux user: The SELinux user identity is an identity known to the >> policy that is authorized for a specific set of roles and for a specific >> MLS range. Each Linux user account is mapped to an SELinux user identity >> when a user login session is created, and the mapped SELinux user >> identity is used in the security context for processes in that session >> in order to bound what roles and levels they can enter[1]. Run the >> /usr/sbin/semanage login -l command to view a list of mappings between >> SELinux and Linux user accounts: >> >> Login Name SELinux User MLS/MCS Range >> >> __default__ unconfined_u s0-s0:c0.c1023 >> root unconfined_u s0-s0:c0.c1023 >> system_u system_u s0-s0:c0.c1023 >> test2user user_u s0 >> xguest xguest_u s0 >> >> Output may differ from system to system. The Login Name column lists >> Linux users, and the the SELinux User column lists which SELinux user is >> mapped to which Linux user. The SELinux user does not restrict the >> access subjects have to objects. > > Well, it does indirectly, by limiting what roles and levels are > accessible to the subject. It also can play a role in the constraints > portion of the policy configuration, e.g. refpolicy doesn't allow a > process to relabel a file with a different SELinux user identity unless > its domain has the can_change_object_identity attribute. Output may differ from system to system. The Login Name column lists Linux users, and the the SELinux User column lists which SELinux user is mapped to which Linux user. For subjects, the SELinux user limits which roles and levels are accessible. The last column, MLS/MCS Range, are levels and categories that are used by Multi-Level Security (MLS) and Mutli-Category Security (MCS). MLS and MCS levels and categories are discussed briefly later. Would removing "For subjects" from the 3rd sentence make it accurate? > >> The last column, MLS/MCS Range, are >> categories that are used by Multi-Level Security (MLS) and >> Mutli-Category Security (MCS). MLS and MCS categories are discussed >> briefly later. >> >> role: Part of SELinux is the Role Based Access Control (RBAC) security >> model. The role is an attribute of RBAC. Roles are associated with >> domain types, and domain types are associated with SELinux users. > > SELinux users are authorized for roles, and roles are authorized for > domain types. Domain types are not directly associated with SELinux > users - the role serves as an intermediary. > >> Roles >> are important when writing policies, as they restrict domain >> transitions, but they do not restrict the access subjects have to >> objects, and as such, they are not discussed in detail in this guide. > > Not directly, but indirectly since what roles you can enter determines > what domain types you can enter and thus ultimately what object types > you can access. The role is a coarse-grained boundary on privilege > escalation.
role:
> >> type: The type is an attribute of Type Enforcement. The type defines a >> domain type for subjects, and a type for objects. SELinux policy rules >> define how types access each other, whether it be a domain accessing a >> type, or a domain accessing another domain. Access is only allowed if a >> specific rule exists that allows it. >> >> category: The category is an attribute of Multi-Level Security (MLS) and >> Multi-Category Security (MCS). Categories are used to categorize data, >> and identify its sensitivity or security level. Standard SELinux policy >> supports MCS; however, it is not heavily used. MCS allows users, at >> their own discretion, to add a category to a piece of data, for example, >> PatientRecord or CompanyConfidential. There is only a single security >> level, s0. MLS labels data with both categories (CompanyConfidential) >> and a sensitivity level. MLS enforces the Bell-LaPadula Mandatory Access >> Model, and is used in Labeled Security Protection Profile (LSPP) >> environments. > > Again, this should be level or range rather than just category, where a > level is a sensitivity and an optional list of categories and a range is > a current/low level and a clearance/high level. You may wish to note > that people who wish to use the MLS restrictions need to install a > separate -mls policy package and make it the default. This part is in progress. I do not understand the difference between levels/categories and ranges. Can you recommend any papers or books on this? This is what is there now, keeping in mind I don't understand: The level is an attribute of MLS and Multi-Category Security (MCS). There is a single sensitivity level, s0, which is the only sensitivity level used. This level is used when running the SELinux MLS policy, but not when running the SELinux targeted policy. An optional list of categories can be used to categorize data. Standard SELinux policy supports MCS; however, it is not heavily used. MCS allows users, at their own discretion, to add a category to a piece of data, for example, CompanyConfidential or PatientRecord. MLS labels data with both a sensitivity level and categories (such as CompanyConfidential). MLS enforces the Bell-LaPadula Mandatory Access Model, and is used in Labeled Security Protection Profile (LSPP) environments. To use MLS restrictions, install the selinux-policy-mls package, and configure MLS to be the default SELinux policy. > >> Domain Transitions >> >> On Linux operating systems that run SELinux, processes, such as a user >> running the less command, or an Apache HTTP server, are called subjects. > > Not sure you need to keep repeating this. Removed. > >> An executable object transitions to a subject, and a subject runs in a >> domain. This transition is called a domain transition. > > A process in one domain transitions to another domain by executing a new > program with the entrypoint type for the new domain. How about: A subject in one domain transitions to another domain by executing an object that is labeled with a file type that has entrypoint permission for the new domain. The entrypoint permission is used in SELinux policy, and controls which domains an object can enter. The following example... > >> The following >> example demonstrates a domain transition: >> >> 1. A users wants to change their password. To change their password, >> they run the /usr/bin/passwd command. The /usr/bin/passwd file object is >> labeled with the passwd_exec_t file type: >> >> $ ls -Z /usr/bin/passwd >> -rwsr-xr-x root root system_u:object_r:passwd_exec_t:s0 /usr/bin/passwd >> >> The passwd application needs to access the /etc/shadow object, which is >> labeled with the shadow_t file type: >> >> $ ls -Z /etc/shadow >> -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow >> >> 2. An SELinux policy rule states that subjects running in the passwd_t >> domain type are allowed to read and write to objects that are labeled >> with the shadow_t file type. The /etc/shadow object is the only object >> that is labeled with the shadow_t file type. > > Also /etc/gshadow. And the backup copies of both files created whenever > they are updated (e.g. /etc/shadow-). And any intermediate files > created during the update transaction that contain any shadow password > data - the point is that any file containing such data ought to be > labeled with the shadow_t type so that it can be consistently protected > throughout. An SELinux policy rule states that subjects running in the passwd_t domain type are allowed to read and write to objects that are labeled with the shadow_t file type. Only objects and their back up copies that are required for a password change, such as /etc/gshadow, /etc/gshadow- and /etc/shadow, are labeled with the shadow_t file type. > >> 3. When a user runs the /usr/bin/passwd command, the application >> transitions to a subject (a process), which is running in the passwd_t >> domain type. > > The user shell process transitions to the passwd_t domain upon executing > the /usr/bin/passwd command. When a user runs the /usr/bin/passwd command, the user's shell process transitions to the passwd_t domain type. > >> With SELinux, since the default action is to deny, and a >> rule exists that allows (among other things) applications running in the >> passwd_t domain type to access objects labeled with the shadow_t file >> type, the passwd application is allowed to access /etc/shadow, and >> update the user's password. >> >> This example is not exhaustive, and is used as a basic example to >> explain domain transition. Although there is an actual rule that allows >> subjects running in the passwd_t domain type to access objects labeled >> with the shadow_t file type, other rules must be met before the object >> can successfully transition. > > Not sure what you mean by "the object can successfully transition" - > processes transition from one domain to another upon executing a new > program. ...other SELinux policy rules must be met before the subject can transition to a new domain. > > In the passwd example, the guarantees we are getting from Type > Enforcement are: > - Only authorized domains (e.g. passwd_t) can write to shadow password > data (shadow_t). Other processes, even superuser ones, cannot do so. > - The passwd_t domain can only be entered by executing a program labeled > with passwd_exec_t, can only execute from authorized shared libraries > (e.g. lib_t) and cannot execute any other programs. Thus, we can have > some confidence that only authorized code is ever executed in passwd_t. > - Only authorized domains (e.g. user_t) can transition to passwd_t. > Thus, a daemon like sendmail_t that has no legitimate reason to ever run > passwd cannot ever reach passwd_t. > - passwd_t can only read and write authorized types (e.g. etc_t, > shadow_t). Thus, it cannot be tricked into reading or writing arbitrary > files. In this example, Type Enforcement ensures:
> >> SELinux Contexts for Subjects >> >> On Linux operating systems the run SELinux, when an application is >> executed, that application transitions to a subject and runs in a >> domain. > > Again, not sure you need to keep repeating this, and technically it is > "the process transitions to a new domain upon executing a program with > the entrypoint type for that domain". Removed. > >> The SELinux context for subjects is viewed using the pstree -Z >> command. > > Or just ps -eZ. Changed examples to use ps -eZ. > >> For example: >> >> 1. Open a terminal, such as Applications → System Tools → Terminal. >> >> 2. Run the /usr/bin/passwd command. Do not enter a new password. >> >> 3. Open a new tab, or another terminal, and run the pstree -Z | grep >> passwd command. The output is similar to the following: >> >> | | `-passwd(`unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023') >> >> 4. In the first tab, cancel passwd application. >> >> In this example, when the /usr/bin/passwd object, which is labeled with >> the passwd_exec_t file type, is executed, it transitions to a subject >> that runs in the passwd_t domain type. Remember: the type defines a >> domain type for subjects, and a type for objects. >> >> To view the SELinux contexts for all subjects, run the pstree -Z >> command. The following is an example of the pstree -Z output, and may >> differ on your system: >> >> ├─NetworkManager(`system_u:system_r:NetworkManager_t:s0') >> │ └─{NetworkManager}(`system_u:system_r:NetworkManager_t:s0') >> ├─acpid(`system_u:system_r:apmd_t:s0') >> ├─anacron(`system_u:system_r:system_crond_t:s0') >> ├─atd(`system_u:system_r:crond_t:s0-s0:c0.c1023') >> ├─auditd(`system_u:system_r:auditd_t:s0') >> >> >> By default, the SELinux targeted policy is used. When using targeted >> policy, most subjects (processes) use the system_r role. Type >> enforcement then separates each domain. > > system_r is for system processes like daemons. Targeted policy used to > use system_r for everything and not use any user roles. In F9, it uses > unconfined_r for unconfined users. The system_r role is used for system processes, such as daemons. Type enforcement then separates each domain. I left user roles (unconfined_r, user_r) out, as they explained later. Thanks again :) -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Tue, 02 Sep 2008 13:39:16 +1000
>>> type: The type is an attribute of Type Enforcement. The type defines >>> a domain type for subjects, and a type for objects. SELinux policy >>> rules define how types access each other, whether it be a domain >>> accessing a type, or a domain accessing another domain. Access is >>> only allowed if a specific rule exists that allows it. >>> >>> category: The category is an attribute of Multi-Level Security (MLS) >>> and Multi-Category Security (MCS). Categories are used to categorize >>> data, and identify its sensitivity or security level. Standard >>> SELinux policy supports MCS; however, it is not heavily used. MCS >>> allows users, at their own discretion, to add a category to a piece >>> of data, for example, PatientRecord or CompanyConfidential. There is >>> only a single security level, s0. MLS labels data with both >>> categories (CompanyConfidential) and a sensitivity level. MLS >>> enforces the Bell-LaPadula Mandatory Access Model, and is used in >>> Labeled Security Protection Profile (LSPP) environments. >> >> Again, this should be level or range rather than just category, where a >> level is a sensitivity and an optional list of categories and a range is >> a current/low level and a clearance/high level. You may wish to note >> that people who wish to use the MLS restrictions need to install a >> separate -mls policy package and make it the default. > How about: The security level is an attribute of MLS and Multi-Category Security (MCS). The first part of the security level is the sensitivity, for example, s0 is a sensitivity. The s0 sensitivity is the only sensitivity used when running the SELinux targeted policy. Optionally, the security level can have a list of categories. Categories are used to categorize data and add an extra level of security. If a user does not have access to the same or higher categories than an object, and DAC and SELinux rules allow access, access to that object is denied. For example, if a user only has access to the c0 category, and an object is labeled with the c1 category, access is denied. Security levels can be translated to an easier-to-read form, such as CompanyConfidential. For an example list of security levels and their translations, refer to the /etc/selinux/targeted/setrans.conf file. When running the SELinux MLS policy, a sensitivity and categories are compulsory. MLS allows sensitivities s0 through to s9. MLS enforces the Bell-LaPadula Mandatory Access Model[1], and is used in Labeled Security Protection Profile (LSPP) environments. To use MLS restrictions, install the selinux-policy-mls package, and configure MLS to be the default SELinux policy. from semanage login -l, is the range the "s0-s0" part of the MLS/MCS label? And in MLS, this could be something like "s0-s3"? [1] http://en.wikipedia.org/wiki/Bell-LaPadula_model
> This part is in progress. I do not understand the difference between -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Tue, 02 Sep 2008 14:48:17 +1000
>>>> type: The type is an attribute of Type Enforcement. The type defines >>>> a domain type for subjects, and a type for objects. SELinux policy >>>> rules define how types access each other, whether it be a domain >>>> accessing a type, or a domain accessing another domain. Access is >>>> only allowed if a specific rule exists that allows it. >>>> >>>> category: The category is an attribute of Multi-Level Security (MLS) >>>> and Multi-Category Security (MCS). Categories are used to categorize >>>> data, and identify its sensitivity or security level. Standard >>>> SELinux policy supports MCS; however, it is not heavily used. MCS >>>> allows users, at their own discretion, to add a category to a piece >>>> of data, for example, PatientRecord or CompanyConfidential. There is >>>> only a single security level, s0. MLS labels data with both >>>> categories (CompanyConfidential) and a sensitivity level. MLS >>>> enforces the Bell-LaPadula Mandatory Access Model, and is used in >>>> Labeled Security Protection Profile (LSPP) environments. >>> >>> Again, this should be level or range rather than just category, where a >>> level is a sensitivity and an optional list of categories and a range is >>> a current/low level and a clearance/high level. You may wish to note >>> that people who wish to use the MLS restrictions need to install a >>> separate -mls policy package and make it the default. >> > > How about: > > The security level is an attribute of MLS and Multi-Category Security > (MCS). The first part of the security level is the sensitivity, for > example, s0 is a sensitivity. The s0 sensitivity is the only sensitivity > used when running the SELinux targeted policy. Optionally, the security > level can have a list of categories. Categories are used to categorize > data and add an extra level of security. If a user does not have access > to the same or higher categories than an object, and DAC and SELinux > rules allow access, access to that object is denied. I keep getting MLS and MCS mixed up. Should this be "If a user does not have access to same categories as the object is labeled with"? Apologies for all the spam.
For example, if a
>> This part is in progress. I do not understand the difference between >> levels/categories and ranges. Can you recommend any papers or books on >> this? This is what is there now, keeping in mind I don't understand: >> >> The level is an attribute of MLS and Multi-Category Security (MCS). >> There is a single sensitivity level, s0, which is the only sensitivity >> level used. This level is used when running the SELinux MLS policy, >> but not when running the SELinux targeted policy. An optional list of >> categories can be used to categorize data. Standard SELinux policy >> supports MCS; however, it is not heavily used. MCS allows users, at >> their own discretion, to add a category to a piece of data, for >> example, CompanyConfidential or PatientRecord. MLS labels data with >> both a sensitivity level and categories (such as CompanyConfidential). >> MLS enforces the Bell-LaPadula Mandatory Access Model, and is used in >> Labeled Security Protection Profile (LSPP) environments. To use MLS >> restrictions, install the selinux-policy-mls package, and configure >> MLS to be the default SELinux policy. > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov > with > the words "unsubscribe selinux" without quotes as the message. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Tue, 02 Sep 2008 09:19:19 -0400
On Tue, 2008-09-02 at 14:48 +1000, Murray McAllister wrote:
For MCS, as I recall, the subject's high level/clearance must dominate the object's level in order to read or write to it. Thus, it must be authorized for all categories in the object's level. For MLS, the subject's low level must dominate the object's level in order to read from it (read down), and the subject's low level must equal the object's level in order to write to it (write equal). Technically, the latter restriction can be relaxed to allow a subject to write up, but in the current mls policy this requires a particular type attribute. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Tue, 02 Sep 2008 09:09:45 -0400
On Tue, 2008-09-02 at 13:39 +1000, Murray McAllister wrote:
I think they go up to s15 in the -mls policy configuration, although it is all defined as part of the policy configuration and there is no implementation-defined hard limit.
> MLS enforces the Caveat: the -mls policy as shipped by Fedora/RH intentionally omits many program domains that were not part of the evaluated configuration, and thus is not usable on a desktop workstation (no X support). However you can build a mls policy from the upstream refpolicy that includes all program domains.
> from semanage login -l, is the range the "s0-s0" part of the MLS/MCS Yes, s0-s0 is a MLS/MCS range where the low level and the high level are identical. It could just as easily be written as just "s0" since that implies s0-s0. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Wed, 03 Sep 2008 16:04:05 +1000
> On Tue, 2008-09-02 at 13:39 +1000, Murray McAllister wrote: >> How about: >> >> The security level is an attribute of MLS and Multi-Category Security >> (MCS). The first part of the security level is the sensitivity, for >> example, s0 is a sensitivity. The s0 sensitivity is the only sensitivity >> used when running the SELinux targeted policy. Optionally, the security >> level can have a list of categories. Categories are used to categorize >> data and add an extra level of security. If a user does not have access >> to the same or higher categories than an object, and DAC and SELinux >> rules allow access, access to that object is denied. For example, if a >> user only has access to the c0 category, and an object is labeled with >> the c1 category, access is denied. Security levels can be translated to >> an easier-to-read form, such as CompanyConfidential. For an example list >> of security levels and their translations, refer to the >> /etc/selinux/targeted/setrans.conf file. >> >> When running the SELinux MLS policy, a sensitivity and categories are >> compulsory. MLS allows sensitivities s0 through to s9. > > I think they go up to s15 in the -mls policy configuration, although it > is all defined as part of the policy configuration and there is no > implementation-defined hard limit. > >> MLS enforces the >> Bell-LaPadula Mandatory Access Model[1], and is used in Labeled Security >> Protection Profile (LSPP) environments. To use MLS restrictions, install >> the selinux-policy-mls package, and configure MLS to be the default >> SELinux policy. > > Caveat: the -mls policy as shipped by Fedora/RH intentionally omits > many program domains that were not part of the evaluated configuration, > and thus is not usable on a desktop workstation (no X support). However > you can build a mls policy from the upstream refpolicy that includes all > program domains. > >> from semanage login -l, is the range the "s0-s0" part of the MLS/MCS >> label? And in MLS, this could be something like "s0-s3"? > > Yes, s0-s0 is a MLS/MCS range where the low level and the high level are > identical. It could just as easily be written as just "s0" since that > implies s0-s0. > How about: The level is an attribute of MLS and Multi-Category Security (MCS). The first part of the level, s0-s0, is the sensitivity. The s0 sensitivity is the only sensitivity used for MCS. Since the format of the level is the same for MLS and MCS, and MLS supports ranges of sensitivities, a sensitivity such as s0-s0 is the same as s0 when using MCS. Optionally, the level can have a list of categories. Categories are used to categorize data and add an extra level of security. Fedora 10 supports 1024 different categories: c0 through to c1023. If a user is not authorized for all of the categories of an object, and DAC and SELinux rules allow access, access is denied. For example, if a user is only authorized for the c0 category, and an object is labeled with the c0 and c1 categories, access is denied. If a user is authorized for the c0 and c1 categories, and an object is only labeled with the c0 category, access is allowed. Levels can be translated to an easier-to-read form, such as CompanyConfidential. For an example list of levels and their translations, refer to the /etc/selinux/targeted/setrans.conf file. MLS allows ranges of sensitivities, not just s0. MLS enforces the Bell-LaPadula Mandatory Access Model, and is used in Labeled Security Protection Profile (LSPP) environments. To use MLS restrictions, install the selinux-policy-mls package, and configure MLS to be the default SELinux policy. The MLS policy shipped with Fedora omits many program domains that were not part of the evaluated configuration, and therefore, MLS on a desktop workstation is unusable (no support for the X Window System); however, an MLS policy from the upstream SELinux reference policy[1] can be built that includes all program domains. I left out details to try to limit mistakes... [1] http://oss.tresys.com/projects/refpolicy -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Wed, 03 Sep 2008 09:01:26 -0400
On Wed, 2008-09-03 at 16:04 +1000, Murray McAllister wrote:
Actually, s0-s0 is a MLS range where the low level has sensitivity s0 and no categories and the high level has sensitivity s0 and no categories.
> The s0 sensitivity No, s0-s0 is always the same as just s0, regardless of MCS or MLS. Just like s1-s1 is the same as just s1. Versus a non-trivial range like s0-s1 or s0-s3.
> Optionally, Each level in the range can have a list of categories, so you can have:
s0:c0,c2-s3:c0,c1,c2
Somewhere you should likely explain the notation:
sN represents a sensitivity with value N, where sN dominates sM if N >=
M.
> Categories are used to That would be DAC and type enforcement rules. SELinux rules include TE rules, RBAC rules, and constraints (including MLS/MCS).
> For example, if a user is only -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Fri, 05 Sep 2008 15:46:43 +1000
>> How about: >> >> The level is an attribute of MLS and Multi-Category Security (MCS). The >> first part of the level, s0-s0, is the sensitivity. > > Actually, s0-s0 is a MLS range where the low level has sensitivity s0 > and no categories and the high level has sensitivity s0 and no > categories. > >> The s0 sensitivity >> is the only sensitivity used for MCS. Since the format of the level is >> the same for MLS and MCS, and MLS supports ranges of sensitivities, a >> sensitivity such as s0-s0 is the same as s0 when using MCS. > > No, s0-s0 is always the same as just s0, regardless of MCS or MLS. Just > like s1-s1 is the same as just s1. Versus a non-trivial range like > s0-s1 or s0-s3. > >> Optionally, >> the level can have a list of categories. I hope this is correct soon ;) The level is an attribute of MLS and Multi-Category Security (MCS). The first part of the level, s0-s0, is an MLS range. This range has an identical low-level and high-level sensitivity, s0, and no categories. A range of s0-s0 is the same as s0. The s0 sensitivity is the only sensitivity used by MCS, as MCS only enforces categories. Optionally, each level in a range can have a list of categories. MCS in Fedora 10 supports 1024 different categories: c0 through to c1023. If a user is not authorized for all of the categories of an object, and DAC and Type Enforcement rules allow access, access is denied. For example, if a user is only authorized for the c0 category, and an object is labeled with the c0 and c1 categories, access is denied. If a user is authorized for the c0 and c1 categories, and an object is only labeled with the c0 category, access is allowed. The /etc/selinux/targeted/setrans.conf file is used to map levels (s0:c0) to human-readable form (CompanyConfidential). MLS allows ranges of sensitivities, not just s0. Both sensitivities and categories are required when using MLS. MLS enforces the Bell-LaPadula Mandatory Access Model, and is used in Labeled Security Protection Profile (LSPP) environments. To use MLS restrictions, install the selinux-policy-mls package, and configure MLS to be the default SELinux policy. The MLS policy shipped with Fedora omits many program domains that were not part of the evaluated configuration, and therefore, MLS on a desktop workstation is unusable (no support for the X Window System); however, an MLS policy from the upstream SELinux reference policy can be built that includes all program domains.
> >> Categories are used to >> categorize data and add an extra level of security. Fedora 10 supports >> 1024 different categories: c0 through to c1023. If a user is not >> authorized for all of the categories of an object, and DAC and SELinux >> rules allow access, access is denied. > > That would be DAC and type enforcement rules. SELinux rules include TE > rules, RBAC rules, and constraints (including MLS/MCS). changed.
> >> For example, if a user is only >> authorized for the c0 category, and an object is labeled with the c0 and >> c1 categories, access is denied. If a user is authorized for the c0 and >> c1 categories, and an object is only labeled with the c0 category, >> access is allowed. Levels can be translated to an easier-to-read form, >> such as CompanyConfidential. For an example list of levels and their >> translations, refer to the /etc/selinux/targeted/setrans.conf file. >> >> MLS allows ranges of sensitivities, not just s0. MLS enforces the >> Bell-LaPadula Mandatory Access Model, and is used in Labeled Security >> Protection Profile (LSPP) environments. To use MLS restrictions, install >> the selinux-policy-mls package, and configure MLS to be the default >> SELinux policy. The MLS policy shipped with Fedora omits many program >> domains that were not part of the evaluated configuration, and >> therefore, MLS on a desktop workstation is unusable (no support for the >> X Window System); however, an MLS policy from the upstream SELinux >> reference policy[1] can be built that includes all program domains. >> >> I left out details to try to limit mistakes... >> >> [1] http://oss.tresys.com/projects/refpolicy -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Fri, 05 Sep 2008 07:27:27 -0400
On Fri, 2008-09-05 at 15:46 +1000, Murray McAllister wrote:
s0-s0 is a range. It is not a level. A MLS range is a pair of levels (lowlevel, highlevel) written as "lowlevel-highlevel" if they differ or as just "lowlevel" if they are the identical. Each level is a (sensitivity, categoryset) pair written as "sensitivity:categoryset" or just "sensitivity" if the category set is empty. A categoryset is a list of categories written as "category1,category2,...". If a category set contains a contiguous series of categories (e.g. "c1,c2,c3,c4,c5,c6,c7,c8,c9,c10") this can be abbreviated as the first category in the series followed by a dot (".") followed by the last category in the series, e.g. "c1.c10". s0-s0 is a range where the lowlevel == highlevel == (sensitivity s0, emptycategoryset). -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Sat, 06 Sep 2008 14:24:17 +1000
>> Stephen Smalley wrote: >>> On Wed, 2008-09-03 at 16:04 +1000, Murray McAllister wrote: >>>> How about: >>>> >>>> The level is an attribute of MLS and Multi-Category Security (MCS). The >>>> first part of the level, s0-s0, is the sensitivity. >>> Actually, s0-s0 is a MLS range where the low level has sensitivity s0 >>> and no categories and the high level has sensitivity s0 and no >>> categories. >>> >>>> The s0 sensitivity >>>> is the only sensitivity used for MCS. Since the format of the level is >>>> the same for MLS and MCS, and MLS supports ranges of sensitivities, a >>>> sensitivity such as s0-s0 is the same as s0 when using MCS. >>> No, s0-s0 is always the same as just s0, regardless of MCS or MLS. Just >>> like s1-s1 is the same as just s1. Versus a non-trivial range like >>> s0-s1 or s0-s3. >>> >>>> Optionally, >>>> the level can have a list of categories. >> I hope this is correct soon ;) >> >> The level is an attribute of MLS and Multi-Category Security (MCS). The >> first part of the level, s0-s0, is an MLS range. > > s0-s0 is a range. It is not a level. A MLS range is a pair of levels > (lowlevel, highlevel) written as "lowlevel-highlevel" if they differ or > as just "lowlevel" if they are the identical. Each level is a > (sensitivity, categoryset) pair written as "sensitivity:categoryset" or > just "sensitivity" if the category set is empty. A categoryset is a > list of categories written as "category1,category2,...". If a category > set contains a contiguous series of categories (e.g. > "c1,c2,c3,c4,c5,c6,c7,c8,c9,c10") this can be abbreviated as the first > category in the series followed by a dot (".") followed by the last > category in the series, e.g. "c1.c10". > > s0-s0 is a range where the lowlevel == highlevel == (sensitivity s0, > emptycategoryset). > If it is not right this time, it's being deleted ;) level: The level[1] is an attribute of MLS and Multi-Category Security (MCS). An MLS range is a pair of levels, written as lowlevel-highlevel if the levels differ, or lowlevel if the levels are identical (s0-s0 is the same as s0). Each level is a sensitivity-category pair, with categories being optional. If there are categories, the level is written as sensitivity:category-set. If there are no categories, it is written as sensitivity. If the category set is a contiguous series, it can be abbreviated. For example, c0.c3 is the same as c0,c1,c2,c3. The /etc/selinux/targeted/setrans.conf file is used to map levels (s0:c0) to human-readable form (CompanyConfidential). [1] talking about all of the output (s0-s0:c0.c1023 ) from semanage login -l -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Mon, 08 Sep 2008 10:44:41 +1000
>> On Fri, 2008-09-05 at 15:46 +1000, Murray McAllister wrote: >>> Stephen Smalley wrote: >>>> On Wed, 2008-09-03 at 16:04 +1000, Murray McAllister wrote: >>>>> How about: >>>>> >>>>> The level is an attribute of MLS and Multi-Category Security (MCS). >>>>> The first part of the level, s0-s0, is the sensitivity. >>>> Actually, s0-s0 is a MLS range where the low level has sensitivity s0 >>>> and no categories and the high level has sensitivity s0 and no >>>> categories. >>>> >>>>> The s0 sensitivity is the only sensitivity used for MCS. Since the >>>>> format of the level is the same for MLS and MCS, and MLS supports >>>>> ranges of sensitivities, a sensitivity such as s0-s0 is the same as >>>>> s0 when using MCS. >>>> No, s0-s0 is always the same as just s0, regardless of MCS or MLS. >>>> Just >>>> like s1-s1 is the same as just s1. Versus a non-trivial range like >>>> s0-s1 or s0-s3. >>>> >>>>> Optionally, the level can have a list of categories. >>> I hope this is correct soon ;) >>> >>> The level is an attribute of MLS and Multi-Category Security (MCS). >>> The first part of the level, s0-s0, is an MLS range. >> >> s0-s0 is a range. It is not a level. A MLS range is a pair of levels >> (lowlevel, highlevel) written as "lowlevel-highlevel" if they differ or >> as just "lowlevel" if they are the identical. Each level is a >> (sensitivity, categoryset) pair written as "sensitivity:categoryset" or >> just "sensitivity" if the category set is empty. A categoryset is a >> list of categories written as "category1,category2,...". If a category >> set contains a contiguous series of categories (e.g. >> "c1,c2,c3,c4,c5,c6,c7,c8,c9,c10") this can be abbreviated as the first >> category in the series followed by a dot (".") followed by the last >> category in the series, e.g. "c1.c10". >> >> s0-s0 is a range where the lowlevel == highlevel == (sensitivity s0, >> emptycategoryset). >> > > If it is not right this time, it's being deleted ;) > > level: The level[1] is an attribute of MLS and Multi-Category Security > (MCS). An MLS range is a pair of levels, written as lowlevel-highlevel > if the levels differ, or lowlevel if the levels are identical (s0-s0 is > the same as s0). Each level is a sensitivity-category pair, with > categories being optional. If there are categories, the level is written > as sensitivity:category-set. If there are no categories, it is written > as sensitivity. If the category set is a contiguous series, it can be > abbreviated. For example, c0.c3 is the same as c0,c1,c2,c3. The > /etc/selinux/targeted/setrans.conf file is used to map levels (s0:c0) to > human-readable form (CompanyConfidential). In Fedora 10, targeted policy enforces MCS, and in MCS, there is only one sensitivity, s0. MCS in Fedora 10 supports 1024 different categories: c0 through to c1023. s0-s0:c0.c1023 is sensitivity s0, and authorized for all categories.
> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Tue, 02 Sep 2008 08:58:44 -0400
On Mon, 2008-09-01 at 17:03 +1000, Murray McAllister wrote:
user, role, type, and optionally a level/range.
> How about "...role:type:sensitivity"? :level or :range is more accurate than :sensitivity, as the sensitivity is merely one component of the level/range.
> Output may differ from system to system. The Login Name column lists No, the user<->role and user<->level restriction is only applied to subjects.
> role: privilege escalation, not privileged escalation.
> This part is in progress. I do not understand the difference between MLS is a hierarchical model where you have a set of security levels that are partially ordered, and those levels form a lattice. There are numerous descriptions of it, see for example: http://www.cs.stthomas.edu/faculty/resmith/r/mls/index.html In SELinux, the last component of the security context is a MLS range. A MLS range takes the form of lowlevel-highlevel. The degenerate case is where the lowlevel equals the highlevel; in this case, we simply write the level once. Each level takes the form of sensitivity:category-set. If the category set is empty, then we simply write the sensitivity. The category-set takes the form of category-1,category-2,.... If there are a set of contiguous categories like c0,c1,c2,...,c1024 then this is written as c0.c1024 for compactness.
The MLS range has two user-visible representations:
1) A human-readable string label, like "SystemLow-SystemHigh" or
"unclassified-top_secret:nato". This is the form of the label produced
by mcstransd and displayed to the user.
> The level is an attribute of MLS and Multi-Category Security (MCS). The one-sensitivity limitation is only true of MCS, not MLS, and only because MCS only uses the categories, not the sensitivity. And while MCS is limited to one sensitivity, it supports a large number of categories (1024 in Fedora), and thus a large number of levels (where level == combination of the one sensitivity s0 with a category set).
> This level is used when running the SELinux MLS policy, but The level is used whenever MCS or MLS is enabled, as the targeted policy in Fedora does enable MCS.
> > A process in one domain transitions to another domain by executing a new
Not exactly:
-- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Murray McAllister <mmcallis_at_redhat.com> subject: Re: user guide draft: "SELinux Contexts and Attributes" review Date: Wed, 03 Sep 2008 15:56:51 +1000
>>> A process in one domain transitions to another domain by executing a new >>> program with the entrypoint type for the new domain. >> How about: >> >> A subject in one domain transitions to another domain by executing an >> object that is labeled with a file type that has entrypoint permission >> for the new domain. The entrypoint permission is used in SELinux policy, >> and controls which domains an object can enter. The following example... > > Not exactly: > 1) A new domain has entrypoint permission to the file type, not the > other way around. > 2) The entrypoint permission controls which programs can be used to > enter a domain, not the other way around. How about (from your original suggestion): A subject in one domain transitions to another domain by executing an object that has the entrypoint file type for the new domain. The entrypoint permission is used in SELinux policy, and controls which objects can be used to enter a domain. I added the following to the list of steps: An SELinux policy rule states that the passwd_t domain type has entrypoint permission to the passwd_exec_t file type. Thanks. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |