user guide draft: "Targeted Policy" review

user guide draft: "Targeted Policy" review

[Murray McAllister]

Hi,

The following is a draft of the "Targeted Policy" sections for the 
SELinux User Guide. Any comments and corrections are appreciated.

Thanks.

Targeted Policy

Targeted policy is the default SELinux policy used in Fedora 10. When 
using targeted policy, subjects that are targeted run in their own 
domain type, and subjects that are not targeted run in the unconfined_t 
domain type. When a subject runs in the unconfined_t domain type, 
SELinux rules do not apply, and only DAC rules are used.

Confined Subjects

A large number of subjects are protected, and are therefore confined by 
the SELinux targeted policy, including the Apache HTTP Server (httpd), 
Samba (samba), FTP (vsftpd), Kerberos (krb5-server), ISC BIND (bind and 
bind-chroot), NFS (nfs-utils), and NIS (ypserv). When a subject is 
confined, it runs in its own domain type, such as the httpd subject 
running in the httpd_t domain type. When a confined subject is 
compromised by an attacker, the damage an attacker can do and the data 
they can access is greatly limited.

The following example demonstrates how SELinux prevents the Apache HTTP 
Server (httpd) from reading files that are not correctly labeled, such 
as files intended for use by another subject. This is an example, and 
should not be used in production. It assumes that the httpd and wget 
packages are installed, that the SELinux targeted policy is used, and 
that SELinux is running in enforcing mode:

1. As the Linux root user, run the touch /var/www/html/testfile command.

2. Run the ls -Z /var/www/html/testfile command to view the SELinux 
context:

-rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 
/var/www/html/testfile

By default, Linux users run unconfined on Fedora 10, which is why the 
testfile file object is labeled with the SELinux unconfined_u user. The 
object_r role is a standard role, and does not affect access control. 
The httpd_sys_content_t file type allows the httpd subject to access 
this object.

[ What is object_r really for? ]

3. As the Linux root user, start the Apache HTTP Server: /sbin/service 
httpd start. When the server has started, change into a directory where 
your Linux user has write access to, and run the wget 
http://localhost/testfile command. Unless there are any changes to the 
default configuration, this command succeeds.

4. The /usr/bin/chcon command relabels files; however, such label 
changes do not survive when the file system is relabeled. For permanent 
changes that survive a file system relabel, use the /usr/sbin/semanage 
command, which is discussed later. As the Linux root user, run the 
/usr/bin/chcon -t samba_share_t /var/www/html/testfile command to change 
the file type, to a file type that is used by Samba. Run the ls -Z 
/var/www/html/testfile command to verify the changes:

[ If a file has an entry in file_contexts, and is relabeled with 
semanage fcontext, does that update 
/etc/selinux/targeted/contexts/files/file_contexts with the change? I 
was going to try, but forgot how to change the file type with semanage]

-rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0 
/var/www/html/testfile

5. Note: the current DAC permissions allow the httpd subject access to 
this file. Change into a directory where your Linux user has write 
access to, and run the wget http://localhost/testfile command. Unless 
there are any changes to the default configuration, this command fails:

HTTP request sent, awaiting response... 403 Forbidden
2008-08-22 03:48:40 ERROR 403: Forbidden.

This example demonstrates the additional security added by SELinux. 
Although the httpd subject had access to the object in step 5, because 
the object was labeled with a file type that httpd subject does not have 
access to, SELinux denied access. After step 5, an error such as the 
following is logged to /var/log/messages:

Aug 22 03:48:40 localhost setroubleshoot: SELinux is preventing httpd 
(httpd_t) "getattr"
to /var/www/html/testfile (samba_share_t). For complete SELinux messages.
run sealert -l c05911d3-e680-4e42-8e36-fe2ab9f8e654

Also, if the audit package is installed and the auditd subject is 
running, a more detailed denial is logged to /var/log/audit/audit.log. 
These denials are discussed later.

Unconfined Subjects

Unconfined subjects run in the unconfined_t domain type. This means that 
SELinux policy rules do not apply, and only DAC permissions are used. 
When an unconfined subject is comprised, an attacker may gain access to 
a large number of system resources and data.

The following example demonstrates how the Apache HTTP Server (httpd) 
can access data intended for use by another subject, when running 
unconfined. Note: on Fedora 10, the httpd subject runs in the confined 
httpd_t domain type by default. This is an example, and should not be 
used in production. It assumes that the httpd and wget packages are 
installed, that the SELinux targeted policy is used, and that SELinux is 
running in enforcing mode:

1. As the Linux root user, run the touch /var/www/html/test2file command.

2. Run the ls -Z /var/www/html/test2file command to view the SELinux 
context:

-rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 
/var/www/html/test2file

By default, Linux users run unconfined on Fedora 10, which is why the 
test2file file object is labeled with the SELinux unconfined_u user. The 
object_r role is a standard role, and does not affect access control. 
The httpd_sys_content_t file type allows the httpd subject to access 
this object.

3. The /usr/bin/chcon command relabels files; however, such label 
changes do not survive when the file system is relabeled. For permanent 
changes that survive a file system relabel, use the /usr/sbin/semanage 
command, which is discussed later. As the Linux root user, run the 
/usr/bin/chcon -t samba_share_t /var/www/html/test2file command to 
change the file type, to a file type that is used by Samba. Run the ls 
-Z /var/www/html/test2file command to verify the changes:

-rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0 
/var/www/html/test2file

4. To simulate the httpd subject running unconfined, run the 
/usr/sbin/setenforce 0 command as the Linux root user to temporarily 
disable SELinux. Confirm SELinux is disabled by running the 
/usr/sbin/getenforce command. When SELinux is disabled, 
/usr/sbin/getenforce returns Permissive:

$ getenforce
Permissive

5. As the Linux root user, start the Apache HTTP Server: /sbin/service 
httpd start. Change into a directory where your Linux user has write 
access to, and run the wget http://localhost/test2file command. Unless 
there are any changes to the default configuration, this command succeeds.

6. Enable SELinux by running /usr/sbin/setenforce 1 command. When 
SELinux is enabled, /usr/sbin/getenforce returns Enforcing:

$ getenforce
Enforcing

The examples in these sections demonstrate how data can be protected 
from a compromised confined-subject (protected by SELinux), as well as 
how data is more accessible to an attacker from a compromised 
unconfined-subject (not protected by SELinux).

Confined and Unconfined User Domains

In progress. Introduction to restrictions on certain domains (user_t, 
guest_t etc).

Are there any SELinux restrictions on what users can do when they run 
unconfined?

--
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: "Targeted Policy" review

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Wed, 2008-09-03 at 17:41 +1000, Murray McAllister wrote:
> Hi,

> Are there any SELinux restrictions on what users can do when they run 
> unconfined?

Yes i think unconfined users cannot do execmem, execstack, execheap by
default.
Otherwise they're exempted from policy enforcement i think.

-- 
Dominick Grift <domg472@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: user guide draft: "Targeted Policy" review

[James Morris]

On Wed, 3 Sep 2008, Murray McAllister wrote:

> subjects that are not targeted run in the unconfined_t domain type. When a
> subject runs in the unconfined_t domain type, SELinux rules do not apply, and
> only DAC rules are used.

I think we should keep trying to reduce the amount of jargon for users.  
e.g. can "domain type" be reduced to "domain" or even "label" ?

> A large number of subjects are protected, and are therefore confined by the
> SELinux targeted policy, including the Apache HTTP Server (httpd), Samba
> (samba), FTP (vsftpd), Kerberos (krb5-server), ISC BIND (bind and
> bind-chroot), NFS (nfs-utils), and NIS (ypserv). When a subject is confined,
> it runs in its own domain type, such as the httpd subject running in the
> httpd_t domain type. When a confined subject is compromised by an attacker,
> the damage an attacker can do and the data they can access is greatly limited.

I think the above could be clarified more in terms of cause and effect, 
e.g. the extent of damage is limited because the attacker's access to 
resources is limited.

> 
> The following example demonstrates how SELinux prevents the Apache HTTP Server
> (httpd) from reading files that are not correctly labeled, such as files
> intended for use by another subject. This is an example, and should not be
> used in production. It assumes that the httpd and wget packages are installed,
> that the SELinux targeted policy is used, and that SELinux is running in
> enforcing mode:
> 
> 1. As the Linux root user, run the touch /var/www/html/testfile command.
> 
> 2. Run the ls -Z /var/www/html/testfile command to view the SELinux context:
> 
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
> /var/www/html/testfile
> 
> By default, Linux users run unconfined on Fedora 10, which is why the testfile
> file object is labeled with the SELinux unconfined_u user. The object_r role
> is a standard role, and does not affect access control. The
> httpd_sys_content_t file type allows the httpd subject to access this object.
> 
> [ What is object_r really for? ]

Roles don't have any meaning for objects (at least, in this 
implementation), so object_r is just a default value for objects.


> 3. As the Linux root user, start the Apache HTTP Server: /sbin/service httpd
> start. When the server has started, change into a directory where your Linux
> user has write access to, and run the wget http://localhost/testfile command.
> Unless there are any changes to the default configuration, this command
> succeeds.

I think it would be useful to show the sequence of commands and the 
output, e.g. what the user would see.

> file. Change into a directory where your Linux user has write access to, and
> run the wget http://localhost/testfile command. Unless there are any changes
> to the default configuration, this command fails:
> 
> HTTP request sent, awaiting response... 403 Forbidden
> 2008-08-22 03:48:40 ERROR 403: Forbidden.

Perhaps also show the httpd error log entry.

-- 
James Morris
<jmorris@namei.org>

--
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: "Targeted Policy" review

[Murray McAllister]

James Morris wrote:
> On Wed, 3 Sep 2008, Murray McAllister wrote:
> 
>> subjects that are not targeted run in the unconfined_t domain type. When a
>> subject runs in the unconfined_t domain type, SELinux rules do not apply, and
>> only DAC rules are used.
> 
> I think we should keep trying to reduce the amount of jargon for users.  
> e.g. can "domain type" be reduced to "domain" or even "label" ?

I changed almost all instances of "domain type" to "domain".


>> 3. As the Linux root user, start the Apache HTTP Server: /sbin/service httpd
>> start. When the server has started, change into a directory where your Linux
>> user has write access to, and run the wget http://localhost/testfile command.
>> Unless there are any changes to the default configuration, this command
>> succeeds.
> 
> I think it would be useful to show the sequence of commands and the 
> output, e.g. what the user would see.

I am adding output for each step.

> 
>> file. Change into a directory where your Linux user has write access to, and
>> run the wget http://localhost/testfile command. Unless there are any changes
>> to the default configuration, this command fails:
>>
>> HTTP request sent, awaiting response... 403 Forbidden
>> 2008-08-22 03:48:40 ERROR 403: Forbidden.
> 
> Perhaps also show the httpd error log entry.
> 

Thanks for the suggestions :)

--
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: "Targeted Policy" review

[Stephen Smalley]

