Switching to Enforcing Mode

be> CommitDate: Sun Oct 23 13:00:43 2011 +0000 URL: http://git.overlays.gentoo.org/gitweb/?p=3Dproj/hardened-docs= .git;a=3Dcommit;h=3D2ddbc661 Remove obsolete documents --- xml/selinux/hb-using-enforcing.xml | 224 ----------- xml/selinux/hb-using-permissive.xml | 666 --------------------------= ------ xml/selinux/hb-using-policymodules.xml | 576 --------------------------= - 3 files changed, 0 insertions(+), 1466 deletions(-) diff --git a/xml/selinux/hb-using-enforcing.xml b/xml/selinux/hb-using-en= forcing.xml deleted file mode 100644 index ca626c3..0000000 --- a/xml/selinux/hb-using-enforcing.xml +++ /dev/null @@ -1,224 +0,0 @@ - - - - - - - - - -1 -2011-03-02 - -

-Switching to Enforcing Mode - -Introduction - - -

-Switching to enforcing mode doesn't require all policies to be fully -operational, nor does it require that the system boots in enforcing mode= . You -can first start small by enabling enforcing mode the moment your system = is -booted, then enable enforcing during boot (but with the possibility to d= isable -it again when some things fail) and finally reconfigure your kernel so t= hat -disabling SELinux isn't possible anymore. -

- - - - -Booting, Switch - - -

-To boot your system before enabling enforcing mode, just boot as you do -currently. Then, when you believe that you can run your system in enforc= ing -mode, run setenforce 1. -

- -

-~# setenforce 1
-

- -

-It is wise to ensure that you have booted the system but not logged in a= nywhere -except as the root user. Also verify that the session you're currently i= n (as -root) uses the root:sysadm_r:sysadm_t or=20 -unconfined_u:unconfined_r:unconfined_t context (otherwise trying = to -disable enforcing mode might not work). -

- -

-When you realize that things are going very, very wrong, disable SELinux= using -setenforce 0 and try to resolve the failures. -

- - - - -Booting in Enforcing Mode (Once) - - -

-When you want to boot in enforcing mode, but you don't want to configure= SELinux -(yet) to run always in enforcing mode (say you want to try it once), add -enforcing=3D1 as a boot option inside the boot loader configurati= on. -

- -

-kernel /vmlinuz root=3D/dev/md3 rootflags=3Ddata=3Djournal enforcing=3D=
1
-

- - - - -Booting in Enforcing Mode - - -

-Once you believe that you can always (re)boot in enforcing mode, edit -/etc/selinux/config and change SELINUX=3Dpermissive = to -SELINUX=3Denforcing. -

- - - - -Reconfiguring the Kernel - - -

-Once you are fully confident that you can always and ever remain in enfo= rcing -mode, reconfigure your kernel so that SELinux cannot be disabled anymore= . -

- -

-[*] NSA SELinux Support
-[ ]   NSA SELinux boot parameter
-[ ]   NSA SELinux runtime disable
-# Make sure the following is deselected
-[ ]   NSA SELinux Development Support
-[ ]   NSA SELinux AVC Statistics
-(1)   NSA SELinux checkreqprot default value
-[ ]   NSA SELinux maximum supported policy format version
-

- - - -

-Analyzing AVC - -Intrusion or Not - - -

-Once you are running in enforcing mode, the role of the -/var/log/avc.log logfile starts changing. Whereas it was pr= eviously -used to inform you about denials which might cause functional failures o= n your -system, it is now more and more becoming a source of information for the -behavior of applications - and sometimes, the unexpected behavior of it. -

- -

-Being able to read the AVC logs is important, because in the (near) futu= re you -should use the AVC logs to identify potential intrusion attempts. Say th= at you -are running an Internet-facing web server which is contained within its = own -SELinux domain. Suddenly you start getting weird AVC denials of that SEL= inux -domain trying to read files it really shouldn't read, or write stuff in = some -temporary location it shouldn't write anything into. This can be a total= ly -expected behavior, but can also be a malicious user that is attempting t= o run -some exploit code against your web server. -

- -

-Interpreting the AVC logs can be considered a time-consuming job if you = are -still getting lots of cosmetic (and safe) AVC denials. So let's first se= e if we -can ignore those... -

- - - - -Ignoring Cosmetic AVC Events - - -

-When you get AVC denials which you believe are harmless for your system,= you can -create a policy module yourself which contains the exact AVC rule, but u= sing the -dontaudit statement rather than allow. -

- -

-Consider the following AVC denial: -

- -

-Jan  6 19:49:25 hpl kernel: [10482.016339] type=3D1400 audit(1294339765.=
865:1527):
-avc:  denied  { use } for  pid=3D19421 comm=3D"ifconfig" path=3D"/dev/nu=
ll" dev=3Dtmpfs
-ino=3D1552 scontext=3Dsystem_u:system_r:ifconfig_t
-tcontext=3Dsystem_u:system_r:wpa_cli_t tclass=3Dfd
-

- -

-The denial states that the ifconfig process is trying to use a fi= le -descriptor within the wpa_cli_t domain. The target file descriptor point= s to -/dev/null. This usually means that the ifconfig proc= ess is -started from within the wpa_cli_t domain with > /dev/null to r= edirect -its output to the /dev/null device. Although it is denied (= so no output -will be redirected to /dev/null) it has no functional impac= t on the -system as the intention was to ignore the output anyhow. -

- -

-So how can we ensure that this rule doesn't fill up our AVC logs? Well, = we need -to create a module (like we have seen before in Creating Specific Allow Ru= les): -

- -

