From Fedora Project Wiki

< Docs‎ | Drafts‎ | SELinux User Guide
Revision as of 22:06, 20 July 2008 by Mdious (talk | contribs) (→‎Feedback and Suggestions: feedback from Max! :D)

Feedback and Suggestions

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

  • Is SELinux enabled by default on Debian? If not, link to appropriate information (<http://wiki.debian.org/SELinux>)
  • Is system_u:object_r:httpd_sys_content_t required for all SugarCRM files?
(07:46:36 AM) domg472: chcon is not good
(07:46:51 AM) domg472: if you have access to semanage use semanage
(07:47:00 AM) domg472: it is persistent
(07:47:17 AM) domg472: after relabel it will be still there
(07:47:26 AM) domg472: unlike chcons
(07:47:37 AM) domg472: chcon is for unprivileged users

Wiki feedback from domg472: 

Explain newrole versus sudo to: transition user domain.

in f10 selinux-policy-targeted newrole is no longer encouraged to be used for domain transitions.
 in policy mls it is still used (but mls is not common)

sudo allows root privileges without actually knowing the root password.

su with newrole still requires a user to enter a root password to gain root privileges.

not needing a root password anymore is a big advantage! 

---

from the wiki:
SELinux and virtualization (relabeling images if images are not in /etc/xen/). 

this is not a domain specific issue. customized types. the solution should be man virt_selinux 
or man xen_selinux like man httpd_selinux. however there is no man xen_selinux yet etc.
this may no longer be an issue in fedora 10 , virt is working on a solution to be implemented in f10

---

make sure to use proper selinux terminology consequent  in an effort to keep it simple.

subject object, security context, domain types, file types, port types, security level, categories, 
domain transition, executable file types, domain, application domain, user domain, init daemon, 
classes, attributes, scontext, tcontext, access vector cache, type enforcement, multi level security, 
multi category security. 

---

from the wiki:
Mounting:

• Do mount points need to be mnt_t? 

boolean mount_any_file. this is also kind of a customized type issue. 
use semanage boolean -l to list all booleans and their explanation. for example:

/usr/sbin/semanage boolean -l | grep mount

sh-3.2# /usr/sbin/semanage boolean -l | grep mount
allow_mount_anyfile            -> off   Allow the mount command to mount 
                                        any directory or file.
xguest_mount_media             -> off   Allow xguest users to mount removable media

consideration: you should consider to not mention get,setsebool. 
semanage also provides this functionality. keep it simple

---

from the wiki:
mislabeled files, relabeled but still problems, touch /.autorelabel (Dans journal). 
aplain how touch /.autorelabel && reboot relates to fixfiles relabel

---

different policies:
first there was strict and optional mls (for dod). strict was in fedora2. it was 
introduced too soon. users were too restricted. targeted was introduced to avoid 
restriction on users.unconfined domain is a domain exempted fro m most selinux policy. 
unconfined is a property of targeted policy. targeted policy only targets a select group. 
strict targets everything on a system. targeted plus multi category security (mcs) which
 is a (poor) implementation of confidentiality(its discretionary users can chcat aslong 
as they are member of the cat. mcs  in policy mls is part of security level. in policy 
mls, mcs is mandatory.mls is strict plus BLP, plus MCS, plus MLS. strict no longer 
maintained, merged with targeted. (strict plus unconfined domain) if you remove the 
unconfined domain then you use what use to be strict. at the moment there are two 
selinux policy models maintained: policy targeted and policy-mls. mls aims to enforces confidentiality BLP.

Suggestions from domg472: 

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

dependencies and selinux-policy by domg472: 

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>

From Max: 

Murray McAllister wrote:

>
> There are a few SELinux books, but these are very technical. We want to create a guide 
>that people with no previous SELinux experience can use, to allow them to do what they 
>want without turning SELinux off.
>

>
> If anyone has any ideas about what they would like to see in the guide, or 
>any corrections to the current topics we would like to include, please let us know. 
>As well, user feedback and comments can be left at 
><https://fedoraproject.org/wiki/Docs/Drafts/SELinux_User_Guide/SELinux_Feedback>. 
A Fedora account >(https://admin.fedoraproject.org/accounts/) is required to use the Wiki - 
>if you do not have one, please do not hesitate to mail me directly, or respond to this thread.
>

Here are a few ideas with comments in no particular order:

0 - *Reference material* - Not something many will probably dive into but necessary for completeness. 
Just some links to other sources of info. Like the IBM page :

> http://www.ibm.com/developerworks/linux/library/l-selinux/?ca=dgr-lnxw01SELinux

Even if there is no link directly to this page a small *Further Info* section like the Resources 
section at the bottom would still be useful, links to papers and web pages that can explain 
things in more detail if anyone is interested in finding out more of the nuts and bolts stuff.

Also perhaps links to any threads in the mailing list archives that help explain some of the concepts, 
these might be sprinkled about so they end up in relevant places. So if the section is about TE rules 
and there is a thread in the archives that was particularly good at explaining this or covers some key 
points then drop a link to the relevant thread there as additional reference or draw useful examples 
from the archives to use in explaining things. Showing how a real world problem was solved step by 
step has more impact than using myapp_t.

1 - *What SELinux isn't* - not an antivirus, will not fix vulnerabilities,  etc ....Maybe slip 
in a few lines explaining the concept of default permit and why this is a bad idea. *No such 
thing as a free lunch*. Which leads to the concept of default deny and....

2 - *What is SELinux and why should I care* - MAC system uses type enforcement to confine 
applications.....default deny. Everything that is to be allowed must be expressed in policy. 
Policy is complex because the system is complex. Typical usage of SELinux, the apache example
 would fit well in this section. What the goal of refpolicy is, where it is , where its going. 
Its not called reference policy for nothing, use as a building block.

3 - *Explain unconfined*. For instance going through the archives I found this little tidbit :


> Allowing unconfined_t to do things is ok; it is supposed to be unrestricted 
(and usually this happens automatically when you use the right type attributes 
on any new types you define, like the "file_type" attribute for file types and the 
"domain" attribute for domains). Allowing other domains to access unconfined_t is the concern. 

> http://www.nsa.gov/seLinux/list-archive/0610/17941.cfm

Above is the link to the message in the archives that I pulled the quote from, in case 
anyone is wondering about the context this was said in, though the statement by my 
estimation is straight forward and not context dependent in this case.

Some explanation of unconfined should be given and points like not letting other domains 
access unconfined should be made crystal clear, is it ever acceptable?If so under what conditions.

4 - *Admin Skills*

From recent traffic to fedora-selinux :

> I guess this is the number one thing we need to teach unix
> administrators.  With SELinux when you get a permission denied message
> there are 3 things to check.  Ownership, Permissions which all admins
> have ingrained into them, and SELinux Label.
>
> chown OWNER PATH
> chmod PERM PATH
> restorecon PATH

This brings us to the Z option , very useful, often forgotten(maybe it should be automatic 
with commands like ls -l). Also a complete listing of SELinux commands. Refer people to man 
pages except where command may be commonly used by admins.

Listing of most commonly encountered issues with explanations and typical fixes. The most 
important thing is explaining how to determine what the problem is and the general diagnostic 
approach one should use.

How do I tell the difference between the common and uncommon issues? Is there a general way to 
determine this? Somethings are never easy to explain but clues as to what should be looked for are invaluable.

Listing of not so common problems and a general diagnostic approach to take for these issues.

 At least a minimal list of info that you should include when asking for help on the mailing list. 
Who, what, when, where, why stuff that is useful in diagnosing problems. Like the top 5 things 
the SELinux guru would like to know or needs  to know to help resolve the issue.



5 - *audit2why and audit2allow* - The man pages explain pretty well what to do and how to do it. 
I would definitely include an explanation of these because they can be the primary tool for solving 
denials but if your going to copy and paste the man page then I would say don't bother. So I like 
the man page but if you can't take a slightly different approach to explaining it then I don't see 
the point of reiterating what's available from man audit2allow. Maybe just changing the order of 
the info presented would be enough, so its a little less tech manual and a little more conversational, 
more wiki less man page. This is the overall goal anyway.

From the man page:

>     Care must be exercised while acting on the output of  this  utility  to
>        ensure  that  the  operations  being  permitted  do not pose a security
>        threat. Often it is better to define new domains and/or types, or  make
>        other structural changes to narrowly allow an optimal set of operations
>        to succeed, as opposed to  blindly  implementing  the  sometimes  broad
>        changes  recommended  by this utility. 

This seems to me to be the most important point when using audit2allow. Here as a segue into 
writing policy there should be some of the *do nots of policy writing*, so if audit2allow happens 
to suggest one of these it either definitely shouldn't be allowed or requiring permissions of this 
kind should be considered an application bug or policy bug , bounce it off your distros selinux list etc...


>       Certain permission denials are
>        not fatal to the application, in which case it  may  be  preferable  to
>        simply  suppress  logging  of  the denial via a ’dontaudit’ rule rather
>        than an ’allow’ rule.

Breakdown the different rules, at least one of each, explain the conventions of policy language. 
How deep into policy langauge this needs to go I am not sure but most of what prompts people to 
turn SELinux off or ignore it is lack of understanding. Nothing turns people off like being 
confused but being in the dark is worse, too much info is better than not enough IMO. For 
instance the reserved word self , the wildcard and complement operators, all useful to know 
about and very dangerous if you stumble across it and don't fully understand the implications of 
using or not using it.

6 - *Explanation of the major concepts*. Types, domains, context, object classes etc....

7 - *Thorough breakdown of AVC*. This is really important. It is essentially the face of SELinux. 
If all goes well you'll never know its there but if something breaks then this is likely to make 
me want to take a header off the nearest skyscraper :

time->Tue Jul 15 22:02:04 2008
type=SYSCALL msg=audit(1216173724.561:64): arch=c000003e syscall=6 success=no exit=-13 
a0=1bcdaa5 a1=7fff450fea80 a2=7fff450fea80 a3=7faa3d0e4810 items=0 ppid=9135 pid=9143 
auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts2 
ses=2 comm="passwd" exe="/usr/bin/passwd" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1216173724.561:64): avc:  denied  { search } for pid=9143 comm="passwd" 
name="tmp" dev=dm-0 ino=12 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:tmp_t:s0 tclass=dir

Now experienced admins can figure out most of it or google for answers but this is for 
the inexperienced, running a desktop system, exactly where this is needed most, they may 
not have basic admin skills or care about learning them, so a comprehensive breakdown of 
the AVC is essential. I should be able to bookmark this page and use it for reference.

8 - *ausearch* is another must have in the arsenal of the admin. Alot of options here. 
Just a small random selection of them :

 -c, --comm comm-name
              Search for an event based on the given comm name. The comm name is the executable’s 
name from the task structure.

       -hn, --host host-name
              Search for an event with the given host name. The hostname can be either a hostname, 
fully qualified domain name, or numeric network address.  No  attempt  is  made  to
              resolve numeric addresses to domain names or aliases.

       -if, --input file-name
              Use the given file instead if the logs. This is to aid analysis where the logs 
have been moved to another machine or only part of a log was saved.

       --input-logs
              Use the log file location from auditd.conf as input for searching. This is needed 
if you are using ausearch from a cron job.


*Lots of ways to search. Can be used in conjunction with audit2allow:*

[root@localhost ~]# ausearch -m avc | audit2allow


#============= NetworkManager_t ==============
allow NetworkManager_t fixed_disk_device_t:blk_file getattr;

#============= avahi_t ==============
allow avahi_t user_home_t:file write;

#============= consoletype_t ==============
allow consoletype_t dhcpc_state_t:file read;


9 - *Examples,Examples,Examples*

What did I search by?How can this be useful to me? Its all in the man pages of 
course but man pages are dry and the output is intimidating.

[root@localhost ~]# ausearch -a 30 | grep SYSCALL
type=SYSCALL msg=audit(1212681693.050:30): arch=c000003e syscall=59 success=yes exit=0 
a0=403665 a1=7fff4a0fbba0 a2=7fff4a0fc228 a3=0 items=0 ppid=5712 pid=5713 auid=4294967295 
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="umount" exe="/bin/umount" subj=system_u:system_r:mount_t:s0 key=(null)
type=SYSCALL msg=audit(1213111393.121:30): arch=c000003e syscall=2 success=no exit=-13 
a0=7fff0a76d7d0 a1=2 a2=14 a3=0 items=0 ppid=4308 pid=4309 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lsusb" exe="/sbin/lsusb" subj=system_u:system_r:cupsd_config_t:s0 
key=(null) type=SYSCALL msg=audit(1214321269.400:30): arch=c000003e syscall=59 success=yes exit=0 
a0=14ebba0 a1=14a53c0 a2=14a8b20 a3=8 items=0 ppid=4104 pid=4114 auid=500 uid=0 gid=0 euid=0 suid=0 
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="iptables" exe="/sbin/iptables" 
subj=unconfined_u:system_r:iptables_t:s0 key=(null)


Leave no stone unturned. Make them laugh, make them cry, make an impression. Sometimes when 
explaining technical concepts to the uninitiated you must sacrifice being strictly accurate 
in favor of getting the larger point across. Once the larger point is made then each person 
can begin to work out the details but having the details without an appreciation of the larger 
picture causes more problems than it solves.


Max
Retrieved from "https://fedoraproject.org/w/index.php?title=Docs/Drafts/SELinux_User_Guide/SELinux_Feedback&oldid=40685"