On Wed, 2008-09-03 at 17:41 +1000, Murray McAllister wrote:
> Hi,
> 
> The following is a draft of the "Targeted Policy" sections for the 
> SELinux User Guide. Any comments and corrections are appreciated.
> 
> Thanks.
> 
> Targeted Policy
> 
> Targeted policy is the default SELinux policy used in Fedora 10. When 
> using targeted policy, subjects that are targeted run in their own 
> domain type, and subjects that are not targeted run in the unconfined_t 
> domain type. When a subject runs in the unconfined_t domain type, 
> SELinux rules do not apply, and only DAC rules are used.

Not exactly true.  SELinux rules are always applied, but the
unconfined_t domain is allowed (almost) all permissions in the SELinux
policy/rules.

> Confined Subjects
> 
> A large number of subjects are protected, and are therefore confined by 
> the SELinux targeted policy, including the Apache HTTP Server (httpd), 
> Samba (samba), FTP (vsftpd), Kerberos (krb5-server), ISC BIND (bind and 
> bind-chroot), NFS (nfs-utils), and NIS (ypserv). When a subject is 
> confined, it runs in its own domain type, such as the httpd subject 
> running in the httpd_t domain type. When a confined subject is 
> compromised by an attacker, the damage an attacker can do and the data 
> they can access is greatly limited.

Greatly limited might be too strong as a general statement - it is
limited in accordance with the policy, and thus depends on how the
policy is configured.

> The following example demonstrates how SELinux prevents the Apache HTTP 
> Server (httpd) from reading files that are not correctly labeled, such 
> as files intended for use by another subject. This is an example, and 
> should not be used in production. It assumes that the httpd and wget 
> packages are installed, that the SELinux targeted policy is used, and 
> that SELinux is running in enforcing mode:
> 
> 1. As the Linux root user, run the touch /var/www/html/testfile command.
> 
> 2. Run the ls -Z /var/www/html/testfile command to view the SELinux 
> context:
> 
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 
> /var/www/html/testfile
> 
> By default, Linux users run unconfined on Fedora 10, which is why the 
> testfile file object is labeled with the SELinux unconfined_u user. The 
> object_r role is a standard role, and does not affect access control. 
> The httpd_sys_content_t file type allows the httpd subject to access 
> this object.
> 
> [ What is object_r really for? ]

The default role value for objects, and one that avoids any restrictions
on the user, type, and level combination in the object context.

> 3. As the Linux root user, start the Apache HTTP Server: /sbin/service 
> httpd start. When the server has started, change into a directory where 
> your Linux user has write access to, and run the wget 
> http://localhost/testfile command. Unless there are any changes to the 
> default configuration, this command succeeds.
> 
> 4. The /usr/bin/chcon command relabels files; however, such label 
> changes do not survive when the file system is relabeled. For permanent 
> changes that survive a file system relabel, use the /usr/sbin/semanage 
> command, which is discussed later. As the Linux root user, run the 
> /usr/bin/chcon -t samba_share_t /var/www/html/testfile command to change 
> the file type, to a file type that is used by Samba. Run the ls -Z 
> /var/www/html/testfile command to verify the changes:
> 
> [ If a file has an entry in file_contexts, and is relabeled with 
> semanage fcontext, does that update 
> /etc/selinux/targeted/contexts/files/file_contexts with the change? I 
> was going to try, but forgot how to change the file type with semanage]

See the EXAMPLES section of the semanage man page.
semanage fcontext -a -t samba_share_t /var/www/html/testfile
The semanage command will update the file_contexts file with the change,
but does not immediately apply the label to any affected files - you
need to run restorecon on the files in order to apply it.

> 
> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0 
> /var/www/html/testfile
> 
> 5. Note: the current DAC permissions allow the httpd subject access to 
> this file. Change into a directory where your Linux user has write 
> access to, and run the wget http://localhost/testfile command. Unless 
> there are any changes to the default configuration, this command fails:
> 
> HTTP request sent, awaiting response... 403 Forbidden
> 2008-08-22 03:48:40 ERROR 403: Forbidden.
> 
> This example demonstrates the additional security added by SELinux. 
> Although the httpd subject had access to the object in step 5, because 
> the object was labeled with a file type that httpd subject does not have 
> access to, SELinux denied access. After step 5, an error such as the 
> following is logged to /var/log/messages:
> 
> Aug 22 03:48:40 localhost setroubleshoot: SELinux is preventing httpd 
> (httpd_t) "getattr"
> to /var/www/html/testfile (samba_share_t). For complete SELinux messages.
> run sealert -l c05911d3-e680-4e42-8e36-fe2ab9f8e654
> 
> Also, if the audit package is installed and the auditd subject is 
> running, a more detailed denial is logged to /var/log/audit/audit.log. 
> These denials are discussed later.
> 
> Unconfined Subjects
> 
> Unconfined subjects run in the unconfined_t domain type. This means that 
> SELinux policy rules do not apply, and only DAC permissions are used.

To be precise, the SELinux policy rules grant most permissions to the
unconfined_t domain, making it _effectively_ unconstrained by SELinux
even though the rules _are_ still applied.

> When an unconfined subject is comprised, an attacker may gain access to 
> a large number of system resources and data.
> 
> The following example demonstrates how the Apache HTTP Server (httpd) 
> can access data intended for use by another subject, when running 
> unconfined. Note: on Fedora 10, the httpd subject runs in the confined 
> httpd_t domain type by default. This is an example, and should not be 
> used in production. It assumes that the httpd and wget packages are 
> installed, that the SELinux targeted policy is used, and that SELinux is 
> running in enforcing mode:
> 
> 1. As the Linux root user, run the touch /var/www/html/test2file command.
> 
> 2. Run the ls -Z /var/www/html/test2file command to view the SELinux 
> context:
> 
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 
> /var/www/html/test2file
> 
> By default, Linux users run unconfined on Fedora 10, which is why the 
> test2file file object is labeled with the SELinux unconfined_u user. The 
> object_r role is a standard role, and does not affect access control. 
> The httpd_sys_content_t file type allows the httpd subject to access 
> this object.
> 
> 3. The /usr/bin/chcon command relabels files; however, such label 
> changes do not survive when the file system is relabeled. For permanent 
> changes that survive a file system relabel, use the /usr/sbin/semanage 
> command, which is discussed later. As the Linux root user, run the 
> /usr/bin/chcon -t samba_share_t /var/www/html/test2file command to 
> change the file type, to a file type that is used by Samba. Run the ls 
> -Z /var/www/html/test2file command to verify the changes:
> 
> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0 
> /var/www/html/test2file
> 
> 4. To simulate the httpd subject running unconfined, run the 
> /usr/sbin/setenforce 0 command as the Linux root user to temporarily 
> disable SELinux. Confirm SELinux is disabled by running the 
> /usr/sbin/getenforce command. When SELinux is disabled, 
> /usr/sbin/getenforce returns Permissive:
> 
> $ getenforce
> Permissive

There are more precise ways to make httpd unconfined w/o making the
entire system permissive, e.g.:
1) Label the httpd binary with unconfined_exec_t and re-start it, or
2) Making the httpd_t domain permissive (in F10 and later):
semanage permissive -a httpd_t

> 5. As the Linux root user, start the Apache HTTP Server: /sbin/service 
> httpd start. Change into a directory where your Linux user has write 
> access to, and run the wget http://localhost/test2file command. Unless 
> there are any changes to the default configuration, this command succeeds.
> 
> 6. Enable SELinux by running /usr/sbin/setenforce 1 command. When 
> SELinux is enabled, /usr/sbin/getenforce returns Enforcing:
> 
> $ getenforce
> Enforcing
> 
> The examples in these sections demonstrate how data can be protected 
> from a compromised confined-subject (protected by SELinux), as well as 
> how data is more accessible to an attacker from a compromised 
> unconfined-subject (not protected by SELinux).
> 
> Confined and Unconfined User Domains
> 
> In progress. Introduction to restrictions on certain domains (user_t, 
> guest_t etc).
> 
> Are there any SELinux restrictions on what users can do when they run 
> unconfined?

Yes.  They are still restricted by MCS.  There are certain booleans that
can apply certain restrictions like execmem, execstack.  And if they run
any program with its own domain and a domain transition is defined from
unconfined_t to the program's domain then they are still subject to the
restrictions on that domain.

-- 
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: "Targeted Policy" review

[Murray McAllister]

Stephen Smalley wrote:
> On Wed, 2008-09-03 at 17:41 +1000, Murray McAllister wrote:
>> Hi,
>>
>> The following is a draft of the "Targeted Policy" sections for the 
>> SELinux User Guide. Any comments and corrections are appreciated.
>>
>> Thanks.
>>
>> Targeted Policy
>>
>> Targeted policy is the default SELinux policy used in Fedora 10. When 
>> using targeted policy, subjects that are targeted run in their own 
>> domain type, and subjects that are not targeted run in the unconfined_t 
>> domain type. When a subject runs in the unconfined_t domain type, 
>> SELinux rules do not apply, and only DAC rules are used.
> 
> Not exactly true.  SELinux rules are always applied, but the
> unconfined_t domain is allowed (almost) all permissions in the SELinux
> policy/rules.

I have moved this part to the "Unconfined Subjects" section. How about:

Unconfined subjects run in the unconfined_t domain. For subjects running 
in this domain, SELinux policy rules are applied, but policy rules exist 
that allow subjects running in this domain almost all access. Subjects 
running in this domain almost always fall back to using DAC rules 
exclusively. When an unconfined subject is comprised, SELinux does not 
prevent the attacker from gaining access to system resources and data, 
and only DAC rules are used.

> 
>> Confined Subjects
>>
>> A large number of subjects are protected, and are therefore confined by 
>> the SELinux targeted policy, including the Apache HTTP Server (httpd), 
>> Samba (samba), FTP (vsftpd), Kerberos (krb5-server), ISC BIND (bind and 
>> bind-chroot), NFS (nfs-utils), and NIS (ypserv). When a subject is 
>> confined, it runs in its own domain type, such as the httpd subject 
>> running in the httpd_t domain type. When a confined subject is 
>> compromised by an attacker, the damage an attacker can do and the data 
>> they can access is greatly limited.
> 
> Greatly limited might be too strong as a general statement - it is
> limited in accordance with the policy, and thus depends on how the
> policy is configured.

How about:

When a confined subject is compromised by an attacker, depending on 
SELinux policy configuration, the attacker's access is to resources and 
the possible damage they can do is limited.

> 
>> The following example demonstrates how SELinux prevents the Apache HTTP 
>> Server (httpd) from reading files that are not correctly labeled, such 
>> as files intended for use by another subject. This is an example, and 
>> should not be used in production. It assumes that the httpd and wget 
>> packages are installed, that the SELinux targeted policy is used, and 
>> that SELinux is running in enforcing mode:
>>
>> 1. As the Linux root user, run the touch /var/www/html/testfile command.
>>
>> 2. Run the ls -Z /var/www/html/testfile command to view the SELinux 
>> context:
>>
>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 
>> /var/www/html/testfile
>>
>> By default, Linux users run unconfined on Fedora 10, which is why the 
>> testfile file object is labeled with the SELinux unconfined_u user. The 
>> object_r role is a standard role, and does not affect access control. 
>> The httpd_sys_content_t file type allows the httpd subject to access 
>> this object.
>>
>> [ What is object_r really for? ]
> 
> The default role value for objects, and one that avoids any restrictions
> on the user, type, and level combination in the object context.