-~$ cat ignoreavc.te
-module ignoreavc 1.0.0;
-
-require {
-  type ifconfig_t;
-  type wpa_cli_t;
-
-  class fd use;
-}
-
-dontaudit ifconfig_t wpa_cli_t:fd { use };
-
-~$ checkmodule -m -o ignoreavc.mod ignoreavc.te
-~$ semodule_package -o ignoreavc.pp -m ignoreavc.mod
-~$ semodule -i ignoreavc.pp
-

- -

-Once this module is loaded, you should no longer see these denials in yo= ur log. -However, if you ever feel that you might have dontaudit'ed too ma= ny -things, you can always reload the SELinux policies without the dontaudit -statements: -

- -

-~# semodule -R -D
-

- -

-If you are confident to continue with the dontaudit statements again, ru= n the -same command without the -D. -

- -

-Gentoo Hardened uses a specific boolean called gentoo_try_dontaudit to=20 -show or hide the denials that the developers believe are cosmetic. Thank= s to=20 -this approach, you can first disable the Gentoo-selected dontaudit state= ments=20 -before showing all of them - which can be quite a lot more. -

- - - -

- diff --git a/xml/selinux/hb-using-permissive.xml b/xml/selinux/hb-using-p= ermissive.xml deleted file mode 100644 index 2b331c7..0000000 --- a/xml/selinux/hb-using-permissive.xml +++ /dev/null @@ -1,666 +0,0 @@ - - - - - - - - - -6 -2011-09-11 - -

-Keeping Track of Denials - -Introduction - - -

-The moment you start using SELinux in permissive mode, SELinux will star= t=20 -logging all of its denials through your system logger. Based on this -information, you can and will: -

- -

- see if certain domains are missing (for instance, commands are being= ran - inside a more standard domain whereas you would expect it to run wit= hin a - more specific one) in which case you'll probably look for a SELinux = policy - module to introduce the specific domain,=20 -
- see if some files have wrong security contexts in which case you'll = either - restore their context or set it yourself, -
- see if some denials are made which you don't expect in which case yo= u'll - find out why the denial is made and what the original policy writer = intended - (a prime example would be a website hosted in the wrong location in = the file - system) -

- -

-Of course, several other aspects can be performed the moment you analyze= the -denial messages, but the above ones are the most common. -

- - - - -Configuring System Logger - - -

-Before we start investigating denials, let's first configure the system = logger -to log the denials in its own log file. If you are running syslog-ng wit= h a -Gentoo Hardened profile, it will already be configured to log these deni= als in -/var/log/avc.log: -

- -

