user guide draft: "SELinux Contexts and Attributes" review

user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

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. 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:

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.

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:

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.

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.

--
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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Stephen Smalley]

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).

>  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.

> 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.

>  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.

> 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.

> 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.

> 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.

>  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.

> 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.

>  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.

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.

> 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".

>  The SELinux context for subjects is viewed using the pstree -Z 
> command.

Or just 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.

> 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.
> 
> --
> 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.
-- 
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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

Cheers. Comments inline:

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:
Part of SELinux is the Role Based Access Control (RBAC) security model. 
The role is an attribute of RBAC. SELinux users are authorized for 
roles, and roles are authorized for domain types. The role serves as an 
intermediary between domains types and SELinux users. The roles that can 
be entered determine which domain types can be entered - ultimately, 
this controls which object types can be accessed. This helps reduce 
vulnerability to privileged escalation attacks.

> 
>> 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:

* The passwd_t domain can only be entered by executing an object labeled 
with the passwd_exec_t file type; can only execute from authorized 
shared libraries, such as the lib_t file type; and can not execute any 
other objects.

* Only authorized domains, such as passwd_t, can write to objects 
labeled with the shadow_t file type. Even if other subjects are running 
with superuser privileges, those subject can not write to objects 
labeled with the shadow_t file type, as they are not running in the 
passwd_t domain.

* Only authorized domains can transition to the passwd_t domain. For 
example, the sendmail subject running in the sendmail_t domain does not 
have a legitimate reason to run /usr/bin/passwd; therefore, it can never 
transition to the passwd_t domain.

* Subjects running in the passwd_t domain type can only read and write 
authorized types, such as objects labeled with the etc_t or shadow_t 
file types. This prevents the passwd application from being tricked into 
reading or writing arbitrary files.

> 
>> 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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

Murray McAllister wrote:

>>> 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 
> 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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

Murray McAllister wrote:
> Murray McAllister wrote:
> 
>>>> 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
> 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 
>> 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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Stephen Smalley]

On Mon, 2008-09-01 at 17:03 +1000, Murray McAllister wrote:
> 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.

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 
> 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?

No, the user<->role and user<->level restriction is only applied to
subjects.

> role:
> Part of SELinux is the Role Based Access Control (RBAC) security model. 
> The role is an attribute of RBAC. SELinux users are authorized for 
> roles, and roles are authorized for domain types. The role serves as an 
> intermediary between domains types and SELinux users. The roles that can 
> be entered determine which domain types can be entered - ultimately, 
> this controls which object types can be accessed. This helps reduce 
> vulnerability to privileged escalation attacks.

privilege escalation, not privileged escalation.

> 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:

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.
2) The raw kernel security context format, like "s0-s15:c0.c1024".  The
user may also see this format if not using mcstransd or if mcstransd
lacks a translation for a given range.  The user can also provide a
label in this format directly if desired.

> 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.

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 
> not when running the SELinux targeted policy.

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
> > 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.

-- 
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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Stephen Smalley]

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.

-- 
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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Stephen Smalley]

On Tue, 2008-09-02 at 14:48 +1000, Murray McAllister wrote:
> Murray McAllister wrote:
> > Murray McAllister wrote:
> > 
> >>>> 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"?

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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

Stephen Smalley wrote:
> On Mon, 2008-09-01 at 17:03 +1000, Murray McAllister wrote:
>>> 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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

Stephen Smalley wrote:
> 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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Stephen Smalley]

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.

Each level in the range can have a list of categories, so you can have:
	s0:c0,c2-s3:c0,c1,c2
The only requirement is that the high level (s3:c0,c1,c2) must dominate
the low level (s0:c0,c2), i.e. s3 >= s0 and {c0, c1, c2} is a superset
of {c0, c2}.

Somewhere you should likely explain the notation:
sN represents a sensitivity with value N, where sN dominates sM if N >=
M.
cN represents category N, where a category set dominates another if it
is a superset of it.
The sN and cN values can then be mapped to human-readable labels using
setrans.conf.

>  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).

>  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
-- 
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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

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. 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.

> 
> Each level in the range can have a list of categories, so you can have:
> 	s0:c0,c2-s3:c0,c1,c2
> The only requirement is that the high level (s3:c0,c1,c2) must dominate
> the low level (s0:c0,c2), i.e. s3 >= s0 and {c0, c1, c2} is a superset
> of {c0, c2}.
> 
> Somewhere you should likely explain the notation:
> sN represents a sensitivity with value N, where sN dominates sM if N >=
> M.
> cN represents category N, where a category set dominates another if it
> is a superset of it.
> The sN and cN values can then be mapped to human-readable labels using
> setrans.conf.
> 
>>  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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Stephen Smalley]

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).

-- 
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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

Stephen Smalley wrote:
> 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).


[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.

Re: user guide draft: "SELinux Contexts and Attributes" review

[Murray McAllister]

Murray McAllister wrote:
> Stephen Smalley wrote:
>> 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.

> 
> 
> [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.


--
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.