RBAC is used for subjects, not objects. Roles do not have a meaning for 
objects, and the object_r role is a generic role that is used for objects.

> 
>> 3. As the Linux root user, start the Apache HTTP Server: /sbin/service 
>> httpd start. When the server has started, change into a directory where 
>> your Linux user has write access to, and run the wget 
>> http://localhost/testfile command. Unless there are any changes to the 
>> default configuration, this command succeeds.
>>
>> 4. The /usr/bin/chcon command relabels files; however, such label 
>> changes do not survive when the file system is relabeled. For permanent 
>> changes that survive a file system relabel, use the /usr/sbin/semanage 
>> command, which is discussed later. As the Linux root user, run the 
>> /usr/bin/chcon -t samba_share_t /var/www/html/testfile command to change 
>> the file type, to a file type that is used by Samba. Run the ls -Z 
>> /var/www/html/testfile command to verify the changes:
>>
>> [ If a file has an entry in file_contexts, and is relabeled with 
>> semanage fcontext, does that update 
>> /etc/selinux/targeted/contexts/files/file_contexts with the change? I 
>> was going to try, but forgot how to change the file type with semanage]
> 
> See the EXAMPLES section of the semanage man page.
> semanage fcontext -a -t samba_share_t /var/www/html/testfile
> The semanage command will update the file_contexts file with the change,
> but does not immediately apply the label to any affected files - you
> need to run restorecon on the files in order to apply it.
> 
>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0 
>> /var/www/html/testfile
>>
>> 5. Note: the current DAC permissions allow the httpd subject access to 
>> this file. Change into a directory where your Linux user has write 
>> access to, and run the wget http://localhost/testfile command. Unless 
>> there are any changes to the default configuration, this command fails:
>>
>> HTTP request sent, awaiting response... 403 Forbidden
>> 2008-08-22 03:48:40 ERROR 403: Forbidden.
>>
>> This example demonstrates the additional security added by SELinux. 
>> Although the httpd subject had access to the object in step 5, because 
>> the object was labeled with a file type that httpd subject does not have 
>> access to, SELinux denied access. After step 5, an error such as the 
>> following is logged to /var/log/messages:
>>
>> Aug 22 03:48:40 localhost setroubleshoot: SELinux is preventing httpd 
>> (httpd_t) "getattr"
>> to /var/www/html/testfile (samba_share_t). For complete SELinux messages.
>> run sealert -l c05911d3-e680-4e42-8e36-fe2ab9f8e654
>>
>> Also, if the audit package is installed and the auditd subject is 
>> running, a more detailed denial is logged to /var/log/audit/audit.log. 
>> These denials are discussed later.
>>
>> Unconfined Subjects
>>
>> Unconfined subjects run in the unconfined_t domain type. This means that 
>> SELinux policy rules do not apply, and only DAC permissions are used.
> 
> To be precise, the SELinux policy rules grant most permissions to the
> unconfined_t domain, making it _effectively_ unconstrained by SELinux
> even though the rules _are_ still applied.

See above.

> 
>> When an unconfined subject is comprised, an attacker may gain access to 
>> a large number of system resources and data.
>>
>> The following example demonstrates how the Apache HTTP Server (httpd) 
>> can access data intended for use by another subject, when running 
>> unconfined. Note: on Fedora 10, the httpd subject runs in the confined 
>> httpd_t domain type by default. This is an example, and should not be 
>> used in production. It assumes that the httpd and wget packages are 
>> installed, that the SELinux targeted policy is used, and that SELinux is 
>> running in enforcing mode:
>>
>> 1. As the Linux root user, run the touch /var/www/html/test2file command.
>>
>> 2. Run the ls -Z /var/www/html/test2file command to view the SELinux 
>> context:
>>
>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 
>> /var/www/html/test2file
>>
>> By default, Linux users run unconfined on Fedora 10, which is why the 
>> test2file file object is labeled with the SELinux unconfined_u user. The 
>> object_r role is a standard role, and does not affect access control. 
>> The httpd_sys_content_t file type allows the httpd subject to access 
>> this object.
>>
>> 3. The /usr/bin/chcon command relabels files; however, such label 
>> changes do not survive when the file system is relabeled. For permanent 
>> changes that survive a file system relabel, use the /usr/sbin/semanage 
>> command, which is discussed later. As the Linux root user, run the 
>> /usr/bin/chcon -t samba_share_t /var/www/html/test2file command to 
>> change the file type, to a file type that is used by Samba. Run the ls 
>> -Z /var/www/html/test2file command to verify the changes:
>>
>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0 
>> /var/www/html/test2file
>>
>> 4. To simulate the httpd subject running unconfined, run the 
>> /usr/sbin/setenforce 0 command as the Linux root user to temporarily 
>> disable SELinux. Confirm SELinux is disabled by running the 
>> /usr/sbin/getenforce command. When SELinux is disabled, 
>> /usr/sbin/getenforce returns Permissive:
>>
>> $ getenforce
>> Permissive
> 
> There are more precise ways to make httpd unconfined w/o making the
> entire system permissive, e.g.:
> 1) Label the httpd binary with unconfined_exec_t and re-start it, or
> 2) Making the httpd_t domain permissive (in F10 and later):
> semanage permissive -a httpd_t

I'll update the example (probably with semanage permissive -a httpd_t)

> 
>> 5. As the Linux root user, start the Apache HTTP Server: /sbin/service 
>> httpd start. Change into a directory where your Linux user has write 
>> access to, and run the wget http://localhost/test2file command. Unless 
>> there are any changes to the default configuration, this command succeeds.
>>
>> 6. Enable SELinux by running /usr/sbin/setenforce 1 command. When 
>> SELinux is enabled, /usr/sbin/getenforce returns Enforcing:
>>
>> $ getenforce
>> Enforcing
>>
>> The examples in these sections demonstrate how data can be protected 
>> from a compromised confined-subject (protected by SELinux), as well as 
>> how data is more accessible to an attacker from a compromised 
>> unconfined-subject (not protected by SELinux).
>>
>> Confined and Unconfined User Domains
>>
>> In progress. Introduction to restrictions on certain domains (user_t, 
>> guest_t etc).
>>
>> Are there any SELinux restrictions on what users can do when they run 
>> unconfined?
> 
> Yes.  They are still restricted by MCS.  There are certain booleans that
> can apply certain restrictions like execmem, execstack.  And if they run
> any program with its own domain and a domain transition is defined from
> unconfined_t to the program's domain then they are still subject to the
> restrictions on that domain.

Thanks for your feedback.


--
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: "Targeted Policy" review

[Stephen Smalley]

On Fri, 2008-09-05 at 16:04 +1000, Murray McAllister wrote:
> 
> I have moved this part to the "Unconfined Subjects" section. How about:
> 
> Unconfined subjects run in the unconfined_t domain. For subjects running 
> in this domain, SELinux policy rules are applied, but policy rules exist 
> that allow subjects running in this domain almost all access. Subjects 
> running in this domain almost always fall back to using DAC rules 
> exclusively. When an unconfined subject is comprised, SELinux does not 

s/comprised/compromised/

> prevent the attacker from gaining access to system resources and data, 
> and only DAC rules are used.

Otherwise, sounds fine.

-- 
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: "Targeted Policy" review

[Daniel J Walsh]

Murray McAllister wrote:
> Stephen Smalley wrote:
>> On Wed, 2008-09-03 at 17:41 +1000, Murray McAllister wrote:
>>> Hi,
>>>
>>> The following is a draft of the "Targeted Policy" sections for the
>>> SELinux User Guide. Any comments and corrections are appreciated.
>>>
>>> Thanks.
>>>
>>> Targeted Policy
>>>
>>> Targeted policy is the default SELinux policy used in Fedora 10. When
>>> using targeted policy, subjects that are targeted run in their own
>>> domain type, and subjects that are not targeted run in the
>>> unconfined_t domain type. When a subject runs in the unconfined_t
>>> domain type, SELinux rules do not apply, and only DAC rules are used.
>>
>> Not exactly true.  SELinux rules are always applied, but the
>> unconfined_t domain is allowed (almost) all permissions in the SELinux
>> policy/rules.
> 
> I have moved this part to the "Unconfined Subjects" section. How about:
> 
> Unconfined subjects run in the unconfined_t domain. For subjects running
> in this domain, SELinux policy rules are applied, but policy rules exist
> that allow subjects running in this domain almost all access. Subjects
> running in this domain almost always fall back to using DAC rules
> exclusively. When an unconfined subject is comprised, SELinux does not
> prevent the attacker from gaining access to system resources and data,
> and only DAC rules are used.
> 
>>
>>> Confined Subjects
>>>
>>> A large number of subjects are protected, and are therefore confined
>>> by the SELinux targeted policy, including the Apache HTTP Server
>>> (httpd), Samba (samba), FTP (vsftpd), Kerberos (krb5-server), ISC
>>> BIND (bind and bind-chroot), NFS (nfs-utils), and NIS (ypserv). When
>>> a subject is confined, it runs in its own domain type, such as the
>>> httpd subject running in the httpd_t domain type. When a confined
>>> subject is compromised by an attacker, the damage an attacker can do
>>> and the data they can access is greatly limited.
>>
>> Greatly limited might be too strong as a general statement - it is
>> limited in accordance with the policy, and thus depends on how the
>> policy is configured.
> 
> How about:
> 
> When a confined subject is compromised by an attacker, depending on
> SELinux policy configuration, the attacker's access is to resources and
> the possible damage they can do is limited.
> 
If a confined ...

