user guide drafts: "Linux Permissions" and "Manual Pages for Services"

user guide drafts: "Linux Permissions" and "Manual Pages for Services"

[Murray McAllister]

Hi,

The following are drafts for the "Fixing Problems"[1] section. Any 
comments and corrections are appreciated.

Linux Permissions

When access is denied, check standard Linux permissions. As mentioned in 
Chapter 2, Introduction, most operating systems use a Discretionary 
Access Control (DAC) system to control access, allowing users to control 
the permissions of files that they own. SELinux policy rules are checked 
after DAC rules. SELinux policy rules are not used if DAC rules deny 
access first.

If access is denied and no SELinux denials are logged, use the ls -l 
command to view the standard Linux permissions:

[example output]

In this example, index.html is owned by the root user and group. The 
root user has read and write permissions (-rw), and members of the root 
group have read permissions (-r-). Everyone else has no access (---). By 
default, such permissions do not allow httpd to read this file. To 
resolve this issue, use the chown command to change the owner and group. 
This command must be run as the Linux root user:

# chown apache:apache /var/www/html/index.html

This assumes the default configuration, in which httpd runs as the Linux 
apache user. If you run httpd with a different user, replace 
apache:apache with that user.

Refer to the Fedora Documentation Project "Permissions"[2] draft for 
information about managing Linux permissions.

Manual Pages for Services

Manual pages for services contain valuable information, such as what 
file type to use for a given situation, and Booleans to change the 
access a service has (such as httpd accessing NFS file systems). This 
information may be in the standard manual page, or a manual page with 
selinux prepended or appended.

For example, the httpd_selinux(8) manual page has information about what 
file type to use for a given situation, as well as Booleans to allow 
scripts, sharing files, accessing directories inside user home 
directories, and so on. Other manual pages with SELinux information for 
services include:

* Samba: the samba_selinux(8) manual page describes that files and 
directories to be exported via Samba must be labeled with the 
samba_share_t type, as well as Booleans to allow files labeled with 
types other than samba_share_t to be exported via Samba.

* NFS: the nfs_selinux(8) manual page describes that, by default, file 
systems can not be exported via NFS, and that to allow file systems to 
be exported, Booleans such as nfs_export_all_ro or nfs_export_all_rw 
must be turned on.

* Berkeley Internet Name Domain (BIND): the named(8) manual page 
describes what file type to use for a given situation (see the Red Hat 
SELinux BIND Security Profile section). The named_selinux(8) manual page 
describes that, by default, named can not write to master zone files, 
and to allow such access, the named_write_master_zones Boolean must be 
turned on.

The information in manual pages helps you configure the correct file 
types and Booleans, helping to prevent SELinux from denying access.

Cheers.

[1] 7.3. Fixing Problems

     7.3.1. Linux Permissions
     7.3.2. Manual Pages for Services
     7.3.3. Permissive Domains
     7.3.4. Searching For and Viewing Denials
     7.3.5. Raw Audit Messages
     7.3.6. sealert Messages
     7.3.7. audit2allow
(I have not sent Permissive Domains or audit2allow to the list yet)

[2] 
<http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide/Permissions>

--
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 drafts: "Linux Permissions" and "Manual Pages for Services"

[Stephen Smalley]

On Wed, 2008-11-12 at 11:49 +1000, Murray McAllister wrote:
> Hi,
> 
> The following are drafts for the "Fixing Problems"[1] section. Any 
> comments and corrections are appreciated.
> 
> Linux Permissions
> 
> When access is denied, check standard Linux permissions. As mentioned in 
> Chapter 2, Introduction, most operating systems use a Discretionary 
> Access Control (DAC) system to control access, allowing users to control 
> the permissions of files that they own. SELinux policy rules are checked 
> after DAC rules. SELinux policy rules are not used if DAC rules deny 
> access first.
> 
> If access is denied and no SELinux denials are logged,

Logically you would also mention the dontaudit case here, and how to
check for denials hidden by dontaudit rules.

-- 
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 drafts: "Linux Permissions" and "Manual Pages for Services"

[Murray McAllister]

Stephen Smalley wrote:
> On Wed, 2008-11-12 at 11:49 +1000, Murray McAllister wrote:
>> Hi,
>>
>> The following are drafts for the "Fixing Problems"[1] section. Any 
>> comments and corrections are appreciated.
>>
>> Linux Permissions
>>
>> When access is denied, check standard Linux permissions. As mentioned in 
>> Chapter 2, Introduction, most operating systems use a Discretionary 
>> Access Control (DAC) system to control access, allowing users to control 
>> the permissions of files that they own. SELinux policy rules are checked 
>> after DAC rules. SELinux policy rules are not used if DAC rules deny 
>> access first.
>>
>> If access is denied and no SELinux denials are logged,
> 
> Logically you would also mention the dontaudit case here, and how to
> check for denials hidden by dontaudit rules.
> 
How about (keeping in mind I have not really heard of this before):