-destination avc { file("/var/log/avc.log"); };
-[...]
-filter f_avc { message(".*avc: .*"); };
-filter f_audit { message("^(\\[.*\..*] |)audit.*") and not message(".*av=
c: .*"); };
-[...]
-log { source(kernsrc); filter(f_avc); destination(avc); };
-

- -

-If you use a different logger, look for the configuration of the kernel = audit -events. Throughout the rest of this document, we assume that the log whe= re the -denials are logged in is /var/log/avc.log. -

- - - - -What is AVC? - - -

-When we previously showed a few of SELinux' policy allow rules, what you= were -actually looking at was an access vector rule. For instance: -

- -

-allow sysadm_t portage_t : process transition ;
-

- -

-Up until now we have seen only the allow permission, but SELinux = supports -others as well: -

- -

- auditallow will allow an activity to occur, but will still lo= g it - (but then with a "granted" message instead of "denied") -
- dontaudit will not allow an activity to occur but will also n= ot log - this. This is particularly useful where the activity is not needed a= nd would - otherwise fill the avc.log file. -

- -

-To improve efficiency of the policy enforcement, SELinux uses a cache fo= r its -access vectors - the access vector cache or AVC. Whenever = some -access is requested which isn't in the cache yet, it is first loaded in = the -cache from which the allow/deny is triggered. Hence the "avc" messages a= nd the -avc.log log file. -

- - - - -Looking at the AVC Log - - -

-During regular system operations, you can keep track of the denials thro= ugh a -simple tail session: -

- -

-~# tail -f /var/log/avc.log
-Jan  1 09:56:59 hpl kernel: [ 2232.354810] type=3D1400 audit(1293872219.=
247:156):
-  avc:  denied  { setattr } for  pid=3D7419 comm=3D"gorg" name=3D"selinu=
x-handbook.xml" dev=3Ddm-3 ino=3D159061=20
-  scontext=3Dstaff_u:staff_r:staff_t tcontext=3Dstaff_u:object_r:var_t t=
class=3Dfile
-Jan  1 10:08:52 hpl kernel: [ 2944.664577] type=3D1400 audit(1293872932.=
907:157):=20
-  avc:  denied  { use } for  pid=3D9917 comm=3D"ifconfig" path=3D"/dev/n=
ull" dev=3Dtmpfs ino=3D1546=20
-  scontext=3Dsystem_u:system_r:ifconfig_t tcontext=3Dsystem_u:system_r:w=
pa_cli_t tclass=3Dfd
-Jan  1 10:08:53 hpl kernel: [ 2945.504956] type=3D1400 audit(1293872933.=
749:158):=20
-  avc:  denied  { create } for  pid=3D10016 comm=3D"logger"=20
-  scontext=3Dsystem_u:system_r:wpa_cli_t tcontext=3Dsystem_u:system_r:wp=
a_cli_t tclass=3Dunix_stream_socket
-

- -

-But how do you interprete such messages? Well, let's take a closer look = at the -first denial from the example. -

- -

-[ Standard data within log message, such as date, time, hostnam=
e, ...  ]
-Jan  1 09:56:59 hpl kernel: [ 2232.354810] type=3D1400=20
-[ The message is an AVC audit message, telling a deny for the s=
etattr system call ]
-  audit(1293872219.247:156): avc:  denied  { setattr }=20
-[ The offending process has PID 7419 and is named "gorg" ] =20
-  for  pid=3D7419 comm=3D"gorg"=20
-[ The target for the system call is a file named "selinux-handb=
ook.xml"
-  on the dm-3 device; the file has inode 159061 ]
-  name=3D"selinux-handbook.xml" dev=3Ddm-3 ino=3D159061=20
-[ The source and target security contexts and the class of the =
target (in this case, a file) ]
-  scontext=3Dstaff_u:staff_r:staff_t tcontext=3Dstaff_u:object_r:var_t t=
class=3Dfile
-

- -

-A similar one can be found of the last line in the example. -

- -

-Jan  1 10:08:53 hpl kernel: [ 2945.504956] type=3D1400 audit(1293872933.=
749:158):=20
-  avc:  denied  { create } for  pid=3D10016 comm=3D"logger"=20
-  scontext=3Dsystem_u:system_r:wpa_cli_t tcontext=3Dsystem_u:system_r:wp=
a_cli_t tclass=3Dunix_stream_socket
-

- -

-In this particular case, the offending process is logger (with PI= D 10016) -which is trying to create a Unix stream socket (see the tclass -information). -

- -

-Note though that not all AVC messages imply denials. Some accesses recor= ded by -the access vector cache are grants but which have an explicit audital= low -statement so that this can be tracked in the logs. -

- - - -

-Analyzing Denials - -A Standard Setup Might Not Work - - -

-If you have taken a look at your denials, you'll probably think "If I'm = going to -go to enforcing mode, my system will not function properly" and you migh= t be=20 -right. At this point, Gentoo Hardened is constantly updating the SELinux= =20 -policies to get you a working system - but we're not fully there yet. Fo= r this=20 -reason, being able to analyze the denials (and take corrective actions) = is=20 -very important. -

- -

-It is not easy to describe what the best option is when you see a denial= which -shouldn't be. But a few ground-rules do apply. -

- -

- Verify if the denial is cosmetic or not. Try focusing on denials of = which - you are sure that they are not cosmetic and will result in a - malfunction of your system (or that particular command) if no correc= tive - action is taken. -
- If you see a denial where the source context is a generic one (such = as - sysadm_t or staff_t or user_t), try to find out= if - there are specific SELinux policy modules for the offending resource= . In the - previous example of the gorg process, we definitely need to c= heck if - there is no selinux-gorg SELinux policy. Note that, even if there is= none, - it doesn't mean there shouldn't be ;-) -
- If the target for the denial is a file, verify if its security conte= xt is - correct or if no different context should be given. It is also possi= ble that - the process is trying to work on the wrong path. Sometimes a simple - configuration change of that process is sufficient to make it work p= roperly - under its SELinux policy. -

- -

-During development of the policies, Gentoo Hardened developers will try = to=20 -hide denials they believe are cosmetic. This hiding can be toggled using= the -SELinux gentoo_try_dontaudit boolean: -

- -

-~# getsebool gentoo_try_dontaudit
-gentoo_try_dontaudit --> off
-~# setsebool -P gentoo_try_dontaudit on
-

- -

-When set, the denials that are believed to be cosmetic are hidden from y= our -audit logs. But if your system is not functioning properly and you do no= t see -any denials, it is wise to toggle this boolean again to verify if the de= nial -is now shown or not. -

- - - - -Installing Additional SELinux Policy Modules - - -

-When a denial is found for which you think a SELinux policy module shoul= d=20 -exist, find out which package provides the offending resource and verify= if -Gentoo offers a SELinux policy for that package. If it does, install it = and -relabel the files of the package. -

- -

-~# tail -f /var/log/avc.log
-Jan  1 09:42:37 hpl kernel: [ 1372.708172] type=3D1400 audit(1293871357.=
972:76):
-  avc:  denied  { search } for  pid=3D6937 comm=3D"screen" name=3D"selin=
ux" dev=3Ddm-0
-  ino=3D1053303 scontext=3Dstaff_u:staff_r:staff_t
-  tcontext=3Dstaff_u:object_r:user_home_t tclass=3Ddir
-
-~# whereis screen
-screen: /usr/bin/screen
-
-~# qfile /usr/bin/screen
-app-misc/screen (/usr/bin/screen)
-
-~# emerge --search selinux-screen
-Searching...   =20
-[ Results for search key : selinux-screen ]
-[ Applications found : 1 ]
-
-*  sec-policy/selinux-screen
-      Latest version available: 2.20110726
-      Latest version installed: 2.20110726
-      Size of files: 574 kB
-      Homepage:      http://www.gentoo.org/proj/en/hardened/selinux/
-      Description:   SELinux policy for screen
-      License:       GPL-2
-
-~# emerge selinux-screen
-[...]
-
-~# rlpkg screen
-Relabeling: app-misc/screen-4.0.3
-

- -

-If you believe a SELinux policy module should exist but you cannot find = one, -then you can either download the reference policy tarball (which you mig= ht find -in your distfiles directory - it is called -refpolicy-2.YYYYMMDD.tar.bz2) and see if there are already = modules -available (look inside the refpolicy/policy/modules locatio= n) or -ask around on #gentoo-hardened on irc.freenode.net. -

- - - - -Updating the Security Contexts of Files - - -

-The most common case of denials when the necessary policies are in place= are -wrongly labeled files or directories (in other words, the security conte= xt of -the target file or directory is not what the policy would expect). This = can be -either because the file has not been (re)labeled after the policy has be= en -loaded or because the label has for some reason changed (case 1) or beca= use=20 -the path of the file is not in accordance to the file context specificat= ions -in the SELinux module (case 2). -

- -

-The first possibility (security context correct in policy, but not appli= ed) can -be easily fixed using the restorecon command. You can apply it ag= ainst a -single file, or run it recursively using the -R option. -

- -

-~# restorecon /etc/make.conf
-

- -

-If the file context definition in the policy however doesn't apply to th= e file -(or directory), you can still tell your system to label the file or dire= ctory -accordingly. For instance, say you have your lvm.conf file = inside -/etc rather than /etc/lvm as the policy would = expect, -then you can still label the file correctly using semanage. With=20 -semanage, you assign a correct security context unrelated to any -module. It is a local setting - but which is persistent across reboots a= nd -relabelling activities. -

- -

-~# semanage fcontext -a -t lvm_etc_t /etc/lvm.conf
-~# restorecon /etc/lvm.conf
-

- -

-If you want to make such a definition part of a module you're writing, y= ou will -need to create a file context file which contains the definition(s) for = the -files whose context you want to set. Writing policy modules is described= later -in this book in Adding SELinux Poli= cy -Modules. -

- - - - -Creating Specific Allow Rules - - -

-If a denial isn't resolved through an available SELinux policy module or= a -corrective action taken against the target file or directory, or there -is no such module available, then you might opt to create your own polic= y. If -your goal is to allow a specific set of rules (rather than to write a -full-fledged SELinux policy module) then you can use the audit2allow<= /c> tool -to generate a policy based on the denial logs. -

- -

-With audit2allow, you can transform an AVC denial message into a = SELinux -policy module definition. This can then be compiled into a binary policy= module -and finally packaged into an easily (re)loadable SELinux policy module. = It is -recommended to keep the (raw) AVC logs that you use to build the SELinux= policy -module as this will allow you to continuously update the module when new= denials -occur. -

- -

-For instance, to allow some sudo-related denials, you can do the -following steps... -

- -

-[ We append the AVC messages to the sudo.raw file so that, in t=
he future, we can
-  add additional denial messages inside the same raw file which will be =
used to
-  build a new SELinux policy module ]
-~# grep 'comm=3D"sudo"' /var/log/avc.log >> sudo.raw
-
-[ We generate a module definition called 'fixsudo' based on the=
 captured AVC denials ]
-~# cat sudo.raw | audit2allow -m fixsudo > fixsudo.te
-
-[ Next we build the SELinux module ]
-~# checkmodule -m -o fixsudo.mod fixsudo.te
-~# semodule_package -o fixsudo.pp -m fixsudo.mod
-

- -

-The generated policy module (with the .pp suffix) can then = be -dynamically loaded into the SELinux policy store: -

- -

-~# semodule -i fixsudo.pp
-

- -

-The module definition (in our example called fixsudo.te) ca= n be -modified as you please - it's content is standard ASCII, human readable. -

- -

-Not all denials that you might get are bugs in the default security poli= cy.=20 -It is very probable that you use your system in a slightly different way= than -intended within the Gentoo Hardened SELinux default policy. However, if = you -believe that you had to change your runtime policy due to a bug in the -current policy, please report it on Bugzilla so that the Gentoo Harde= ned=20 -SELinux developers can take a look at it. Also, don't hesitate to contac= t -the Gentoo Hardened SELinux developers if you are uncertain about things= . -

- -

-They don't bite. They get fed regularly so they don't have to. -

- - - -

- -

-Working with SELinux - -Loading and Unloading of Modules - - -

-We have already crossed SELinux modules quite a few times. You even saw = that, in -order to load a module, you can use semodule -i modulename.pp. Th= e -semodule command offers the following functions: -

- -

- With semodule -i modulename.pp you (re)install a module (or i= nstall - a higher version of said module) -
- With semodule -u modulename.pp you upgrade an existing instal= led - module with a new version of this module -
- With semodule -r modulename.pp you remove a module from the S= ELinux - policy store. It will not be reloaded, not even after a reboot. -
- With semodule -R you reload the policies. An interesting feat= ure here - is that you can add -D which will disable the donta= udit - rules from the policy. This can be useful, especially later in enfor= cing - mode, to find out why something is failing even though you get no de= nials. -
- With semodule -B you force a rebuild of the policy (which inc= ludes by - default a reload of the policy as well). Amongst some other things, = such a - rebuild will read up on the existing users' and their home directori= es and - create the associated domains. -

- - - - -Listing Modules - - -

-With the semodule -l command you can get an overview of the insta= lled -modules, together with their current version. When you have issues with = SELinux -policies and are trying to get online help on the matter, knowing the ve= rsion of -the particular module is important to help you troubleshoot problems. -

- -

-~# semodule -l
-dbus    1.14.0
-dnsmasq 1.9.0
-hal     1.13.0
-[...]
-

- - - - -Switching Roles - - -

-When you are working with a SELinux system, your default users will be u= sing the -user_u SELinux login (and as such the user_r SELinux role) so they will = not need -to perform any role switching: there are no other roles they can switch = to. -

- -

-Accounts that you use to perform more administrative tasks however are m= ost -likely mapped to the staff_u SELinux login or have their own login but w= ith the -same roles supported: staff_r and sysadm_r. These accounts should by def= ault -start within the staff_r role. Although still restricted, it has more -possibilities (with respect to supported target domains to transition to= ) -than the user_r role. -

- -

-The major difference however is that these users will also have to switc= h roles -from time to time. For instance, if you want to use Portage - even just = for -querying the tree - you will need to be in the sysadm_r role. To switch = roles, -use the newrole command: -

- -

-~$ newrole -r sysadm_r
-Password: (Enter your personal password)
-~$
-

- -

-With id -Z you can verify that you have indeed successfully switc= hed -roles. -

- -

-Now how do you know that you need to switch roles? Generally, you will g= et a -Permission denied statement on one or more files: -

- -

-~$ emerge --info
-Permission denied: '/etc/make.conf'
-

- -

-You might not be able, from within your current role, to find out if swi= tching -roles is sufficient to gain read access. Within your current role, you m= ight not -be able to get to view the current security context or query the SELinux= AV -rules. But if you switch to the sysadm_r role and run the necessary quer= ies, you -might get the information you need: -

- -

-~$ id -Z
-staff_u:staff_r:staff_t
-~$ newrole -r sysadm_r
-Password: (Enter your personal password)
-~$ id -Z
-staff_u:sysadm_r:sysadm_t
-~$ ls -Z /etc/make.conf
-system_u:object_r:portage_conf_t /etc/make.conf
-~$ sesearch -t portage_conf_t -c file -p read -A -d
-Found 8 semantic av rules:
-   allow portage_t portage_conf_t : file { ioctl read getattr lock execu=
te execute_no_trans open } ;=20
-   # This is the one we are looking for
-   allow sysadm_t portage_conf_t : file { ioctl read write ... } ;=20
-   allow portage_fetch_t portage_conf_t : file { ioctl read getattr lock=
 open } ;=20
-   allow restorecond_t portage_conf_t : file { ioctl read getattr lock r=
elabelfrom relabelto open } ;=20
-   allow gcc_config_t portage_conf_t : file { ioctl read getattr lock op=
en } ;=20
-   allow portage_sandbox_t portage_conf_t : file { ioctl read getattr lo=
ck open } ;=20
-   allow rsync_t portage_conf_t : file { ioctl read getattr lock open } =
;=20
-   allow mount_t portage_conf_t : file { ioctl read getattr lock open } =
;=20
-

- -

-As you can see, the sysadm_t domain (which is affiliated with the sysadm= _r role) -has the necessary read access, whereas there is no sign of any read acce= ss for -the staff_t domain. -

- - - - -Using File Labels - - -

-During regular system usage, you will get into situations where you need= to set -file labels (security contexts). We have already covered the use of -semanage and restorecon to do so, but a few other methods = exist as -well, each of them for specific purposes... -

- -

-With chcon users (and not only administrators) can relabel files = (if they -have the necessary privileges to do so) to the type they want. As an exa= mple, -consider the domains and rules for the Mozilla applications (such as fir= efox). -By default, this domain has no ability to create new files in the user h= ome -directory. However, a specific domain has been created (mozilla_home_t) = in which -the application can create files. By creating a folder (say -Downloads) and relabeling it correctly, the application is = able to -create new files inside this location. -

- -

-~$ ls -Zd ~/Downloads
-staff_u:object_r:user_home_t  Downloads/
-~$ chcon -t mozilla_home_t ~/Downloads
-~$ ls -Zd ~/Downloads
-staff_u:object_r:mozilla_home_t
-

- -

-It is important to understand that relabeling is a specific privilege wh= ich is -also governed by SELinux policies (the staff_t domain has this privilege= on the -user_home_t domain). Also, the target domain (mozilla_home_t) is still -manageable by the staff_t domain (including relabeling) so that the rela= beling -activity doesn't lower the privileges that staff_t has on this folder. T= his -isn't always the case, so be careful when you relabel. -

- -

-Relabelling files is governed by the relabelfrom and relabelto privilege= s. -Consider the following two hypothetical rules: -

- -

-allow staff_t foo_t : dir { relabelfrom relabelto };
-allow staff_t bar_t : dir { relabelto };
-

- -

-In the first rule, the staff_t domain has the ability to relabel directo= ries -that are currently in the foo_t domain (relabelfrom) and to relabel dire= ctories -to the foo_t domain (if their source domain has a correct relabelfrom -privilege). In the second rule, the staff_t domain is only able to relab= el -directories to the bar_t domain. However, once a directory has the bar_t= domain, -the staff_t domain has no ability to relabel it to something else (no -relabelfrom privilege). -

- - - - -Relabelling Gentoo Package Content - - -

-As a last section let's talk about Gentoo support for relabeling files. = By -default, Portage will relabel all files of a package once it is installe= d. This -is governed by the FEATURES=3D"selinux" setting which is enabled when yo= u select -the selinux profiles. An administrator can also relabel the contents of = a -package using the (Gentoo-specific) rlpkg command (installed thro= ugh=20 -the policycoreutils package): -

- -

-~# rlpkg net-tools
-Relabeling: sys-apps/net-tools-1.60_p20090728014017-r1
-

- -

-The same tool can be used to relabel the entire system: -

- -

-~# rlpkg -a -r
-

- - - -

- diff --git a/xml/selinux/hb-using-policymodules.xml b/xml/selinux/hb-usin= g-policymodules.xml deleted file mode 100644 index 3032bcb..0000000 --- a/xml/selinux/hb-using-policymodules.xml +++ /dev/null @@ -1,576 +0,0 @@ - - - - - - - - - -1 -2011-03-02 - -

-Writing Simple Policies - -Writing a TE File - - -

-Let us summarize our previous experiences with writing simple policies. = We have -already covered how to write a .te file and convert it to a -loadable SELinux module. Let's go over this once again with a simple exa= mple: -allowing execmem for the mozilla_t domain. -

- -

-When using the selinux-mozilla provided SELinux module, you= might -still get a failure if you are using the 32-bit binary firefox package -(www-client/firefox-bin) and if you do not allow memexec (s= ee the -allow_memexec boolean). You will probably find an AVC denial tell= ing you -this exact same thing. If you want to allow just mozilla_t to run execme= m, you -can write the following fixmozilla.te module: -

- -

-module fixmozilla 1.0.0;
-
-require {
-  type mozilla_t;
-  class process execmem;
-}
-
-allow mozilla_t self:process { execmem };
-

- -

-This simple policy sais that the module is called fixmozilla with= module -version 1.0.0 (it is wise to update this version every time you u= pdate -the content of the module so that you can quickly verify with semodul= e -l -if the new version is loaded or not). It requires the mozilla_t d= omain -(if sec-policy/selinux-mozilla isn't installed, loading of = this -policy will fail as it will not find the mozilla_t domain) and the -process class with the execmem operation. The policy itsel= f=20 -(the AVC statement) is to allow the mozilla_t domain to use execmem on i= ts=20 -own processes. -

- -

-To convert this source into a loadable policy, we first convert it into = a -.mod file: -

- -

-~$ checkmodule -m -o fixmozilla.mod fixmozilla.te
-

- -

-In this particular command, we create a non-base (-m) module file -(fixmozilla.mod) which contains the statements offered by t= he -fixmozilla.te file. If you are running an MLS/MCS system yo= u will -need to add the -M option. -

- -

-Next we package this module into a loadable SELinux module: -

- -

-~$ semodule_package -o fixmozilla.pp -m fixmozilla.mod
-

- -

-This final module file (fixmozilla.pp) can then be loaded i= nto the -SELinux policy store using semodule -i fixmozilla.pp. -

- -

-Using this relatively simple method, you can create all the policy rules= you -want. However, you most likely want to add information on file labeling = as -well... -

- - - - -Writing an FC File - - -

-An FC file (File Context) contains the file labels (security cont= exts) -that should be assigned to particular files. If you structure your modul= es -correctly, you most likely have policies for particular programs, and yo= u would -like to label the program files and binaries accordingly. This is what t= he -.fc files are for. -

- -

-Let's take a look at a sample .fc file which contains the various types = of -context definitions that are supported: -

- -

-/var/.*                   gen_context(system_u:object_r:var_t)
-/dev/.*tty[^/]*     -c    gen_context(system_u:object_r:tty_device_t)
-/dev/p[fg][0-3]     -b    gen_context(system_u:object_r:removable_device=
_t)
-/vmlinuz.*          -l    gen_context(system_u:object_r:boot_t)
-/usr/bin/firefox    --    gen_context(system_u:object_r:mozilla_exec_t)
-/tmp/\.ICE-unix/.*  -s    <<none>>
-/dev/initctl        -p    gen_context(system_u:object_r:initctl_t)
-/mnt(/[^/]*)?       -d    gen_context(system_u:object_r:mnt_t)
-

- -

-The first column (in every line) starts with a regular expression to mat= ch -against a file's path. This is usually sufficient to match any possible = file. -SELinux does support some special variables like ROLE, HOME_DIR, HOME_RO= OT and -USER which are substituted with their corresponding values when the file= context -is (re)compiled (for instance when you add or delete SELinux users or re= build -the policy using semodule). -

- -

-The second column, if available, starts with a dash followed by the file= type: -character device, block device, symbolic link, -socket, directory, named pipe or a regular file (-). -

- -

-The last column gives the security context (label) that should be assign= ed to -the resource(s) that match the regular expression. You should always see= the -"standard three" (user, role, domain), but you might also see the securi= ty level -and even category if MLS/MCS is used or supported by the module. -

- -

-/usr/tmp    -d  gen_context(system_u:object_r:tmp_t,s0-s15,c0.c255)
-

- -

-You can write your own FC file. For instance, Gentoo adds the following -definition to the sec-policy/selinux-mozilla package to sup= port the -binary firefox package: -

- -

-/usr/bin/firefox-bin           -- gen_context(system_u:object_r:mozilla_=
exec_t,s0)
-/opt/firefox/libxul\.so        -- gen_context(system_u:object_r:textrel_=
shlib_t,s0)
-/opt/firefox/firefox           -- gen_context(system_u:object_r:mozilla_=
exec_t,s0)
-/opt/firefox/run-mozilla.sh    -- gen_context(system_u:object_r:mozilla_=
exec_t,s0)
-/opt/firefox/firefox-bin       -- gen_context(system_u:object_r:mozilla_=
exec_t,s0)
-/opt/firefox/plugin-container  -- gen_context(system_u:object_r:mozilla_=
exec_t,s0)
-

- -

-If you want to add such a file to your policy, add it during the -semodule_package phase: -

- -

-~$ semodule_package -o fixmozilla.pp -m fixmozilla.mod -f fixmozilla.=
fc
-

- -

-Once this policy is loaded, you can use tools like matchpathcon, -restorecon and more as they now know how to deal with the files y= ou have -mentioned in your file context file. -

- - - -

-Building a Reference Policy Module - -Introduction to the Reference Policy - - -

-Initially we have already covered the fact that Gentoo Hardened bases it= s -policies on the reference policy maintained by Tresys. This reference po= licy -offers an important additional functionality during module development: -interfaces. -

- -

-By creating an interface, you actually create a function of some sort wh= ich can -be used in other modules. Such interfaces allow module writers to genera= te rules -to interact with the domain of their module without knowing what the oth= er -domains are. For instance, the mozilla module has an interface definitio= n like -so: -

- -

-interface(`mozilla_read_user_home_files',`
-  gen_require(`
-    type mozilla_home_t;
-  ')
-
-  allow $1 mozilla_home_t:dir list_dir_perms;
-  allow $1 mozilla_home_t:file read_file_perms;
-  allow $1 mozilla_home_t:lnk_file read_lnk_file_perms;
-  userdom_search_user_home_dirs($1)
-')
-

- -

-This interface allows other modules to use the -mozilla_read_user_home_files function if they want their domain t= o be -able to (in this case) read the files in the mozilla_home_t domain. Of c= ourse, -they can add all statements inside their own definition, but then they w= ould -have to require that the mozilla module is loaded, which might be a wron= g -assumption, and duplicate the same allow statements for each application= . -The use of interfaces makes policy development easier. -

- -

-Also, the reference policy allows the use of optional statements: -a module can call an interface of another module, but this may not fail = if -the other module is not available on a users' system. -

- -

-For instance, in the evolution policy: -

- -

-optional_policy(`
-  mozilla_read_user_home_files(evolution_t)
-  mozilla_domtrans(evolution_t)
-')
-

- -

-In this extract we see that the previously defined interface is called w= ith -argument evolution_t (the Evolution domain) within an optional_policy= -clause. As a result, building this policy will attempt to call this inte= rface, -but if the interface is missing (because the mozilla module isn't instal= led) it -will not fail the build of the evolution module. -

- -

-Using the interfaces allows for a clean separation of the various module= s. -Within the reference policy, the following guidelines are used: -

- -

- Inside a .te file, the only domains that are allowed to= be - mentioned are those defined in the same .te file. Any - interaction with other domains need to happen through interfaces off= ered by - that domain. -
- Inside an .if file, where the interfaces are defined, a= n XML - like syntax is used to document each interface, allowing for develop= ers to - read easily what an interface is meant to do (because honestly, ther= e are - far more complex interfaces than the one we have previously shown) -
- Distribution-specific aspects of modules should be enclosed within a - ifdef(`distro_gentoo',`...') statement (example for Gentoo). = This - statement is supported in all three files (.te, - .if and .fc). -

- - - - -Building the Reference Policy Module - - -

-If you want to build a module using the reference policy interfaces, you= first -need to create the .te file and, optionally (but most likel= y -needed) .if and .fc file. It is wise to start = from an -example set of files for a similar application. If you want to or need t= o use -interfaces of different modules, you can find the interfaces that are va= lid on -your system inside /usr/share/selinux/strict/include. -

- -

-Once you want to build the module, copy the -/usr/share/selinux/strict/include/Makefile file inside the -directory where your policy definition(s) are stored. Then, call the = make -command to build the policy modules.=20 -

- -

-The result should be one (or more) loadable SELinux modules. -

- - - -

-Example: Start Building the Skype Policy - -Labelling - - -

-Let's start to create a sample reference policy based SELinux module for= the skype -application. This application is a well-known application used to perfor= m voice- -and video chats across the Internet. We will not finish the module in th= is -chapter (as the exercise will become a repetitive try-and-correct cycle = which -isn't the purpose to document here) but rather show an approach on how t= o deal -with such policy building exercises. -

- -

-First get acquainted with the application. -

- -

-The usual way of interacting with skype is from an end-user point= (not -administrator). From interacting with it in permissive mode (or from a -non-SELinux system) we know it creates a ~/.Skype folder fo= r its -configuration, chat history and more. -

- -

-Given this above information, let's take a look at the content of the -net-im/skype package: -

- -

-~$ qlist skype
-(Output shortened for clarity)
-/usr/bin/skype
-/usr/share/... # Unrelated to the application but used by distr=
ibution
-/opt/skype/skype
-/opt/skype/sounds/...
-/opt/skype/lang/...
-/opt/skype/avatars/...
-

- -

-Given this information, we could create the following file context defin= ition: -

- -

-/usr/bin/skype         -- gen_context(system_u:object_r:skype_exec_t,s0)
-/opt/skype/skype       -- gen_context(system_u:object_r:skype_exec_t,s0)
-HOME_DIR/\.Skype(/.*)?    gen_context(system_u:object_r:skype_home_t,s0)
-

- -

-We will not give the various skype files a specific label - they are all -read-only files so can keep the default label assigned to them. -

- -

-Within the skype.te file, we define the necessary domains a= nd=20 -also use the first interfaces which are often associated with this kind = of -domains (for reasoning you can read the sources for the apache module or= =20 -other services). A sample module to base our definition from could be -telepathy... -

- -

-policy_module(skype, 1.0.0)
-
-type skype_t;
-type skype_exec_t;
-application_domain(skype_t, skype_exec_t)
-
-type skype_home_t;
-userdom_user_home_content(skype_home_t)
-
-# Allow skype_t to put files in the skype_home_t location(s)
-manage_dirs_pattern(skype_t, skype_home_t, skype_home_t)
-manage_files_pattern(skype_t, skype_home_t, skype_home_t)
-userdom_user_home_dir_filetrans(skype_t, skype_home_t, { dir file })
-userdom_search_user_home_dirs(skype_t)
-

- -

-Again, we're not going to cover the various interfaces and explain them.= They -are documented and available on the system, and there are plenty of exam= ples to -use. -

- -

-Finally, we are going to create an interface to allow users to transitio= n to the -skype_t domain. The idea here is that you add skype_role(role, domain= ) in -the .te definition of the users' domain or within your own = policy. -

- -

-interface(`skype_role',`
-  gen_require(`
-    type skype_t, skype_exec_t;
-  ')
-
-  role $1 types skype_t;
-
-  domain_auto_trans($2, skype_exec_t, skype_t)
-')
-

- -

-Build the module and load it in the SELinux module store. Next, create a= small -policy to allow users (user_r, user_t) to access skype: -

- -

-~$ cat skypeusers.te
-policy_module(skypeusers, 1.0.0)
-
-gen_require(`
-  type user_t;
-  role user_r;
-  type staff_t;
-  role staff_r;
-')
-
-optional_policy(`
-  skype_role(user_r, user_t)
-  skype_role(staff_r, staff_t)
-')
-

- -

-Build that module as well and load it. A regular SELinux user should now= have -the ability to execute skype_exec_t and transition to the skype_t domain= . -

- - - - -Dry Run - - -

-With the policy loaded, do a dry run. Relabel the files of the -net-im/skype package (and if you have previously ran skype = yourself, -relabel the ~/.Skype folder as well), then start skype and both=20 -watch skype's output as well as the AVC denials. -

- -

-We notice that the binary (skype) hangs and cannot be killed. In the AVC= denial -logs, we notice the following denials: -

- -

-Jan  6 22:01:56 hpl kernel: [18418.420427] type=3D1400 audit(1294347716.=
358:2221):
-avc:  denied  { read write } for  pid=3D25540 comm=3D"skype" name=3D"1" =
dev=3Ddevpts
-ino=3D4 scontext=3Dstaff_u:staff_r:skype_t tcontext=3Dstaff_u:object_r:u=
ser_devpts_t
-tclass=3Dchr_file
-Jan  6 22:01:56 hpl kernel: [18418.420455] type=3D1400 audit(1294347716.=
358:2222):
-avc:  denied  { use } for  pid=3D25540 comm=3D"skype" path=3D"/dev/pts/1=
" dev=3Ddevpts
-ino=3D4 scontext=3Dstaff_u:staff_r:skype_t tcontext=3Dstaff_u:staff_r:st=
aff_t
-tclass=3Dfd
-Jan  6 22:01:56 hpl kernel: [18418.420563] type=3D1400 audit(1294347716.=
358:2225):
-avc:  denied  { sigchld } for  pid=3D6532 comm=3D"bash"
-scontext=3Dstaff_u:staff_r:skype_t tcontext=3Dstaff_u:staff_r:staff_t tc=
lass=3Dprocess
-

- -

-Note that the attempt is done in enforcing mode - running in permissive = mode -will yield more AVC denials and is also a plausible way to create the ne= cessary -rules. -

- -

-From the denials, we see that skype attempts to use the pts in which the= command -is ran (notice that this fails because we didn't explicitly allow it) an= d also -fails to exit properly (a sigchld signal isn't allowed to be submitted). -

- -

-By looking into the example policies already around, we notice that they= have -interfaces in use such as userdom_use_user_terminals as well as g= eneric -allowances such as ps_process_pattern (to allow users to view a p= rocess -and kill it). This is a nice example of how a type enforcement MAC syste= m works: -nothing is assumed by default. -

- - - - -Next Dry Run - - -

-So after adding some interfaces to allow the use of the user terminals, = file -descriptors and also allow process signals to be sent, we try to run the -application again. Now, we get: -

- -

-~$ skype
-Killed
-
-~$ cat /var/log/avc.log
-Jan  6 22:27:41 hpl kernel: [19961.313321] type=3D1400
-audit(1294349261.991:9089017): avc:  denied  { execmem } for  pid=3D2725=
6
-comm=3D"skype" scontext=3Dstaff_u:staff_r:skype_t tcontext=3Dstaff_u:sta=
ff_r:skype_t
-tclass=3Dprocess
-

- -

-At least skype now exits. From the AVC log, we see that it wants = to call -execmem (which isn't something we like, but have seen in the past for mo= zilla as -well). Okay, let's allow this, rebuild the modules and retry. -

- -

-~$ skype
-./skype: error while loading shared libraries: libasound.so.2: cannot op=
en
-shared object file: Permission denied
-
-~$ cat /var/log/avc.log
-Jan  6 22:33:41 hpl kernel: [20319.960127] type=3D1400
-audit(1294349621.275:9089042): avc:  denied  { read } for  pid=3D27536
-comm=3D"skype" name=3D"libasound.so.2" dev=3Ddm-1 ino=3D525098
-scontext=3Dstaff_u:staff_r:skype_t tcontext=3Dsystem_u:object_r:usr_t
-tclass=3Dlnk_file
-

- -

-Okay, we need to grant it read rights to links within the usr_t domain (= and most -likely then load libraries from the lib_t domain, so we need to add -files_read_usr_symlinks and libs_use_ld_so, etc. -

- - - - -Finishing Up - - -

-After running into the standard "can't start" issues, you'll notice that= the -application then wants to bind and connect to ports - which are also pro= tected -by SELinux and can be manipulated by various interfaces. It wants to acc= ess your -soundcard and webcam, etc. -

- -

-As you can see from the above information, writing policies correctly is= n't -easy. You need to constantly keep in mind what you are allowing - aren't= you -granting too much? Are you forgetting something? Also, the first time(s)= you -create policies it will take lots of time, but over time you will grow b= etter in -it. You'll start realizing what all those standard things are that you n= eed to -allow and what not. -

- -

-Writing SELinux policies isn't hard, but it's far more difficult than se= tting -the standard Linux permissions on files and directories. It requires a d= ecent -knowledge of how the application behaves and what the SELinux reference = policy -interfaces grant when you select them. -

- -

-If you ever feel like writing these policies, don't hesitate to read up = on the -various resources at the end of this book. -

- - - -