>>
>>> The following example demonstrates how SELinux prevents the Apache
>>> HTTP Server (httpd) from reading files that are not correctly
>>> labeled, such as files intended for use by another subject. This is
>>> an example, and should not be used in production. It assumes that the
>>> httpd and wget packages are installed, that the SELinux targeted
>>> policy is used, and that SELinux is running in enforcing mode:
>>>
>>> 1. As the Linux root user, run the touch /var/www/html/testfile command.
>>>
>>> 2. Run the ls -Z /var/www/html/testfile command to view the SELinux
>>> context:
>>>
>>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
>>> /var/www/html/testfile
>>>
>>> By default, Linux users run unconfined on Fedora 10, which is why the
>>> testfile file object is labeled with the SELinux unconfined_u user.
>>> The object_r role is a standard role, and does not affect access
>>> control. The httpd_sys_content_t file type allows the httpd subject
>>> to access this object.
>>>
>>> [ What is object_r really for? ]
>>
>> The default role value for objects, and one that avoids any restrictions
>> on the user, type, and level combination in the object context.
> 
> RBAC is used for subjects, not objects. Roles do not have a meaning for
> objects, and the object_r role is a generic role that is used for objects.
> 
>>
>>> 3. As the Linux root user, start the Apache HTTP Server:
>>> /sbin/service httpd start. When the server has started, change into a
>>> directory where your Linux user has write access to, and run the wget
>>> http://localhost/testfile command. Unless there are any changes to
>>> the default configuration, this command succeeds.
>>>
>>> 4. The /usr/bin/chcon command relabels files; however, such label
>>> changes do not survive when the file system is relabeled. For
>>> permanent changes that survive a file system relabel, use the
>>> /usr/sbin/semanage command, which is discussed later. As the Linux
>>> root user, run the /usr/bin/chcon -t samba_share_t
>>> /var/www/html/testfile command to change the file type, to a file
>>> type that is used by Samba. Run the ls -Z /var/www/html/testfile
>>> command to verify the changes:
>>>
>>> [ If a file has an entry in file_contexts, and is relabeled with
>>> semanage fcontext, does that update
>>> /etc/selinux/targeted/contexts/files/file_contexts with the change? I
>>> was going to try, but forgot how to change the file type with semanage]
>>
>> See the EXAMPLES section of the semanage man page.
>> semanage fcontext -a -t samba_share_t /var/www/html/testfile
>> The semanage command will update the file_contexts file with the change,
>> but does not immediately apply the label to any affected files - you
>> need to run restorecon on the files in order to apply it.
>>
>>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
>>> /var/www/html/testfile
>>>
>>> 5. Note: the current DAC permissions allow the httpd subject access
>>> to this file. Change into a directory where your Linux user has write
>>> access to, and run the wget http://localhost/testfile command. Unless
>>> there are any changes to the default configuration, this command fails:
>>>
>>> HTTP request sent, awaiting response... 403 Forbidden
>>> 2008-08-22 03:48:40 ERROR 403: Forbidden.
>>>
>>> This example demonstrates the additional security added by SELinux.
>>> Although the httpd subject had access to the object in step 5,
>>> because the object was labeled with a file type that httpd subject
>>> does not have access to, SELinux denied access. After step 5, an
>>> error such as the following is logged to /var/log/messages:
>>>
>>> Aug 22 03:48:40 localhost setroubleshoot: SELinux is preventing httpd
>>> (httpd_t) "getattr"
>>> to /var/www/html/testfile (samba_share_t). For complete SELinux
>>> messages.
>>> run sealert -l c05911d3-e680-4e42-8e36-fe2ab9f8e654
>>>
>>> Also, if the audit package is installed and the auditd subject is
>>> running, a more detailed denial is logged to
>>> /var/log/audit/audit.log. These denials are discussed later.
>>>
>>> Unconfined Subjects
>>>
>>> Unconfined subjects run in the unconfined_t domain type. This means
>>> that SELinux policy rules do not apply, and only DAC permissions are
>>> used.
>>
Only unconfined login users run as unconfined_t, init programs run in
the unconfined domain initrc_t, unconfined inetd processes run in the
inetd_child_t domain.  Unconfined kernel processes run in kernel_t.
There are about 20 unconfined domains in Fedora 10.
>> To be precise, the SELinux policy rules grant most permissions to the
>> unconfined_t domain, making it _effectively_ unconstrained by SELinux
>> even though the rules _are_ still applied.
> 
> See above.
> 
>>
>>> When an unconfined subject is comprised, an attacker may gain access
>>> to a large number of system resources and data.
>>>
>>> The following example demonstrates how the Apache HTTP Server (httpd)
>>> can access data intended for use by another subject, when running
>>> unconfined. Note: on Fedora 10, the httpd subject runs in the
>>> confined httpd_t domain type by default. This is an example, and
>>> should not be used in production. It assumes that the httpd and wget
>>> packages are installed, that the SELinux targeted policy is used, and
>>> that SELinux is running in enforcing mode:
>>>
>>> 1. As the Linux root user, run the touch /var/www/html/test2file
>>> command.
>>>
>>> 2. Run the ls -Z /var/www/html/test2file command to view the SELinux
>>> context:
>>>
>>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
>>> /var/www/html/test2file
>>>
>>> By default, Linux users run unconfined on Fedora 10, which is why the
>>> test2file file object is labeled with the SELinux unconfined_u user.
>>> The object_r role is a standard role, and does not affect access
>>> control. The httpd_sys_content_t file type allows the httpd subject
>>> to access this object.
>>>
>>> 3. The /usr/bin/chcon command relabels files; however, such label
>>> changes do not survive when the file system is relabeled. For
>>> permanent changes that survive a file system relabel, use the
>>> /usr/sbin/semanage command, which is discussed later. As the Linux
>>> root user, run the /usr/bin/chcon -t samba_share_t
>>> /var/www/html/test2file command to change the file type, to a file
>>> type that is used by Samba. Run the ls -Z /var/www/html/test2file
>>> command to verify the changes:
>>>
>>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
>>> /var/www/html/test2file
>>>
>>> 4. To simulate the httpd subject running unconfined, run the
>>> /usr/sbin/setenforce 0 command as the Linux root user to temporarily
>>> disable SELinux. Confirm SELinux is disabled by running the
>>> /usr/sbin/getenforce command. When SELinux is disabled,
>>> /usr/sbin/getenforce returns Permissive:
>>>
>>> $ getenforce
>>> Permissive
>>
>> There are more precise ways to make httpd unconfined w/o making the
>> entire system permissive, e.g.:
>> 1) Label the httpd binary with unconfined_exec_t and re-start it, or
>> 2) Making the httpd_t domain permissive (in F10 and later):
>> semanage permissive -a httpd_t
> 
> I'll update the example (probably with semanage permissive -a httpd_t)
> 
>>
>>> 5. As the Linux root user, start the Apache HTTP Server:
>>> /sbin/service httpd start. Change into a directory where your Linux
>>> user has write access to, and run the wget http://localhost/test2file
>>> command. Unless there are any changes to the default configuration,
>>> this command succeeds.
>>>
>>> 6. Enable SELinux by running /usr/sbin/setenforce 1 command. When
>>> SELinux is enabled, /usr/sbin/getenforce returns Enforcing:
>>>
>>> $ getenforce
>>> Enforcing
>>>
>>> The examples in these sections demonstrate how data can be protected
>>> from a compromised confined-subject (protected by SELinux), as well
>>> as how data is more accessible to an attacker from a compromised
>>> unconfined-subject (not protected by SELinux).
>>>
>>> Confined and Unconfined User Domains
>>>
>>> In progress. Introduction to restrictions on certain domains (user_t,
>>> guest_t etc).
>>>
>>> Are there any SELinux restrictions on what users can do when they run
>>> unconfined?
>>
>> Yes.  They are still restricted by MCS.  There are certain booleans that
>> can apply certain restrictions like execmem, execstack.  And if they run
>> any program with its own domain and a domain transition is defined from
>> unconfined_t to the program's domain then they are still subject to the
>> restrictions on that domain.
> 
> Thanks for your feedback.
> 
> 
> -- 
> 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: "Targeted Policy" review

[Murray McAllister]

Daniel J Walsh wrote:
> Murray McAllister wrote:
>> Stephen Smalley wrote:
>>> On Wed, 2008-09-03 at 17:41 +1000, Murray McAllister wrote:

>> When a confined subject is compromised by an attacker, depending on
>> SELinux policy configuration, the attacker's access is to resources and
>> the possible damage they can do is limited.
>>
> If a confined ...

Changed.

>>>> Unconfined Subjects
>>>>
>>>> Unconfined subjects run in the unconfined_t domain type. This means
>>>> that SELinux policy rules do not apply, and only DAC permissions are
>>>> used.
> Only unconfined login users run as unconfined_t, init programs run in
> the unconfined domain initrc_t, unconfined inetd processes run in the
> inetd_child_t domain.  Unconfined kernel processes run in kernel_t.
> There are about 20 unconfined domains in Fedora 10.

How about:

Unconfined subjects run in unconfined domains, for example, init 
programs run in the unconfined initrc_t domain, unconfined kernel 
subjects run in the kernel_t domain, and unconfined Linux users run in 
the unconfined_t domain. For unconfined subjects, SELinux policy rules 
are applied, but policy rules exist that allow subjects running in 
unconfined domains almost all access. Subjects running in unconfined 
domains almost always fall back to using DAC rules exclusively. If an 
unconfined subject is compromised, SELinux does not prevent the attacker 
from gaining access to system resources and data, but of course, DAC 
rules are still used. SELinux is a security enhancement above DAC rules 
- it does not replace them.

--
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: "Targeted Policy" review

[Daniel J Walsh]

Murray McAllister wrote:
> Daniel J Walsh wrote:
>> Murray McAllister wrote:
>>> Stephen Smalley wrote:
>>>> On Wed, 2008-09-03 at 17:41 +1000, Murray McAllister wrote:
> 
>>> When a confined subject is compromised by an attacker, depending on
>>> SELinux policy configuration, the attacker's access is to resources and
>>> the possible damage they can do is limited.
>>>
>> If a confined ...
> 
> Changed.
> 
>>>>> Unconfined Subjects
>>>>>
>>>>> Unconfined subjects run in the unconfined_t domain type. This means
>>>>> that SELinux policy rules do not apply, and only DAC permissions are
>>>>> used.
>> Only unconfined login users run as unconfined_t, init programs run in
>> the unconfined domain initrc_t, unconfined inetd processes run in the
>> inetd_child_t domain.  Unconfined kernel processes run in kernel_t.
>> There are about 20 unconfined domains in Fedora 10.
> 
> How about:
> 
> Unconfined subjects run in unconfined domains, for example, init
> programs run in the unconfined initrc_t domain, unconfined kernel
> subjects run in the kernel_t domain, and unconfined Linux users run in
> the unconfined_t domain. For unconfined subjects, SELinux policy rules
> are applied, but policy rules exist that allow subjects running in
> unconfined domains almost all access. Subjects running in unconfined
> domains almost always fall back to using DAC rules exclusively. If an
> unconfined subject is compromised, SELinux does not prevent the attacker
> from gaining access to system resources and data, but of course, DAC
> rules are still used. SELinux is a security enhancement above DAC rules
> - it does not replace them.

I don't think you need the "almost always"


--
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: "Targeted Policy" review

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Murray McAllister wrote:
> Hi,
> 
> The following is a draft of the "Targeted Policy" sections for the
> SELinux User Guide. Any comments and corrections are appreciated.
> 
> Thanks.
> 
> Targeted Policy
> 
> Targeted policy is the default SELinux policy used in Fedora 10. When
> using targeted policy, subjects that are targeted run in their own
> domain type, and subjects that are not targeted run in the unconfined_t
confined domain, and subjects that are not targeted run in an unconfined
domain,  For example logged in users by default log in as unconfined_t
while system processes started by init run in initrc_t.  Both of these
domains are unconfined.

NOTE:

Even unconfined domains are subject to executable/writable memory
checks.  execmem, execstack, execheap.  By default processes run as an
unconfined domain can not allocate writeable memory and execute it.
This is a common attack vector call buffer overflow attacks.  Some
applications require this type of access (java, wine, mono and a few
others).   These applications need to be labeled correctly to allow the
access.  There are booleans that can turn off this protection for the
unconfined user unconfined_t.  allow_execmem, allow_execstack,
allow_execheap.

You can turn the booleans on using setsebool

setsebool -P allow_execmem 1

> domain type. When a subject runs in the unconfined_t domain type,