dontaudit Rules and Linux Permissions

Bugs in applications may cause a lot of SELinux denials, but such 
denials may not prevent the application from running correctly. For 
these situations, dontaudit rules can be added to policy to prevent log 
files being filled with denial messages. The downside of this is that, 
although SELinux denies access, denial messages are not logged, making 
troubleshooting hard.

To temporarily disable dontaudit rules, allowing all denials to be 
logged, run the following command as the Linux root user:

/usr/sbin/semodule -DB

The -D option disables dontaudit rules; the -B option rebuilds policy. 
The dontaudit rules are disabled until policy is rebuilt. To rebuild 
policy and enable dontaudit rules, run the following command as the 
Linux root user:

/usr/sbin/semodule -B
For a full list of dontaudit rules, run the sesearch --dontaudit 
command. Narrow down searches using the -s domain option and the grep 
command. For example:

[output from "sesearch --dontaudit -s smbd_t | grep squid
"]

Refer to Section 7.3.5, “Raw Audit Messages” and Section 7.3.6, “sealert 
Messages” for information about analyzing denials.

After resolving any issues found by removing dontaudit rules, or if 
disabling these rules did not produce denials for your situation, check 
standard Linux permissions. [rest of Linux Permissions content].

Thanks.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user guide drafts: "Linux Permissions" and "Manual Pages for Services"

[Stephen Smalley]

On Thu, 2008-11-13 at 15:11 +1000, Murray McAllister wrote:
> Stephen Smalley wrote:
> > On Wed, 2008-11-12 at 11:49 +1000, Murray McAllister wrote:
> >> Hi,
> >>
> >> The following are drafts for the "Fixing Problems"[1] section. Any 
> >> comments and corrections are appreciated.
> >>
> >> Linux Permissions
> >>
> >> When access is denied, check standard Linux permissions. As mentioned in 
> >> Chapter 2, Introduction, most operating systems use a Discretionary 
> >> Access Control (DAC) system to control access, allowing users to control 
> >> the permissions of files that they own. SELinux policy rules are checked 
> >> after DAC rules. SELinux policy rules are not used if DAC rules deny 
> >> access first.
> >>
> >> If access is denied and no SELinux denials are logged,
> > 
> > Logically you would also mention the dontaudit case here, and how to
> > check for denials hidden by dontaudit rules.
> > 
> How about (keeping in mind I have not really heard of this before):
> 
> dontaudit Rules and Linux Permissions

"Possible Causes of Silent Denials"

> Bugs in applications may cause a lot of SELinux denials, but such 
> denials may not prevent the application from running correctly.

"Applications and system library functions will often probe for access
beyond what they require in order to perform their task.  In order to
maintain least privilege without filling the audit logs with avc denials
from harmless application probing, the policy can silence avc denials
without allowing a permission by using a dontaudit rule.  Such dontaudit
rules are common in the standard policy based on experience with
applications."

>  For 
> these situations, dontaudit rules can be added to policy to prevent log 
> files being filled with denial messages. The downside of this is that, 
> although SELinux denies access, denial messages are not logged, making 
> troubleshooting hard.
> 
> To temporarily disable dontaudit rules, allowing all denials to be 
> logged, run the following command as the Linux root user:
> 
> /usr/sbin/semodule -DB
> 
> The -D option disables dontaudit rules; the -B option rebuilds policy. 
> The dontaudit rules are disabled until policy is rebuilt.

"After running semodule -DB, you can try again to exercise the
application that was encountering a permission denial and see whether
any SELinux denials are reported that are relevant to the application.
Care must be taken in deciding which of these denials should be allowed,
as some should in fact be ignored and handled via dontaudit rules."


>  To rebuild 
> policy and enable dontaudit rules, run the following command as the 
> Linux root user:
> 
> /usr/sbin/semodule -B

"This will restore the policy to its original state."

> For a full list of dontaudit rules, run the sesearch --dontaudit 
> command. Narrow down searches using the -s domain option and the grep 
> command. For example:
> 
> [output from "sesearch --dontaudit -s smbd_t | grep squid
> "]
>
> Refer to Section 7.3.5, “Raw Audit Messages” and Section 7.3.6, “sealert 
> Messages” for information about analyzing denials.
> 
> After resolving any issues found by removing dontaudit rules, or if 
> disabling these rules did not produce denials for your situation, check 
> standard Linux permissions. [rest of Linux Permissions content].
> 
> Thanks.
-- 
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.