From Fedora Project Wiki
mNo edit summary
Line 18: Line 18:


[[Docs/Drafts/SELinx User Guide/SELinux Content Specification/Working with SELinux| Working with SELinux]]
[[Docs/Drafts/SELinx User Guide/SELinux Content Specification/Working with SELinux| Working with SELinux]]
== Access Control ==
Describe the concepts of the following, using <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/selg-overview.html> as a guide:
* Discretionary Access Control (DAC)
* Mandatory Access Control (MAC)
* Multi-Level Security (MLS)
* Mutli-Category Security (MCS)
* Type Enforcement (TE)
* Role Based Access Control (RBAC)
SELinux rules are not checked if DAC rules deny access.
RBAC: Roles are associated with domain types, and domain types are associated with SELinux users. When not taking domain transition into account, roles do not restrict access between subjects and objects, but limit which SELinux users can exist and transition to which domains. For example, domain transition fails if the SELinux user and the new domain type are not allowed to exist in the security context that is created after a domain transition occurs. Roles are important when writing policies, but do not restrict access per se, and as such, are not discussed in detail in this guide.


== Targeted Policy Overview ==
== Targeted Policy Overview ==
Line 69: Line 52:
** Admin User Account - staff_t
** Admin User Account - staff_t
** Unconfined User - Unconfined_t
** Unconfined User - Unconfined_t
== Access Control ==
Describe the concepts of the following, using <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/selg-overview.html> as a guide:
* Discretionary Access Control (DAC)
* Mandatory Access Control (MAC)
* Multi-Level Security (MLS)
* Mutli-Category Security (MCS)
* Type Enforcement (TE)
* Role Based Access Control (RBAC)
SELinux rules are not checked if DAC rules deny access.
RBAC: Roles are associated with domain types, and domain types are associated with SELinux users. When not taking domain transition into account, roles do not restrict access between subjects and objects, but limit which SELinux users can exist and transition to which domains. For example, domain transition fails if the SELinux user and the new domain type are not allowed to exist in the security context that is created after a domain transition occurs. Roles are important when writing policies, but do not restrict access per se, and as such, are not discussed in detail in this guide.

Revision as of 23:35, 13 August 2008

Content Specification (Draft-only)

SELinux Introduction

SELinux Basics

Someone suggested having a section, that detailed if you are not going to do anything else with SELinux, then at least do these 3-4 things...

SELinux Contexts and Attributes

SELinux Contexts and Attributes

Subjects and Objects

Subjects and Objects

Working with SELinux

Working with SELinux

Targeted Policy Overview

  • Confined and unconfined processes. Explain unconfined.
  • Confined System Domains
    • httpd - apache
  man httpd_selinux
    • samba
  man samba_selinux
    • ftp
  man ftpd_selinux      
    • rsync
  man rsync_selinux 
    • kerberos
  man kerberos_selinux  
    • named
  man named_selinux       
    • nfs
  man nfs_selinux     
    • nis
  man nis_selinux  
    • ypbind
  man ypbind_selinux

...

  • Confined user domains
    • Minimal login user - guest_t
    • Minimal X-Windows Login User -xguest_t
    • Standard User Account - user_t
    • Admin User Account - staff_t
    • Unconfined User - Unconfined_t

Access Control

Describe the concepts of the following, using <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/selg-overview.html> as a guide:

  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Multi-Level Security (MLS)
  • Mutli-Category Security (MCS)
  • Type Enforcement (TE)
  • Role Based Access Control (RBAC)

SELinux rules are not checked if DAC rules deny access.

RBAC: Roles are associated with domain types, and domain types are associated with SELinux users. When not taking domain transition into account, roles do not restrict access between subjects and objects, but limit which SELinux users can exist and transition to which domains. For example, domain transition fails if the SELinux user and the new domain type are not allowed to exist in the security context that is created after a domain transition occurs. Roles are important when writing policies, but do not restrict access per se, and as such, are not discussed in detail in this guide.