> SELinux rules do not apply, and only DAC rules are used.
> 
> Confined Subjects
> 
> large number of subjects are protected, and are therefore confined by
Greater then 200, subjects are not protected they are confined.  IE A
subject could still be compromized but other processes on the system are
protected from the confined process.
> the SELinux targeted policy, including the Apache HTTP Server (httpd),
> Samba (samba), FTP (vsftpd), Kerberos (krb5-server), ISC BIND (bind and
> bind-chroot), NFS (nfs-utils), and NIS (ypserv). 
This is an old RHEL4 list.  Almost every domain that listens to the
internet is now confined.  And most processes that run as root and do
stuff for users are confined.
When a subject is
> confined, it runs in its own domain type, such as the httpd subject
> running in the httpd_t domain type. When a confined subject is
> compromised by an attacker, the damage an attacker can do and the data
> they can access is greatly limited.
> 
> The following example demonstrates how SELinux prevents the Apache HTTP
> Server (httpd) from reading files that are not correctly labeled, such
> as files intended for use by another subject. This is an example, and
> should not be used in production. It assumes that the httpd and wget
> packages are installed, that the SELinux targeted policy is used, and
> that SELinux is running in enforcing mode:
> 
> 1. As the Linux root user, run the touch /var/www/html/testfile command.
> 
> 2. Run the ls -Z /var/www/html/testfile command to view the SELinux
> context:
> 
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
> /var/www/html/testfile
> 
Make sure the machine is in enforcing mode, setenforce 1.
> By default, Linux users run unconfined on Fedora 10, which is why the
> testfile file object is labeled with the SELinux unconfined_u user. The
> object_r role is a standard role, and does not affect access control.
> The httpd_sys_content_t file type allows the httpd subject to access
> this object.
> 
> [ What is object_r really for? ]
Not used on objects so it is just the default.
> 
> 3. As the Linux root user, start the Apache HTTP Server: /sbin/service
> httpd start. When the server has started, change into a directory where
> your Linux user has write access to, and run the wget
> http://localhost/testfile command. Unless there are any changes to the
> default configuration, this command succeeds.
> 
> 4. The /usr/bin/chcon command relabels files; however, such label
> changes do not survive when the file system is relabeled. For permanent
> changes that survive a file system relabel, use the /usr/sbin/semanage
> command, which is discussed later. As the Linux root user, run the
> /usr/bin/chcon -t samba_share_t /var/www/html/testfile command to change
> the file type, to a file type that is used by Samba. Run the ls -Z
> /var/www/html/testfile command to verify the changes:
> 
> [ If a file has an entry in file_contexts, and is relabeled with
> semanage fcontext, does that update
> /etc/selinux/targeted/contexts/files/file_contexts with the change? I
> was going to try, but forgot how to change the file type with semanage]
> 
Yes it will update /etc/selinux/targeted/contexts/files/file_contexts
> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
> /var/www/html/testfile
> 
> 5. Note: the current DAC permissions allow the httpd subject access to
> this file. Change into a directory where your Linux user has write
> access to, and run the wget http://localhost/testfile command. Unless
> there are any changes to the default configuration, this command fails:
> 
> HTTP request sent, awaiting response... 403 Forbidden
> 2008-08-22 03:48:40 ERROR 403: Forbidden.
> 
> This example demonstrates the additional security added by SELinux.
> Although the httpd subject had access to the object in step 5, because
> the object was labeled with a file type that httpd subject does not have
> access to, SELinux denied access. After step 5, an error such as the
> following is logged to /var/log/messages:
> 
> Aug 22 03:48:40 localhost setroubleshoot: SELinux is preventing httpd
> (httpd_t) "getattr"
> to /var/www/html/testfile (samba_share_t). For complete SELinux messages.
> run sealert -l c05911d3-e680-4e42-8e36-fe2ab9f8e654
> 
setroubleshoot requires audit subsystem to be running.
> Also, if the audit package is installed and the auditd subject is
> running, a more detailed denial is logged to /var/log/audit/audit.log.
> These denials are discussed later.
> 
> Unconfined Subjects
> 
> Unconfined subjects run in the unconfined_t domain type. This means that
Unconfined subjects run in the unconfined domain. This means that
> SELinux policy rules do not apply, and only DAC permissions are used.
> When an unconfined subject is comprised, an attacker may gain access to
> a large number of system resources and data.
> 
I think this would be better stated:

If an unconfined subject is compromized, SELinux will not prevent the
attacker from gaining access to system resources and data, the system
will still have DAC protection.

> The following example demonstrates how the Apache HTTP Server (httpd)
> can access data intended for use by another subject, when running
> unconfined. Note: on Fedora 10, the httpd subject runs in the confined
> httpd_t domain type by default. This is an example, and should not be
> used in production. It assumes that the httpd and wget packages are
> installed, that the SELinux targeted policy is used, and that SELinux is
> running in enforcing mode:
> 
> 1. As the Linux root user, run the touch /var/www/html/test2file command.
> 
> 2. Run the ls -Z /var/www/html/test2file command to view the SELinux
> context:
> 
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
> /var/www/html/test2file
> 
> By default, Linux users run unconfined on Fedora 10, which is why the
> test2file file object is labeled with the SELinux unconfined_u user. The
> object_r role is a standard role, and does not affect access control.
> The httpd_sys_content_t file type allows the httpd subject to access
> this object.
> 
> 3. The /usr/bin/chcon command relabels files; however, such label
> changes do not survive when the file system is relabeled. For permanent
> changes that survive a file system relabel, use the /usr/sbin/semanage
> command, which is discussed later. As the Linux root user, run the
> /usr/bin/chcon -t samba_share_t /var/www/html/test2file command to
> change the file type, to a file type that is used by Samba. Run the ls
> -Z /var/www/html/test2file command to verify the changes:
> 
> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
> /var/www/html/test2file
> 
> 4. To simulate the httpd subject running unconfined, run the
> /usr/sbin/setenforce 0 command as the Linux root user to temporarily
> disable SELinux. Confirm SELinux is disabled by running the
> /usr/sbin/getenforce command. When SELinux is disabled,
> /usr/sbin/getenforce returns Permissive:
> 
> $ getenforce
> Permissive
> 
> 5. As the Linux root user, start the Apache HTTP Server: /sbin/service
> httpd start. Change into a directory where your Linux user has write
> access to, and run the wget http://localhost/test2file command. Unless
> there are any changes to the default configuration, this command succeeds.
> 
> 6. Enable SELinux by running /usr/sbin/setenforce 1 command. When
> SELinux is enabled, /usr/sbin/getenforce returns Enforcing:
> 
> $ getenforce
> Enforcing
> 
> The examples in these sections demonstrate how data can be protected
> from a compromised confined-subject (protected by SELinux), as well as
> how data is more accessible to an attacker from a compromised
> unconfined-subject (not protected by SELinux).
> 
> Confined and Unconfined User Domains
> 
> In progress. Introduction to restrictions on certain domains (user_t,
> guest_t etc).
> 
> Are there any SELinux restrictions on what users can do when they run
> unconfined?
> 
See above,  Also there are booleans available to allow the transition to
 a confined domain from the unconfined_t.  The one I would like to
encourage is.

allow_unconfined_nsplugin_transition

Which will transition firefox plugins to a confined domain.
> -- 
> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAki+kQYACgkQrlYvE4MpobNPWQCgujeWSr7KJHhu0qtsded8Ftyb
+kIAoM2oo7FMz9n8NedTIyI/wh0sOG6K
=Yeqt
-----END PGP SIGNATURE-----

--
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: "Targeted Policy" review

[Murray McAllister]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Murray McAllister wrote:
>> Hi,
>>
>> The following is a draft of the "Targeted Policy" sections for the
>> SELinux User Guide. Any comments and corrections are appreciated.
>>
>> Thanks.
>>
>> Targeted Policy
>>
>> Targeted policy is the default SELinux policy used in Fedora 10. When
>> using targeted policy, subjects that are targeted run in their own
>> domain type, and subjects that are not targeted run in the unconfined_t
> confined domain, and subjects that are not targeted run in an unconfined
> domain,  For example logged in users by default log in as unconfined_t
> while system processes started by init run in initrc_t.  Both of these
> domains are unconfined.
> 
> NOTE:
> 
> Even unconfined domains are subject to executable/writable memory
> checks.  execmem, execstack, execheap.  By default processes run as an
> unconfined domain can not allocate writeable memory and execute it.
> This is a common attack vector call buffer overflow attacks.  Some
> applications require this type of access (java, wine, mono and a few
> others). 

Does this mean applications running in a Java Virtual Machine, and in Wine?

I'll change my response below based on the answer to this.

These applications need to be labeled correctly to allow the
> access.  There are booleans that can turn off this protection for the
> unconfined user unconfined_t.  allow_execmem, allow_execstack,
> allow_execheap.
> 
> You can turn the booleans on using setsebool
> 
> setsebool -P allow_execmem 1

I will use these examples later on.


How about:

Targeted policy is the default SELinux policy used in Fedora 10. When 
using targeted policy, subjects that are targeted run in a confined 
domain, and subjects that are not targeted run in an unconfined domain. 
For example, by default, logged in users run in the unconfined_t domain, 
and system processes started by init run in the initrc_t domain - both 
of these domains are unconfined.

Unconfined domains (as well as confined domains) are subject to 
executable and writeable memory checks. By default, subjects running in 
an unconfined domain can not allocate writeable memory and execute it.

[I think I changed the meaning. Is it still correct? ]

This reduces vulnerability to buffer overflow attacks. Some subjects 
require this access, including but not limited to Java™, Wine and Mono. 
To allow this access, these subjects must be labeled correctly, and 
memory checks need to be disabled for the users running in the 
unconfined_t domain. These memory checks are disable by setting 
booleans, which allow the SELinux policy to be modified during runtime. 
Configuring booleans is discussed later.

> 
>> domain type. When a subject runs in the unconfined_t domain type,
> 
>> SELinux rules do not apply, and only DAC rules are used.
>>
>> Confined Subjects
>>
>> large number of subjects are protected, and are therefore confined by
> Greater then 200, subjects are not protected they are confined.  IE A
> subject could still be compromized but other processes on the system are
> protected from the confined process.
>> the SELinux targeted policy, including the Apache HTTP Server (httpd),
>> Samba (samba), FTP (vsftpd), Kerberos (krb5-server), ISC BIND (bind and
>> bind-chroot), NFS (nfs-utils), and NIS (ypserv). 
> This is an old RHEL4 list.  Almost every domain that listens to the
> internet is now confined.  And most processes that run as root and do
> stuff for users are confined.
> When a subject is
>> confined, it runs in its own domain type, such as the httpd subject
>> running in the httpd_t domain type. When a confined subject is
>> compromised by an attacker, the damage an attacker can do and the data
>> they can access is greatly limited.

How about:

Almost every subject that has network access is confined in Fedora 10. 
Most subjects that run as the Linux root user and perform tasks for 
users, such as the passwd application, are confined. When a subject is 
confined, it runs in its own domain, such as the httpd subject running 
in the httpd_t domain. When a confined subject is compromised by an 
attacker, depending on SELinux policy configuration, the attacker's 
access is to resources and the possible damage they can do is limited.

