From Fedora Project Wiki
(→‎Feedback and Suggestions: adding "dependencies and selinux-policy by domg472" notes...)
m (add cat)
 
(6 intermediate revisions by one other user not shown)
Line 5: Line 5:
* Is SELinux enabled by default on Debian? If not, link to appropriate information (<http://wiki.debian.org/SELinux>)
* Is SELinux enabled by default on Debian? If not, link to appropriate information (<http://wiki.debian.org/SELinux>)
* Is <code>system_u:object_r:httpd_sys_content_t</code> required for all SugarCRM files?
* Is <code>system_u:object_r:httpd_sys_content_t</code> required for all SugarCRM files?
* A section on setroubleshoot.
* SELinux open permission: <http://james-morris.livejournal.com/31714.html>
* Can users control where SELinux logs are written to?


Suggestions from domg472:
[[Category:SELinux docs]]
<pre>
Basic access control models ( DAC , MAC ) ( not so basic MDAC )
 
 
 
explain discretionary
 
explain the dac model attributes: user group permission bits
 
explain why dac acl is not sufficient. example privilege escalation
 
explain the mac model attributes: security context
 
explain mandatory
 
explain that MAC is ACL layer on top of the DAC ACL layer
 
explain Type enforcement
 
explain Role Based AC
 
explain Multi Level Security
 
Explain Multi Category/Compartment Security
 
 
 
compare a selinux system to a submarine with compartments. if one compartment has a leak,
the water will be contained to that compartment and will not be able to spread ( escalate) . submarine will not sink
 
 
 
Security context / SELinux attributes
 
 
 
explain the security context tuple and how to read it (explain the fields)
 
explain user ( which SELinux user (group) created the object? )
 
explain type is the attribute for type enforcement (TE)
 
explain role is the attribute for role enforcement (RBAC)
 
explain security level is the attribute for security level enforcement (MLS)
 
explain categories/compartments is the attribute for security level enforcement or category/compartment enforcement (MLS or MCS)
 
 
 
Subjects and objects ( processes and "files" )
 
 
 
explain that everything in a system is a object
 
explain that even subjects in a system are represented as objects in proc mountpoint
 
explain subjects and objects
 
explain subjects are processes (ps auxZ)
 
explain objects are "files" (ls -alZ)
 
- file objects ( files , lnk files, dirs, fifo files, sock files etc)
 
- port objects
 
- interface objects
 
- node objects
 
- objects available by other programs ACE access control extension: XACE, sepostgesql, SEDBUS, mscd, etc.
 
- explain object is a class defined in kernel :process :file :tcp_socket
 
example of a class: process. example of a class: file
 
explain domain type is the attribute of a process ( user_t is (user) domain type/attribute of "user"
 
explain object type is the attribute of a object or "file". do not mistake files with file objects/file types. a "file" is
any object
 
explain that a object type can never be a scontext ( source context ) in a avc denail
 
explain that processes (subjects) generally operate on files (objects)
 
explain that processes (subjects) also operate on other processes (subjects) example: process ( sigchld ) if a user
processes spawns a program process.
 
explain that "files" ( objects ) do not operate. they get operated on by subjects ( processes )
 
explain permissions that define how to operate on subjects and objects ( classes ) are defined in the kernel and are attributes of classes
 
explain classes and their attributes are static defined in kernel:
 
- example of a file object class and its attributes:
 
+ file read
 
+ dir write
 
+ lnk_file getattr
 
- example of a subject class and its attributes:
 
+ process sigchld
 
- example of a object available by other programs ACL
 
+ dbus send_msg
 
explain that although classes and their attributes are defined in the kernel, that one can assign "types" to
subjects and objects, and that one can define policy for these types can interact using the object classes
and their attributes supplied by the kernel.
 
 
 
example:
 
 
 
scontext/domain type/subject  |  tcontext/file type/object  |  "object" class      |  "object" permissions/attributes
 
___________________________________________________________________________________________________________________________
 
user_t                        |  user_home_t                |  dir                |  getattr
 
httpd_t                      |  httpd_sys_content_ra_t      |  file                |  read
 
user_t                        |  mozilla_t                  |  process            |  sigchld
 
user_t                        |  self                        |  process            |  transition
 
mozilla_t                    |  httpd_port_t                |  tcp_socket          |  connect
 
unconfined_t                  |  cupsd_t                    |  dbus                |  send_msg
 
 
 
 
 
How to find out if selinux is supported /enabled:
 
supported?: http://domg444.blogspot.com/2007/11/how-to-determine-if-our-system-supports.html
 
enabled?: getenforce /selinux/config sestatus
 
 
 
explain selinux framework and selinux policy. explain the selinux framework is responsible for enforcing policy.
 
explain the access vector cache.
 
perruse selinux packages ( rpm -ql ) and discuss important locations : /etc/selinux , /selinux
 
 
 
How to disable SELinux: i refer to dwalsh blog. some highlights selinux=0 , enforcing=0, setenforce 0,
system-config-selinux, semanage
 
 
 
system-config-selinux is a GUI for semanage. semanage is THE central managing point for SELinux administration:
 
label file objects ( semanage fcontect -a)
 
label port objects ( semanage port -a) etc
 
explain each optipn of semanage and system-config-selinux: label interfaces, set booleans, add , modify, delete selinux user (groups) and SELinux logins.
 
explain translation ( requires mcstransd )
 
explain what mcstransd does
 
explain what restorecond does
 
explain auditd connection to selinux ( explain ausearch /auctl )
 
 
 
show some pratical examples for managing users. add a unconfined user , add a confined user ,
add a staff users, assign mcs categories to user (ranges)
 
create custom selinux user groups
 
create custom selinux logins
 
 
 
explain booleans
 
explain customizable types
 
mention manual pages for targeted daemons.
 
 
 
explain audit2allow
 
explain audit2why
 
explain sesearch and how you can use this to make decisions
 
explain semodule, sestatus , restorecon , semanage, setenforce , getenforce
 
explain limitations of chcon
 
explain advantage of chcon
 
explain chcat
 
 
 
explain selinux-policy-devel ( /usr/share/selinux/devel/Makefile )
 
show example how to make a custom policy module
 
explain the limitations of a policy module package
 
explain the advantages of a policy module package
 
 
 
explain role base access control and derrived types.
 
 
 
explain star and selinux tar support (exmaples)
 
 
 
important: Possible problems caused from running in permissive mode, such as having permissions to mislabel files.
 
important: Copying Vs moving files.
 
 
 
explain avc denials field by field.
 
explain advantage and limitation of sealert/setroublehoot and how this relates to audit.
 
 
 
explain file_t, unlabeled_t
 
explain initrc_t
 
explain unconfined_t
 
explain sepolgen and gui
 
 
 
explain why /tmp will not be relabled: http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html
 
 
 
read selinux by example book
 
 
 
explain the MLS vs TARGETED
 
explain mcs role in targetted versus mcs role in mls
</pre>
 
dependencies and selinux-policy by domg472:
<pre>
SELinux policy and dependencies.
 
A policy module has 3 files. Here is the explaination of the 3 files.
 
mydomain.te (.te) (type enforcement file) it has PRIVATE policy for the "mydomain" policy module.
 
mydomain.if (.if) (interface file) it has PUBLIC policy for the "mydomain" policy module.
 
mydomain.fc (.fc) (file context file) it has file contexts for the "mydomain" policy module.
 
The type enforcement file.
 
This file has private policy. Policy that is, in my example, related to "mydomain"
 
for example, you might find a rule like this in the mydomain.te file:
apache_read_user_content(mydomain_t)
 
This policy was provided by apache.if to "mydomain". You can look it up in the apache.if file.
It is really a template or interface with rules for how to read apaches user content.
We are using (instantiating) that interface that apache policy module provides in it's
apache.if file, in our mydomain.te file.
 
Let us refer to interfaces and templates as blocks of public policy. Public policy blocks
should be prefixed by the policy module name of the domain that facilitates it in it's .if (interface file).
 
for example, just by looking at the following interface call in mydomain.te i know:
1. which module provided the interface 2. where to roughly find it. 3. where to find what
policy te interface provides. 4. which domain instantiates the block of public policy:
 
alsa_read_rw_config(mydomain_t)
 
1. provided by the alsa policy module.
2. can be found in alsa.if
3. Summary: Read alsa writable config files
 
allow $1 alsa_etc_rw_t:dir list_dir_perms;
read_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
read_lnk_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
 
4. this policy is instantiated by mydomain_t domain.
 
So you can easily from looking at a .te file know the modules dependencies by
parsing each called interface prefix. as each called interface is prefixed by the domain
that made it available in its interface file.
 
important note regarding public policy.
 
creating a quick policy module package(.pp) can be very handy for implementing
quick policy. but it is also limited.
 
to compile policy one need selinux-devel. it has development files for each module that
is used by the compiler to see if the policy that we want to compile is valid.
 
when you compile and install a seperate policy package with semodule -i mydomain.pp for example.
there will not be a devel package installed.
 
interfaces files are therefore rendered useless for seperate policy module packages. for the
reason that other modules will not be able too instantiate any public policy for that  module.
 
the reason is that when you try to compile your module that has a call to a public policy block
of a module that was installed with semodule, the compiler will nnot find that interface/ template
in its devel files because non were installed!
 
This is important to know!
do you want to develop and implement much policy, then do not use policy module packages with
semodule but instead integrate your module into the selinux-policy source provided upstream,
rebuild it and reinstall it.
 
by rebuilding selinux-policy, a new selinux-policy-devel package is created. this selinux-policy-devel
package DOES include the public policy for the domain that you integrated and thus is usable as
opposed to using a .pp with semodule.
 
<http://domg472.blogspot.com/2008/05/how-to-create-integrate-and-rebuild.html>

Latest revision as of 00:47, 28 February 2009

Feedback and Suggestions

Feel free to add any suggestions or corrections here. Thanks :)