>>
>> The following example demonstrates how SELinux prevents the Apache HTTP
>> Server (httpd) from reading files that are not correctly labeled, such
>> as files intended for use by another subject. This is an example, and
>> should not be used in production. It assumes that the httpd and wget
>> packages are installed, that the SELinux targeted policy is used, and
>> that SELinux is running in enforcing mode:
>>
>> 1. As the Linux root user, run the touch /var/www/html/testfile command.
>>
>> 2. Run the ls -Z /var/www/html/testfile command to view the SELinux
>> context:
>>
>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
>> /var/www/html/testfile
>>
> Make sure the machine is in enforcing mode, setenforce 1.

I am adding more steps and example output.

>> By default, Linux users run unconfined on Fedora 10, which is why the
>> testfile file object is labeled with the SELinux unconfined_u user. The
>> object_r role is a standard role, and does not affect access control.
>> The httpd_sys_content_t file type allows the httpd subject to access
>> this object.
>>
>> [ What is object_r really for? ]
> Not used on objects so it is just the default.
>> 3. As the Linux root user, start the Apache HTTP Server: /sbin/service
>> httpd start. When the server has started, change into a directory where
>> your Linux user has write access to, and run the wget
>> http://localhost/testfile command. Unless there are any changes to the
>> default configuration, this command succeeds.
>>
>> 4. The /usr/bin/chcon command relabels files; however, such label
>> changes do not survive when the file system is relabeled. For permanent
>> changes that survive a file system relabel, use the /usr/sbin/semanage
>> command, which is discussed later. As the Linux root user, run the
>> /usr/bin/chcon -t samba_share_t /var/www/html/testfile command to change
>> the file type, to a file type that is used by Samba. Run the ls -Z
>> /var/www/html/testfile command to verify the changes:
>>
>> [ If a file has an entry in file_contexts, and is relabeled with
>> semanage fcontext, does that update
>> /etc/selinux/targeted/contexts/files/file_contexts with the change? I
>> was going to try, but forgot how to change the file type with semanage]
>>
> Yes it will update /etc/selinux/targeted/contexts/files/file_contexts
>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
>> /var/www/html/testfile
>>
>> 5. Note: the current DAC permissions allow the httpd subject access to
>> this file. Change into a directory where your Linux user has write
>> access to, and run the wget http://localhost/testfile command. Unless
>> there are any changes to the default configuration, this command fails:
>>
>> HTTP request sent, awaiting response... 403 Forbidden
>> 2008-08-22 03:48:40 ERROR 403: Forbidden.
>>
>> This example demonstrates the additional security added by SELinux.
>> Although the httpd subject had access to the object in step 5, because
>> the object was labeled with a file type that httpd subject does not have
>> access to, SELinux denied access. After step 5, an error such as the
>> following is logged to /var/log/messages:
>>
>> Aug 22 03:48:40 localhost setroubleshoot: SELinux is preventing httpd
>> (httpd_t) "getattr"
>> to /var/www/html/testfile (samba_share_t). For complete SELinux messages.
>> run sealert -l c05911d3-e680-4e42-8e36-fe2ab9f8e654
>>
> setroubleshoot requires audit subsystem to be running.
>> Also, if the audit package is installed and the auditd subject is
>> running, a more detailed denial is logged to /var/log/audit/audit.log.
>> These denials are discussed later.
>>
>> Unconfined Subjects
>>
>> Unconfined subjects run in the unconfined_t domain type. This means that
> Unconfined subjects run in the unconfined domain. This means that
>> SELinux policy rules do not apply, and only DAC permissions are used.
>> When an unconfined subject is comprised, an attacker may gain access to
>> a large number of system resources and data.
>>
> I think this would be better stated:
> 
> If an unconfined subject is compromized, SELinux will not prevent the
> attacker from gaining access to system resources and data, the system
> will still have DAC protection.

How about:

When an unconfined subject is comprised, SELinux does not prevent the 
attacker from gaining access to system resources and data, and DAC rules 
are used.

(I should probably change these to "If an...")

> 
>> The following example demonstrates how the Apache HTTP Server (httpd)
>> can access data intended for use by another subject, when running
>> unconfined. Note: on Fedora 10, the httpd subject runs in the confined
>> httpd_t domain type by default. This is an example, and should not be
>> used in production. It assumes that the httpd and wget packages are
>> installed, that the SELinux targeted policy is used, and that SELinux is
>> running in enforcing mode:
>>
>> 1. As the Linux root user, run the touch /var/www/html/test2file command.
>>
>> 2. Run the ls -Z /var/www/html/test2file command to view the SELinux
>> context:
>>
>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
>> /var/www/html/test2file
>>
>> By default, Linux users run unconfined on Fedora 10, which is why the
>> test2file file object is labeled with the SELinux unconfined_u user. The
>> object_r role is a standard role, and does not affect access control.
>> The httpd_sys_content_t file type allows the httpd subject to access
>> this object.
>>
>> 3. The /usr/bin/chcon command relabels files; however, such label
>> changes do not survive when the file system is relabeled. For permanent
>> changes that survive a file system relabel, use the /usr/sbin/semanage
>> command, which is discussed later. As the Linux root user, run the
>> /usr/bin/chcon -t samba_share_t /var/www/html/test2file command to
>> change the file type, to a file type that is used by Samba. Run the ls
>> -Z /var/www/html/test2file command to verify the changes:
>>
>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
>> /var/www/html/test2file
>>
>> 4. To simulate the httpd subject running unconfined, run the
>> /usr/sbin/setenforce 0 command as the Linux root user to temporarily
>> disable SELinux. Confirm SELinux is disabled by running the
>> /usr/sbin/getenforce command. When SELinux is disabled,
>> /usr/sbin/getenforce returns Permissive:
>>
>> $ getenforce
>> Permissive
>>
>> 5. As the Linux root user, start the Apache HTTP Server: /sbin/service
>> httpd start. Change into a directory where your Linux user has write
>> access to, and run the wget http://localhost/test2file command. Unless
>> there are any changes to the default configuration, this command succeeds.
>>
>> 6. Enable SELinux by running /usr/sbin/setenforce 1 command. When
>> SELinux is enabled, /usr/sbin/getenforce returns Enforcing:
>>
>> $ getenforce
>> Enforcing
>>
>> The examples in these sections demonstrate how data can be protected
>> from a compromised confined-subject (protected by SELinux), as well as
>> how data is more accessible to an attacker from a compromised
>> unconfined-subject (not protected by SELinux).
>>
>> Confined and Unconfined User Domains
>>
>> In progress. Introduction to restrictions on certain domains (user_t,
>> guest_t etc).
>>
>> Are there any SELinux restrictions on what users can do when they run
>> unconfined?
>>
> See above,  Also there are booleans available to allow the transition to
>  a confined domain from the unconfined_t.  The one I would like to
> encourage is.
> 
> allow_unconfined_nsplugin_transition
> 
> Which will transition firefox plugins to a confined domain.
>> -- 
>> 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.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAki+kQYACgkQrlYvE4MpobNPWQCgujeWSr7KJHhu0qtsded8Ftyb
> +kIAoM2oo7FMz9n8NedTIyI/wh0sOG6K
> =Yeqt
> -----END PGP SIGNATURE-----

Thanks for your help.

--
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: "Targeted Policy" review

[Daniel J Walsh]

Murray McAllister wrote:
> Daniel J Walsh wrote:
> Murray McAllister wrote:
>>>> Hi,
>>>>
>>>> The following is a draft of the "Targeted Policy" sections for the
>>>> SELinux User Guide. Any comments and corrections are appreciated.
>>>>
>>>> Thanks.
>>>>
>>>> Targeted Policy
>>>>
>>>> Targeted policy is the default SELinux policy used in Fedora 10. When
>>>> using targeted policy, subjects that are targeted run in their own
>>>> domain type, and subjects that are not targeted run in the unconfined_t
> confined domain, and subjects that are not targeted run in an unconfined
> domain,  For example logged in users by default log in as unconfined_t
> while system processes started by init run in initrc_t.  Both of these
> domains are unconfined.
> 
> NOTE:
> 
> Even unconfined domains are subject to executable/writable memory
> checks.  execmem, execstack, execheap.  By default processes run as an
> unconfined domain can not allocate writeable memory and execute it.
> This is a common attack vector call buffer overflow attacks.  Some
> applications require this type of access (java, wine, mono and a few
> others). 
> 
>> Does this mean applications running in a Java Virtual Machine, and in Wine?
> 
>> I'll change my response below based on the answer to this.
Yes
> 
>> These applications need to be labeled correctly to allow the
> access.  There are booleans that can turn off this protection for the
> unconfined user unconfined_t.  allow_execmem, allow_execstack,
> allow_execheap.
> 
> You can turn the booleans on using setsebool
> 
> setsebool -P allow_execmem 1
> 
>> I will use these examples later on.
> 
> 
>> How about:
> 
>> Targeted policy is the default SELinux policy used in Fedora 10. When
>> using targeted policy, subjects that are targeted run in a confined
>> domain, and subjects that are not targeted run in an unconfined domain.
>> For example, by default, logged in users run in the unconfined_t domain,
>> and system processes started by init run in the initrc_t domain - both
>> of these domains are unconfined.
> 
>> Unconfined domains (as well as confined domains) are subject to
>> executable and writeable memory checks. By default, subjects running in
>> an unconfined domain can not allocate writeable memory and execute it.
> 
>> [I think I changed the meaning. Is it still correct? ]
Looks good
> 
>> This reduces vulnerability to buffer overflow attacks. Some subjects
>> require this access, including but not limited to Java", Wine and Mono.
>> To allow this access, these subjects must be labeled correctly.

For example, if you had a java application /usr/local/bin/myjavaapp,
that was not working because it needed the execmem access, you could
change the system labeling.
# semanage fcontext -a -t java_exec_t /usr/local/bin/myjavaapp
Then you fix the context on the actual file
# restorecon /usr/local/bin/myjavaapp

myjavaapp will now be allowed to run with execmem and execstack.

If you do not want to deal with any of the memory checks for users, you
can disable them with by setting the allow_exec* booleans.

# setsebool -P allow_execmem=1 allow_execstack=1 allow_execheap=1
You can check if the booleans current state by executing

getsebool -a | grep allow_exec

You system is most protected if these booleans are turned off.

# setsebool -P allow_execmem=0 allow_execstack=0 allow_execheap=0

>> memory checks need to be disabled for the users running in the
>> unconfined_t domain. 
No this sentence is wrong.
These memory checks are disable by setting
>> booleans, which allow the SELinux policy to be modified during runtime.
>> Configuring booleans is discussed later.
> 
> 


>>>> domain type. When a subject runs in the unconfined_t domain type,
> 
>>>> SELinux rules do not apply, and only DAC rules are used.
>>>>
>>>> Confined Subjects
>>>>
>>>> large number of subjects are protected, and are therefore confined by
> Greater then 200, subjects are not protected they are confined.  IE A
> subject could still be compromized but other processes on the system are
> protected from the confined process.
>>>> the SELinux targeted policy, including the Apache HTTP Server (httpd),
>>>> Samba (samba), FTP (vsftpd), Kerberos (krb5-server), ISC BIND (bind and
>>>> bind-chroot), NFS (nfs-utils), and NIS (ypserv). 
> This is an old RHEL4 list.  Almost every domain that listens to the
> internet is now confined.  And most processes that run as root and do
> stuff for users are confined.
> When a subject is
>>>> confined, it runs in its own domain type, such as the httpd subject
>>>> running in the httpd_t domain type. When a confined subject is
>>>> compromised by an attacker, the damage an attacker can do and the data
>>>> they can access is greatly limited.
> 
>> How about:
> 
>> Almost every subject that has network access is confined in Fedora 10.
>> Most subjects that run as the Linux root user and perform tasks for
>> users, such as the passwd application, are confined. 
DBUS/Hal are good examples also.
When a subject is
>> confined, it runs in its own domain, such as the httpd subject running
>> in the httpd_t domain. When a confined subject is compromised by an
>> attacker, depending on SELinux policy configuration, the attacker's
>> access is to resources and the possible damage they can do is limited.
> 
Good
>>>>
>>>> The following example demonstrates how SELinux prevents the Apache HTTP
>>>> Server (httpd) from reading files that are not correctly labeled, such
>>>> as files intended for use by another subject. This is an example, and
>>>> should not be used in production. It assumes that the httpd and wget
>>>> packages are installed, that the SELinux targeted policy is used, and
>>>> that SELinux is running in enforcing mode:
>>>>
>>>> 1. As the Linux root user, run the touch /var/www/html/testfile command.
>>>>
>>>> 2. Run the ls -Z /var/www/html/testfile command to view the SELinux
>>>> context:
>>>>
>>>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
>>>> /var/www/html/testfile
>>>>
> Make sure the machine is in enforcing mode, setenforce 1.
> 
>> I am adding more steps and example output.
> 
>>>> By default, Linux users run unconfined on Fedora 10, which is why the
>>>> testfile file object is labeled with the SELinux unconfined_u user. The
>>>> object_r role is a standard role, and does not affect access control.
>>>> The httpd_sys_content_t file type allows the httpd subject to access
>>>> this object.
>>>>
>>>> [ What is object_r really for? ]
> Not used on objects so it is just the default.
>>>> 3. As the Linux root user, start the Apache HTTP Server: /sbin/service
>>>> httpd start. When the server has started, change into a directory where
>>>> your Linux user has write access to, and run the wget
>>>> http://localhost/testfile command. Unless there are any changes to the
>>>> default configuration, this command succeeds.
>>>>
>>>> 4. The /usr/bin/chcon command relabels files; however, such label
>>>> changes do not survive when the file system is relabeled. For permanent
>>>> changes that survive a file system relabel, use the /usr/sbin/semanage
>>>> command, which is discussed later. As the Linux root user, run the
>>>> /usr/bin/chcon -t samba_share_t /var/www/html/testfile command to change
>>>> the file type, to a file type that is used by Samba. Run the ls -Z
>>>> /var/www/html/testfile command to verify the changes:
>>>>
>>>> [ If a file has an entry in file_contexts, and is relabeled with
>>>> semanage fcontext, does that update
>>>> /etc/selinux/targeted/contexts/files/file_contexts with the change? I
>>>> was going to try, but forgot how to change the file type with semanage]
>>>>
> Yes it will update /etc/selinux/targeted/contexts/files/file_contexts
>>>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
>>>> /var/www/html/testfile
>>>>
>>>> 5. Note: the current DAC permissions allow the httpd subject access to
>>>> this file. Change into a directory where your Linux user has write
>>>> access to, and run the wget http://localhost/testfile command. Unless
>>>> there are any changes to the default configuration, this command fails:
>>>>
>>>> HTTP request sent, awaiting response... 403 Forbidden
>>>> 2008-08-22 03:48:40 ERROR 403: Forbidden.
>>>>
>>>> This example demonstrates the additional security added by SELinux.
>>>> Although the httpd subject had access to the object in step 5, because
>>>> the object was labeled with a file type that httpd subject does not have
>>>> access to, SELinux denied access. After step 5, an error such as the
>>>> following is logged to /var/log/messages:
>>>>
>>>> Aug 22 03:48:40 localhost setroubleshoot: SELinux is preventing httpd
>>>> (httpd_t) "getattr"
>>>> to /var/www/html/testfile (samba_share_t). For complete SELinux
>>>> messages.
>>>> run sealert -l c05911d3-e680-4e42-8e36-fe2ab9f8e654
>>>>
> setroubleshoot requires audit subsystem to be running.
>>>> Also, if the audit package is installed and the auditd subject is
>>>> running, a more detailed denial is logged to /var/log/audit/audit.log.
>>>> These denials are discussed later.
>>>>
>>>> Unconfined Subjects
>>>>
>>>> Unconfined subjects run in the unconfined_t domain type. This means that
> Unconfined subjects run in the unconfined domain. This means that
>>>> SELinux policy rules do not apply, and only DAC permissions are used.
>>>> When an unconfined subject is comprised, an attacker may gain access to
>>>> a large number of system resources and data.
>>>>
> I think this would be better stated:
> 
> If an unconfined subject is compromized, SELinux will not prevent the
> attacker from gaining access to system resources and data, the system
> will still have DAC protection.
> 
>> How about:
> 
>> When an unconfined subject is comprised, SELinux does not prevent the
>> attacker from gaining access to system resources and data, and DAC rules
>> are used.
> 
>> (I should probably change these to "If an...")
> 
If an unconfined subject is comprised, SELinux does not prevent the
attacker from gaining access to system resources and data, of course DAC
rules are used.

Note: A common misconception about SELinux is that it replaces DAC
Controls, when it really just augments them.
> 
>>>> The following example demonstrates how the Apache HTTP Server (httpd)
>>>> can access data intended for use by another subject, when running
>>>> unconfined. Note: on Fedora 10, the httpd subject runs in the confined
>>>> httpd_t domain type by default. This is an example, and should not be
>>>> used in production. It assumes that the httpd and wget packages are
>>>> installed, that the SELinux targeted policy is used, and that SELinux is
>>>> running in enforcing mode:
>>>>
>>>> 1. As the Linux root user, run the touch /var/www/html/test2file
>>>> command.
>>>>
>>>> 2. Run the ls -Z /var/www/html/test2file command to view the SELinux
>>>> context:
>>>>
>>>> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
>>>> /var/www/html/test2file
>>>>
>>>> By default, Linux users run unconfined on Fedora 10, which is why the
>>>> test2file file object is labeled with the SELinux unconfined_u user. The
>>>> object_r role is a standard role, and does not affect access control.
>>>> The httpd_sys_content_t file type allows the httpd subject to access
>>>> this object.
>>>>
>>>> 3. The /usr/bin/chcon command relabels files; however, such label
>>>> changes do not survive when the file system is relabeled. For permanent
>>>> changes that survive a file system relabel, use the /usr/sbin/semanage
>>>> command, which is discussed later. As the Linux root user, run the
>>>> /usr/bin/chcon -t samba_share_t /var/www/html/test2file command to
>>>> change the file type, to a file type that is used by Samba. Run the ls
>>>> -Z /var/www/html/test2file command to verify the changes:
>>>>
>>>> -rw-r--r--  root root unconfined_u:object_r:samba_share_t:s0
>>>> /var/www/html/test2file
>>>>
>>>> 4. To simulate the httpd subject running unconfined, run the
>>>> /usr/sbin/setenforce 0 command as the Linux root user to temporarily
>>>> disable SELinux. Confirm SELinux is disabled by running the
>>>> /usr/sbin/getenforce command. When SELinux is disabled,
>>>> /usr/sbin/getenforce returns Permissive:
>>>>
>>>> $ getenforce
>>>> Permissive
>>>>
>>>> 5. As the Linux root user, start the Apache HTTP Server: /sbin/service
>>>> httpd start. Change into a directory where your Linux user has write
>>>> access to, and run the wget http://localhost/test2file command. Unless
>>>> there are any changes to the default configuration, this command
>>>> succeeds.
>>>>
>>>> 6. Enable SELinux by running /usr/sbin/setenforce 1 command. When
>>>> SELinux is enabled, /usr/sbin/getenforce returns Enforcing:
>>>>
>>>> $ getenforce
>>>> Enforcing
>>>>
>>>> The examples in these sections demonstrate how data can be protected
>>>> from a compromised confined-subject (protected by SELinux), as well as
>>>> how data is more accessible to an attacker from a compromised
>>>> unconfined-subject (not protected by SELinux).
>>>>
>>>> Confined and Unconfined User Domains
>>>>
>>>> In progress. Introduction to restrictions on certain domains (user_t,
>>>> guest_t etc).
>>>>
>>>> Are there any SELinux restrictions on what users can do when they run
>>>> unconfined?
>>>>
> See above,  Also there are booleans available to allow the transition to
>  a confined domain from the unconfined_t.  The one I would like to
> encourage is.
> 
> allow_unconfined_nsplugin_transition
> 
> Which will transition firefox plugins to a confined domain.
>>>> -- 
>>>> 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.
> 

> Thanks for your help.


--
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: "Targeted Policy" review

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]

On Fri, 2008-09-05 at 09:49 -0400, Daniel J Walsh wrote:
> Murray McAllister wrote:
> > Daniel J Walsh wrote:
> > Murray McAllister wrote:
> >>>> Hi,
> >>>>
> >>>> The following is a draft of the "Targeted Policy" sections for the
> >>>> SELinux User Guide. Any comments and corrections are appreciated.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> Targeted Policy
> >>>>
> >>>> Targeted policy is the default SELinux policy used in Fedora 10. When
> >>>> using targeted policy, subjects that are targeted run in their own
> >>>> domain type, and subjects that are not targeted run in the unconfined_t
> > confined domain, and subjects that are not targeted run in an unconfined
> > domain,  For example logged in users by default log in as unconfined_t
> > while system processes started by init run in initrc_t.  Both of these
> > domains are unconfined.
> > 
> > NOTE:
> > 
> > Even unconfined domains are subject to executable/writable memory
> > checks.  execmem, execstack, execheap.  By default processes run as an
> > unconfined domain can not allocate writeable memory and execute it.
> > This is a common attack vector call buffer overflow attacks.  Some
> > applications require this type of access (java, wine, mono and a few
> > others). 
> > 
> >> Does this mean applications running in a Java Virtual Machine, and in Wine?
> > 
> >> I'll change my response below based on the answer to this.
> Yes
> > 
> >> These applications need to be labeled correctly to allow the
> > access.  There are booleans that can turn off this protection for the
> > unconfined user unconfined_t.  allow_execmem, allow_execstack,
> > allow_execheap.
> > 
> > You can turn the booleans on using setsebool
> > 
> > setsebool -P allow_execmem 1
> > 
> >> I will use these examples later on.
> > 
> > 
And then there is text relocation

http://people.redhat.com/drepper/textrelocs.html
http://people.redhat.com/drepper/selinux-mem.html

/usr/sbin/semanage fcontext -l | grep execmem
/usr/sbin/semanage fcontext -l | grep textrel

> --
> 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.
-- 
Dominick Grift <domg472@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: user guide draft: "Targeted Policy" review

[Murray McAllister]

Daniel J Walsh wrote:
> Murray McAllister wrote:
>> Daniel J Walsh wrote:
>> Murray McAllister wrote:
>>>>> Hi,
>>>>>
>>>>> The following is a draft of the "Targeted Policy" sections for the
>>>>> SELinux User Guide. Any comments and corrections are appreciated.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Targeted Policy
>>>>>
>>>>> Targeted policy is the default SELinux policy used in Fedora 10. When
>>>>> using targeted policy, subjects that are targeted run in their own
>>>>> domain type, and subjects that are not targeted run in the unconfined_t
>> confined domain, and subjects that are not targeted run in an unconfined
>> domain,  For example logged in users by default log in as unconfined_t
>> while system processes started by init run in initrc_t.  Both of these
>> domains are unconfined.
>>
>> NOTE:
>>
>> Even unconfined domains are subject to executable/writable memory
>> checks.  execmem, execstack, execheap.  By default processes run as an
>> unconfined domain can not allocate writeable memory and execute it.
>> This is a common attack vector call buffer overflow attacks.  Some
>> applications require this type of access (java, wine, mono and a few
>> others). 
>>
>>> Does this mean applications running in a Java Virtual Machine, and in Wine?
>>> I'll change my response below based on the answer to this.
> Yes
>>> These applications need to be labeled correctly to allow the
>> access.  There are booleans that can turn off this protection for the
>> unconfined user unconfined_t.  allow_execmem, allow_execstack,
>> allow_execheap.
>>
>> You can turn the booleans on using setsebool
>>
>> setsebool -P allow_execmem 1
>>
>>> I will use these examples later on.
>>
>>> How about:
>>> Targeted policy is the default SELinux policy used in Fedora 10. When
>>> using targeted policy, subjects that are targeted run in a confined
>>> domain, and subjects that are not targeted run in an unconfined domain.
>>> For example, by default, logged in users run in the unconfined_t domain,
>>> and system processes started by init run in the initrc_t domain - both
>>> of these domains are unconfined.
>>> Unconfined domains (as well as confined domains) are subject to
>>> executable and writeable memory checks. By default, subjects running in
>>> an unconfined domain can not allocate writeable memory and execute it.
>>> [I think I changed the meaning. Is it still correct? ]
> Looks good
>>> This reduces vulnerability to buffer overflow attacks. Some subjects
>>> require this access, including but not limited to Java", Wine and Mono.
>>> To allow this access, these subjects must be labeled correctly.
> 
> For example, if you had a java application /usr/local/bin/myjavaapp,
> that was not working because it needed the execmem access, you could
> change the system labeling.
> # semanage fcontext -a -t java_exec_t /usr/local/bin/myjavaapp
> Then you fix the context on the actual file
> # restorecon /usr/local/bin/myjavaapp
> 
> myjavaapp will now be allowed to run with execmem and execstack.
> 
> If you do not want to deal with any of the memory checks for users, you
> can disable them with by setting the allow_exec* booleans.
> 
> # setsebool -P allow_execmem=1 allow_execstack=1 allow_execheap=1
> You can check if the booleans current state by executing
> 
> getsebool -a | grep allow_exec
> 
> You system is most protected if these booleans are turned off.
> 
> # setsebool -P allow_execmem=0 allow_execstack=0 allow_execheap=0
> 
>>> memory checks need to be disabled for the users running in the
>>> unconfined_t domain. 
> No this sentence is wrong.
> These memory checks are disable by setting
>>> booleans, which allow the SELinux policy to be modified during runtime.
>>> Configuring booleans is discussed later.
>>

I removed some bits to avoid too much theory:

Unconfined domains (as well as confined domains) are subject to 
executable and writeable memory checks. By default, subjects running in 
an unconfined domain can not allocate writeable memory and execute it. 
This reduces vulnerability to buffer overflow attacks. These memory 
checks are disable by setting booleans, which allow the SELinux policy 
to be modified during runtime. Configuring booleans is discussed later.

>>> How about:
>>> When an unconfined subject is comprised, SELinux does not prevent the
>>> attacker from gaining access to system resources and data, and DAC rules
>>> are used.
>>> (I should probably change these to "If an...")
> If an unconfined subject is comprised, SELinux does not prevent the
> attacker from gaining access to system resources and data, of course DAC
> rules are used.
> 
> Note: A common misconception about SELinux is that it replaces DAC
> Controls, when it really just augments them.

How about:

If an unconfined subject is compromised, SELinux does not prevent the 
attacker from gaining access to system resources and data, but of 
course, DAC rules are still used. SELinux is a security enhancement on 
top of DAC rules - it does not replace them.

--
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: "Targeted Policy" review

[Daniel J Walsh]

Murray McAllister wrote:
> Daniel J Walsh wrote:
>> Murray McAllister wrote:
>>> Daniel J Walsh wrote:
>>> Murray McAllister wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The following is a draft of the "Targeted Policy" sections for the
>>>>>> SELinux User Guide. Any comments and corrections are appreciated.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Targeted Policy
>>>>>>
>>>>>> Targeted policy is the default SELinux policy used in Fedora 10. When
>>>>>> using targeted policy, subjects that are targeted run in their own
>>>>>> domain type, and subjects that are not targeted run in the
>>>>>> unconfined_t
>>> confined domain, and subjects that are not targeted run in an unconfined
>>> domain,  For example logged in users by default log in as unconfined_t
>>> while system processes started by init run in initrc_t.  Both of these
>>> domains are unconfined.
>>>
>>> NOTE:
>>>
>>> Even unconfined domains are subject to executable/writable memory
>>> checks.  execmem, execstack, execheap.  By default processes run as an
>>> unconfined domain can not allocate writeable memory and execute it.
>>> This is a common attack vector call buffer overflow attacks.  Some
>>> applications require this type of access (java, wine, mono and a few
>>> others).
>>>> Does this mean applications running in a Java Virtual Machine, and
>>>> in Wine?
>>>> I'll change my response below based on the answer to this.
>> Yes
>>>> These applications need to be labeled correctly to allow the
>>> access.  There are booleans that can turn off this protection for the
>>> unconfined user unconfined_t.  allow_execmem, allow_execstack,
>>> allow_execheap.
>>>
>>> You can turn the booleans on using setsebool
>>>
>>> setsebool -P allow_execmem 1
>>>
>>>> I will use these examples later on.
>>>
>>>> How about:
>>>> Targeted policy is the default SELinux policy used in Fedora 10. When
>>>> using targeted policy, subjects that are targeted run in a confined
>>>> domain, and subjects that are not targeted run in an unconfined domain.
>>>> For example, by default, logged in users run in the unconfined_t
>>>> domain,
>>>> and system processes started by init run in the initrc_t domain - both
>>>> of these domains are unconfined.
>>>> Unconfined domains (as well as confined domains) are subject to
>>>> executable and writeable memory checks. By default, subjects running in
>>>> an unconfined domain can not allocate writeable memory and execute it.
>>>> [I think I changed the meaning. Is it still correct? ]
>> Looks good
>>>> This reduces vulnerability to buffer overflow attacks. Some subjects
>>>> require this access, including but not limited to Java", Wine and Mono.
>>>> To allow this access, these subjects must be labeled correctly.
>>
>> For example, if you had a java application /usr/local/bin/myjavaapp,
>> that was not working because it needed the execmem access, you could
>> change the system labeling.
>> # semanage fcontext -a -t java_exec_t /usr/local/bin/myjavaapp
>> Then you fix the context on the actual file
>> # restorecon /usr/local/bin/myjavaapp
>>
>> myjavaapp will now be allowed to run with execmem and execstack.
>>
>> If you do not want to deal with any of the memory checks for users, you
>> can disable them with by setting the allow_exec* booleans.
>>
>> # setsebool -P allow_execmem=1 allow_execstack=1 allow_execheap=1
>> You can check if the booleans current state by executing
>>
>> getsebool -a | grep allow_exec
>>
>> You system is most protected if these booleans are turned off.
>>
>> # setsebool -P allow_execmem=0 allow_execstack=0 allow_execheap=0
>>
>>>> memory checks need to be disabled for the users running in the
>>>> unconfined_t domain. 
>> No this sentence is wrong.
>> These memory checks are disable by setting
>>>> booleans, which allow the SELinux policy to be modified during runtime.
>>>> Configuring booleans is discussed later.
>>>
> 
> I removed some bits to avoid too much theory:
> 
> Unconfined domains (as well as confined domains) are subject to
> executable and writeable memory checks. By default, subjects running in
> an unconfined domain can not allocate writeable memory and execute it.
> This reduces vulnerability to buffer overflow attacks. These memory
> checks are disable by setting booleans, which allow the SELinux policy
> to be modified during runtime. Configuring booleans is discussed later.
> 
>>>> How about:
>>>> When an unconfined subject is comprised, SELinux does not prevent the
>>>> attacker from gaining access to system resources and data, and DAC
>>>> rules
>>>> are used.
>>>> (I should probably change these to "If an...")
>> If an unconfined subject is comprised, SELinux does not prevent the
>> attacker from gaining access to system resources and data, of course DAC
>> rules are used.
>>
>> Note: A common misconception about SELinux is that it replaces DAC
>> Controls, when it really just augments them.
> 
> How about:
> 
> If an unconfined subject is compromised, SELinux does not prevent the
> attacker from gaining access to system resources and data, but of
> course, DAC rules are still used. SELinux is a security enhancement on
> top of DAC rules - it does not replace them.
Looks good.

--
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: "Targeted Policy" review

[Murray McAllister]

Daniel J Walsh wrote:
> Stephen Smalley wrote:
>> As a reminder, users will derive the most benefit from actual practical
>> HOWTO-style guidance you can give them on how to use SELinux and deal
>> with issues that arise, not from a redux of introductory material on
>> what SELinux is.
>>
> I agree, Most people are not looking into what SELinux does, but how do
> I make my system work without needing to disable SELinux
> 
> I believe conveying information like the following is critical.
> 
> http://danwalsh.livejournal.com/22347.html

Yes, I do not want to spend any more time on the intro, as I'm wasting 
everyone's time with it now.

I tried to include an intro because someone mentioned expanding the 
guide to include policy writing, so I wrongly assumed an intro to 
selinux would make that easier.

Let me know if you want anything removed.

--
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: "Targeted Policy" review

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
On
> Behalf Of Dominick Grift
> Sent: Wednesday, September 03, 2008 2:25 AM
> To: Murray McAllister
> Cc: SE Linux
> Subject: Re: user guide draft: "Targeted Policy" review
> 
> On Wed, 2008-09-03 at 17:41 +1000, Murray McAllister wrote:
> > Hi,
> 
> > Are there any SELinux restrictions on what users can do when they
run
> > unconfined?
> 
> Yes i think unconfined users cannot do execmem, execstack, execheap by
> default.
> Otherwise they're exempted from policy enforcement i think.

In RHEL5, constraints still apply to applications running in the
unconfined_t domain, so all the MLS constraints apply. I'm not familiar
with Fedora 10, so it may be different.

> 
> --
> Dominick Grift <domg472@gmail.com>



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