Now you can yum install or update SELinux related packages which includes minimal policy and mod_selinux by Kaigai.

English version bellow.

Abaixo segue a apresentação feita por mim e pelo Ulisses Castro no FISL-10 Forum Internacional de Software Livre, realizado em Junho de 2009.



http://www.slideshare.net/guest552ebe/selinux-for-everyday-sysadmins-fisl-10

Na demonstração, confinamos uma PoC de uma vulnerabilidade do PhpMyAdmin (CVE-2009-1151), mostrando a sua exploração com selinux habilitado e desabilitado.

Obrigado a todos que puderam comparecer na apresentação.



English version:

Follow bellow a presentation that I've made with Ulisses Castro in FISL-10 Free Software Internacional Forum, in June of 2009.



http://www.slideshare.net/guest552ebe/selinux-for-everyday-sysadmins-fisl-10

In the demonstration, we have confined a PoC of a vulnerability of PhpMyAdmin (CVE-2009-1151), with selinux enabled and disabled.


Thanks to all who could attend the presentation.

I’ve uploaded the slides from essentially all of the talks I’ve given to Slideshare. This is likely more useful than my previous strategy of dumping them in a directory and leaving the rest up to search engine bots.

Click here for the full list of slides. They are all published under the Creative Commons attribution share-alike license.

One interesting slide title, which I’d forgotten about, is Kernel Security for 2.8, from the 2004 Kernel Summit. This was from when we were still expecting a 2.7 development kernel leading to a 2.8 stable kernel — I think Linus announced the change in development model at that summit.

Included in this set of slides are several introductory and deeper technical overviews of SELinux; I hope they are useful for people who are looking for information for themselves, or if making their own slides. As the license suggests, please feel free to copy and extend them (but note that the older ones are going to be more out of date).

The next openSUSE version is in the queue, milestone 3 of 11.2 was already released during LinuxTag last week.

We try to make 11.2 more SELinux-enabled than before. When you watch the security:SELinux (account needed) repository you may have recognized some changes during the last days. What did we changed so far:

• mkinitrd (Base:System): needs a little patch to mount /proc of the root filesystem to make the SELinux functions in init happy
• selinux-policy (security:SELinux): a new package that contains some sample policies as well as a config file (/etc/selinux/config)
• libselinux (security:SELinux): now includes a script named selinux-ready to verify if your system's configuration is suitable to run SELinux and give you hints of solving possible hurdles

So far it is still needed to install the packages, adding the boot-parameters (selinux=1 enforcing=0), and to make the directory /selinux (we don't want to pack this dir in a package - FHS).

What is on our TODO list:

• I hope we can add a yast-module to 11.2 to enable SELinux by one or two clicks
  
• everything else that is needed to enable basic SELinux support (looking at F11 ATM)
  
• we will not provide a policy or enable SELinux by default for now, but hopefully later

Volunteers are welcome. openSUSE:Factory is open now! :-)

kostenloser Counter

-

In segatex-7.768, you can download and install minimal policy.
Please wait until I get the job done.

Dave Cantrell and Tom London have recently asked me about how can they tell if an Access was added in a recent release?  Tom was trying to figure out whether he could remove a custom policy module and David has a bug report 508070 that stated the dhclient application was being denied sys_ptrace access, David noticed that he was not seeing the access any longer in Fedora 11,  he asked if the access was allowed.

Here are a couple of ways you can check to see if an access was added to the current selinux policy.

One tool that I use quite often to examine policy for access is sesearch, part of the setools package. sesearch allows you to examine the installed SELinux policy file /etc/selinux/POLICYTYPE/policy/policy.VERSION file. David could have executed a command like the following:


#sesearch --allow --dontaudit -s dhcpc_t -p sys_ptrace

Found 1 semantic av rules:
   dontaudit dhcpc_t dhcpc_t : capability { dac_read_search sys_module sys_ptrace sys_tty_config } ;

    * -s indicates the Source Type of the AVC.
    * -p indicates the access.

In this case I checked both for allow rules and dontaudit rules.

You can also use sesearch to examine all the access available for a certain domain (process). If you wanted to see all of the access allowed for the dhcpc_t domain, you could just execute

sesearch --allow  -s dhcpc_t

We have just added python bindings to sesearch for Fedora 12.  We are starting to use these in setroubleshoot so we can suggest possible labels for a denied domain.  For example, if someone sets up a directory /myweb in the / directory, it would be labeled default_t, then they tried to execute httpd using this directory they would get a denial saying httpd_t can not write default_t.  The setroubleshoot plugin uses sesearch to find the types that httpd_t can write too, and suggests these as alternative file labels.

Another way you could check is to feed the avc message to  audit2why (audit2allow -w)

# audit2why -i /tmp/t
node=apogee10.apogeect.com type=AVC msg=audit(1245934965.118:83): avc: denied { sys_ptrace } for pid=7132 comm="ps" capability=19 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=capability

 Was caused by:
  Unknown - should be dontaudit'd by active policy    Possible mismatch between this policy and the one under which the audit message was generated.

  Possible mismatch between current in-memory boolean settings vs. permanent ones. 

I often use audit2why to examine different policies to see if this version of policy has the access.  When I get a AVC bug report against RHEL5, I will check Fedora 11 to see if the access has been added.

audit2why can also tell you if there is a boolean to allow the access or if the access is caused by a constraint.

audit2why and sesearch are handy tools for examining SELinux policy.

Fixed downloader Fedora to download F11.

Multi Category Security or MCS is a discretionary implementation of the mandatory Multi Level Security or MLS Model. SELinux Policy MLS is a SELinux Policy model that is used in Department of Defense type environments. In a MLS environment processes are forced to operate on specified Security Levels. The s0 Security Level or SystemLow level is the lower end of the Security Level Range in a MLS environment. The s15 Security Level or SystemHigh level is the upper end of the Security Range in a MLS environment. Between the low and upper end there are fourteen levels to be used.

In MLS there is a rule that says: "no read up and no write down". This means that processes that are forced to operate on for example Security Level s14 can not read processes or files that operate on the s15 Security Level. Processes that are forced to operate on the s5 Security Level can not write to files or interact with processes on the s4 Security Level. The MLS model is used to enforce confidentiality.

MCS basically tries to use the MLS attributes: Security Levels and Security Compartments, in its own model in a way that may be useful in common environments. SELinux Policy Targeted can be build with the MCS functionality. Red Hat distributions have this MCS functionality enabled by default in its Targeted SELinux Policy model. Gentoo Hardened, as far as i know, does not have MCS functionality builtin by default.

MCS pretty much works like the DAC Extended attributes. Users are assigned categories and can apply these categories to content that they own to their discretion. You can easily recognise a MCS enabled system by looking at security contexts. A system that has SELinux Policy Targeted implemented without MCS enabled only has three fields in its Security Context tuples: user_u:role_r:type_t. Systems that have MCS implemented have one or more extra fields in their Security Context tuple: user_u:role_r:type_t:s0:c0. In MCS policy there is only one Security Level. This SystemLow level is s0. MCS does have 1024 categories that can be assigned to processes and files. Categories are the last field in the Security Context tuple. In a MCS environment s0:c0.c1023 is SystemHigh or the upper end of the MCS range. This means that if you are assigned the SystemHigh MCS range that you can access all categories. By default everything in a MCS environment has access to SystemLow or s0.

Example:

Create a new SELinux User that is based of off the user_u SELinux User. Call this SELinux User for example "mcsuser_u" and assign the full MCS range to this SELinux User:

sudo semanage user -a -L s0 -r s0-s0:c0.c1023 -R user_u -P user mcsuser_u
sudo cp /etc/selinux/targeted/contexts/users/user_u /etc/selinux/targeted/contexts/users/mcsuser_u

( to list the differences between SELinux User user_u and mcsuser_u simply: sudo semanage user -l | grep user_u )

Now create three Linux Users and map them to the mcsuser_u SELinux user. Give John access to the s0-s0:c122 MCS range. Give Jane access to the s0-s0:c123 MCS range, and give johnjane access to the s0-s0:c122,c123 MCS range.

sudo useradd john
sudo useradd jane
sudo useradd johnjane
sudo semanage login -a -s mcsuser_u -r s0-s0:c122 john
sudo semanage login -a -s mcsuser_u -r s0-s0:c123 jane
sudo semanage login -a -s mcsuser_u -r s0-s0:c122,c123 johnjane

Login as john, touch file with name test and list its attributes:

# touch test; ls -Z test;
mcsuser_u:object_r:user_home_t:s0 test

The file was created on the s0 SystemLow level which is accessible by everything. Now add the c122 category to the file with the chcat command, and list the SELinux attributes of file test:

# chcat -- +s0:c122 test
# ls -Z test
mcsuser_u:object_r:user_home_t:s0:c122

If you try to add for example category s0:c123 to the file you will be denied access to do so because your assigned MCS range does not include the s0:c123 category.

Try the same procedure for Jane but instead use the s0:c123 category.

Linux User johnjane has access to both s0:c122 and s0:c123 MCS categories. In a shared location where DAC permissions are sufficient johnjane would be able to access both files with s0:c122 as well as s0:c123 categories.

Johnjane can also assign both s0:c122 and s0:c123 to a single file, but then neither John nor Jane woould be able to access it.

If all these MCS category digits make you dizzy then you can install mcstrans. Mcstrans is a daemon that translates the MCS category numbers into strings of letters which are easier to work with. The mcstrans daemon has some problems though.

# sudo yum install mcstrans
# chkconfig mcstrans on
# service mcstrans start

Now one can add translations for the MCS category digits with the semanage command.

Translate s0:c122 to JohnsFriends, s0:c123 to JanesFriends, and s0:c122,c123 to JohnJanesFriends:

# sudo semanage translation -a -T JohnsFriends s0:c122
# sudo semanage translation -a -T JanesFriends s0:c123
# sudo semanage translation -a -T JohnsJanesFriend s0:c122,c123

( use sudo semanage translation -l to list current translation mappings )

Note: After this the mcstrans may have died. If required restart the mcstrans daemon.

# sudo service mcstrans restart

Users can use the chcat command to list which categories they have assigned:

# chcat -L john
john: JohnsFriends

User can also use the id command with the -Z option to view their security context. The context displays to categories.

# id -Z
mcsuser_u:user_r:user_t:SystemLow-JohnsFriends

Conclusion:

MCS is a neat extra functionality that can be enabled on systems that have SELinux Targeted Policy implemented.
The functionality of MCS is similar to that of Extended Attributes.

man: chcat, man semanage, man id

When you use our open build service (OBS) and build packages on your local machine, code from the network is executed as root. This is ok as long as you trust the packages.

If you do not want the code to be executed with full access to your local files then you can use KVM.

Add the following lines to you ~/.oscrc:

[general]
build-type=kvm
build-device=/tmp/KVM.root
build-swap=/tmp/KVM.swap
build-memory=254

But before this files can be used you have to create them:

> dd if=/dev/zero of=/tmp/KVM.swap bs=1024 count=300000

> qemu-img create /tmp/KVM.root 6G

> su -c "mkfs.ext3 -c /tmp/KVM.root "

Now you can use osc build without caring too much about your local security.

Thanks to Adrian to bringing this up.

kostenloser Counter

-

I’ve just filed Debian bug report #534534 about Valgrind/Helgrind reporting “Possible data race during write” [1]. I included a patch that seems to fix that problem (by checking whether a variable is not zero before setting it to zero). But on further testing with Valgrind 3.4.1 (backported from Debian/Unstable) it seems that my patch is not worth using, I expect that Valgrind related patches won’t be accepted into the Lenny version of OpenSSL.

I would appreciate suggestions on how to fix this, the problem is basically having a single static variable that is initialised to the value 1 but set to 0 the first time one of the malloc functions is called. Using a lock for this is not desirable as it will add overhead to every malloc operation. However without the lock it does seem possible to have a race condition if one thread calls CRYPTO_set_mem_functions() and then before that operation is finished a time slice is given to a thread that is allocating memory. So in spite of the overhead I guess that using a lock is the right thing to do.

deb http://www.coker.com.au lenny gcc

For the convenience of anyone who is testing these things on Debian and wants to use the latest valgrind, the above Debian repository has Valgrind 3.4.1 and a build of GCC to fix the problem I mentioned in my previous blog post about Valgrind [2].

if (default_RSA_meth == NULL)
default_RSA_meth=RSA_PKCS1_SSLeay();

I have also filed bug #534656 about another reported race condition in the OpenSSL libraries [3]. Above is the code in question (with some C preprocessor stuff removed). This seems likely to be a problem on an architecture for which assignment of a pointer is not an atomic operation, I don’t know if we even have any architectures that work in such a way.

static void impl_check(void)   {
        CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
        if(!impl)
                impl = &impl_default;
        CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
}
#define IMPL_CHECK if(!impl) impl_check();

A similar issue is my bug report bug #534683 [4] which is due to a similar issue with the above code. If the macro is changed to just call impl_check() then the problem will go away, but at some performance cost.

I filed bug report #534685 about a similar issue with the EX_DATA_CHECK macro [5].

I filed bug report #534687 about some code that has CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA); before it [6], so it seems that the code may be safe and it may be an issue with how Valgrind recognises problems (maybe a Valgrind bug or an issue with how Valgrind interprets what the OpenSSL code is doing). Valgrind 3.3.1 reported many more issues that were similar to this, so it appears that version 3.4.1 improved the analysis of this but didn’t do quite enough.

I filed bug report #534706 about the cleanse_ctr global variable that is used as a source of pseudo-randomness for the OPENSSL_cleanse() function without locking [7]. It seems that they have the idea that memset() is not adequate for clearing memory. Does anyone know of a good research paper about recovering the contents of memory after memset()? I doubt that we need such things.

I filed bug report #534699 about what appears to be a potential race condition in int_new_ex_data() [8]. The def_get_class() function obtains a lock before returning a pointer to a member of a hash table. It seems possible for an item to be deleted from the hash table (and it’s memory freed) after def_get_class() has returned the pointed but before int_new_ex_data() accesses the memory in question.

I filed bug report #534889 about int_free_ex_data() and int_new_ex_data() which call def_get_class() before obtaining a lock and then use the data returned from that function in a locked area[9] (it seems that obtaining the lock earlier would solve this).

I filed bug report #534892 about another piece of code which would have a race condition if pointer assignment isn’t atomic, this time in err_fns_check() [10]. In my first pass I didn’t bother filing bug reports about most of the issues helgrind raised with the error handling code (there were so many that I just hoped that there was some subtle locking involved that eluded helgrind and my brief scan of the source). But a new entry in my core file collection suggests that this may be a problem area for my code.

I think that it is fairly important to get security related libraries to be clean for use with valgrind and other debugging tools – if only to allow better debugging of the code that calls them. I would appreciate any assistance that people can offer in terms of fixing these problems. I know that there are security risks in terms of changing code in such important libraries, but there are also risks in leaving potential race conditions in such code.

As an aside, I’ve filed a wishlist bug report #534695 requesting that valgrind would have a feature to automatically add entries to the suppressions file [11]. As a function that is considered to be unsafe can be called from different contexts, and code that is considered unsafe can be in a macro that is called from multiple functions there can be many different suppressions needed. Pasting them all into the suppressions file is tedious.

• [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534534


• [2] http://etbe.coker.com.au/2009/06/22/valgrindhelgrind-and-stl-string/


• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534656


• [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534683


• [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534685


• [6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534687


• [7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534706


• [8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534699


• [9] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534889


• [10] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534892


• [11] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534695

The staff module provided by Refpolicy is pretty cool but i needed a user domain with less privileges that would be able to transition to privileged admin domains.

One of my requirements was that this User Domain should only be accessible via OpenSSH and that it should be identical to the guest_t User Domain or have even less privileges. The guest_t User Domain was designed to not User Domain transition ever.

Another requirement for my mystaff User Domain was that this user should not be able to change passwords. I did this because the provided staff_t User Domain by Tresys can change passwords. If i sudo to root in the staff_t User Domain than in theory i would be able to change the root password. This is something i wanted to prevent for mystaff user.

Generally i wanted mystaff to have as little privileges as possible. It would be a very restricted login environment only accessible with OpenSSH that would be able to transition to specified admin User domains like for example webadm_t.

I started by reverse engineering the staff_t User Domain:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/roles/staff.te
http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/roles/staff.if

The staff.te file is mostly one call to a interface that is defined in the userdom modules interface file:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/system/userdomain.if ( line 927 to line 1020)

So far so good, but this interface has calls to to included several other interfaces that are defined in the same interface files:

userdom_restricted_user_template($1)
userdom_common_user_template($1)

These interfaces have calls to yet other interfaces defined in userdom.if file and so forth and so forth.

userdom_login_user_template($1)
userdom_basic_networking_template($1)

Which call:

userdom_base_user_template($1)
userdom_manage_home_role($1_r, $1_t)
userdom_manage_tmp_role($1_r, $1_t)
userdom_manage_tmpfs_role($1_r, $1_t)
userdom_exec_user_tmp_files($1_t)
userdom_exec_user_home_content_files($1_t)
userdom_change_password_template($1)

My goal was to expand all these userdomain interfaces so that i could remove parts of policy in there that i did not need.

Since i did not want mystaff to be able to change passwords i could for example remove the userdom_change_password_template altogether.

I also wanted mystaff to easily be customizable for different admin domain transitions and i started making different admin domains based of off webadm User domain. Basically i edited the name and declarations and replace the apache_admin interface calls by admin interface calls for other services. I also remove some policy specific to webadm.

For example:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/aide.if (line 46 to line 71)

The interface to call for administration of the aide domain.

Long story short. Below you will find the links to the mystaff user domain that is based of off the staff domain provided by upstream. In mystaff module i have expanded all userdom interface calls and i have removed policy that i did not require.

Basically the mystaff_u SELinux user is even more restricted then guest_u but unlike guest_u, mystaff_u can use sudo to user domain transition to admin domains. By default i have it call the webadm_role_change interface which allows mystaff_r access to the already by default installed webadm_r role. I also used the gen_user() macro to generate a mystaff_u SELinux User. However this SELinux user does not yet have the webadm_r role mapped. One could simply use semanage user -m ...> mystaff_u to add the webadm_r or edit the gen_user() macro to recflect mystaff_u SELinux Users access to the webadm_r role.

You will also notice plenty commented role_change template calls for other services. One can simple uncomment any of these calls to allow mystaff_r access to the role these provides. This requires that you install the corresponding admin User domains which can be found in the same modules directory.
It is then also required to map any of these roles to the mystaff_u SELinux User.

http:///82.197.205.60/~dgrift/stuff/modules/mystaff.te
http:///82.197.205.60/~dgrift/stuff/modules/mystaff.if
http:///82.197.205.60/~dgrift/stuff/modules/mystaff.fc

Other source policy modules:
http:///82.197.205.60/~dgrift/stuff/modules/

By the way: the mystaff module can be easily modified to reflect a myguest modified guest User Domain. Just comment:

optional_policy(`
sudo_role_template(mystaff, mystaff_r, mystaff_t)
')

# Available privileged roles
# Test
optional_policy(`
webadm_role_change(mystaff_r)
')

In that case one may also want to rename the mystaff to something more appropriate. One can simply modify this policy to add or remove privileges.

Oh, by the way, do not forget to add default contexts for mystaff_u. You can base you mystaff_u default context file of off the staff_u file in /etc/selinux/targeted/contexts/users/. All you have to do is replace staff by mystaff in this file. (see my previous article on creating custom user domains)

In this article i will try to explain a bit more about the policy module source files.

A policy module source has three files. The first file is a Type Enforcement file. These files have the .te extension. The second file is a interface file. These files have a .if extension. The third file is called a file context file. This file has a .fc extension.

Type enforcement source policy file.

This file has policy and declarations that a personal or local to the policy module. Policy that is used by the (personal) types that are declared in this module.

Interface source policy file.

This file has policy and declarations that are shared with other types.

File context source policy file.

This file has personal file contexts for the personal types that are (usually) declared in the Type Enforcement file.

Some background information:

Example of a AVC denial:

avc: denied { read write } for pid=1864 comm="tor" path="/dev/console" dev=tmpfs ino=496 scontext=system_u:system_r:tor_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file

Example of the AVC denial when processed by audit2allow:

allow tor_t console_device_t:chr_file { read write };

Example of the AVC denial processed by audit2allow -R:

term_use_console(tor_t)

The AVC denial has a lot of information about details of a denied rule in the Access Vector Cache. The basic audit2allow command translates this AVC denial into human readable policy language. The audit2allow -R command goes looking for any available shared policy that may be available for us to use.

In this example the tor_t domain wants to read and write to /dev/console which is a character device file that has type console_device_t. Tor interacts with terminal.

To make policy manageable and to keep the footprint of policy as small as possible the concept of shared policy is used. There is no need for duplicate policy. There should be a single point where a certain access is defined. This point is defined in the interface file of the target.

In this example term_use_console is shared policy that is hosted by the module that declared(owns) type console_device_t. Interfaces (shared policy) are usually prefixed by the name of the module that own the type of the target.

The tor_t domain tries to read and write to console_device_t which is a type that is declared in the terminal.te source policy file. The terminal.if interface file hosts policy to interact with this type properly: term_use_console. term is the abbreviation for terminal which is the name of the module that hosts the console_device_t file.

The type console_device_t is declared here -- it is a declaration the is personal to the terminal policy module (terminal.te):

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/kernel/terminal.te (line 21)

The interface term_use_console is defined here -- it is policy that is shared (hosted) by the terminal policy module (terminal.if):

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/kernel/terminal.if (line 219 to line 237)

The terminal module own the console_device_t type and shares all policy other types need to be able to interact with this type. If something changes in the way that interaction is done with this type then the terminal.if is a central point to modify policy for this. Other types simple call this shared policy and changes automatically get synchronized.

Shared policy usually have a commented header which explains the purpose of the interface and the parameters it expects when it is called.

For term_use_console the description is:

Read from and write to the console

And the parameter it expects is:

Domain allowed access.

If the tor_t domain wants to read and write to the terminal a device file with type console_device_t then it can simple call the shared policy that is hosted in the terminal.if file, which is the file that shares policy and declaration with regard to types and domains that are personal to the terminal policy module.

Look at interfaces like BASH functions. You can source a external file that has BASH functions and then call any functions that are provided by the sources functions file.

The purpose of the commented headers is that it is easy to reference and call the interfaces. The source policy can be converted to html if you run "make html" in the source root.

An example of this is hosted here:

http://oss.tresys.com/docs/refpolicy/api/

The specific term_use_console interface is specified here:

http://oss.tresys.com/docs/refpolicy/api/kernel_terminal.html

Below the commented header for the term_use_console interface the actual shared policy can be found. This policy often has calls to shared policy for types that are external to the module. In this case the term_use_console as a interface call to dev_list_all_dev_nodes($1) Which is shared policy that is hosted by the devices module (interfaces defined in device.if).

The $1 is a variable of the parameter is expects. Look up the interface name here: http://oss.tresys.com/docs/refpolicy/api/kernel_devices.html and see what parameter is expects: Domain allowed to list device nodes.

If a domain type tor_t wants to list device nodes then simple call dev_list_all_dev_nodes(tor_t)

$1, $2, $3 etc are variables that replace parameter 1, parameter 2, parameter 3 etc.

Another rule in the term_use_console interface in terminal.if is:

allow $1 console_device_t:chr_file rw_chr_file_perms;

If term_use_console(tor_t) is defined than the rule is translated:

allow tor_t console_device_t:chr_file rw_chr_file_perms;

Which basically allows the tor_t domain type read and write access to character files with type console_device_t.

The last thing to mention about the term_use_console interface and interfaces in general is the gen_require() blocks that can be seen.

Since type console_device_t is declared in terminal.te and since term_use_console is called by tor_t domain in the tor.te source policy file, the tor_t files has to borrow the console_device_t type which is external to the tor.te file.

The gen_require() and require{} block basically source types that are declared in other modules. After the types are sourced they can be used in personal policy.

another example:

If you encounter a AVC denial than consider that the target type (tcontext type) usually hosts policy to facilitate the access that the source type (scontext type) in the AVC denial needs. Run the AVC denial through audit2allow to hav it translated to raw policy language. Run the AVC denial through audit2allow -R to have it look for any shared policy that facilitates the access that is required.

Of course you can also do this yourself:

avc: denied { read } for pid=1842 comm="smartd" name="config" dev=dm-1 ino=39859 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file

The smartd executable that runs in the fsdaemon_t domain wants to read a file with name config and with type selinux_config_t.

allow fsdaemon_t selinux_config_t:file read;

The module that has declared selinux_config_t should also provide shared policy that facilitates the access fsdaemon_t domain needs.

I would expect that type selinux_config_t would be declared in selinux.te since types and interfaces are often prefixed by the name of the module that owns it. In this case it is not so straight forward. A little peruse of the policy shows that this type is declared in the selinuxutil.te file.

So shared policy related to this type should be in the selinuxutil.if file. On line 595 in the selinuxutil.if interface file here:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/system/selinuxutil.if

This interface called seutil_read_config can be called by fsdaemon_t if we wish to give that domain this permissions.

seutil_read_config(fsdaemon_t)

However policy decisions are usually not that simple to make. A better idea may be to use this interface on line 575:

seutil_dontaudit_read_config(fsdaemon_t)

File context files define file contexts of types that are declared in the policy module. Have a look at some of the many examples Type Enforcement, Interface and File contexts files available in Tresys Reference policy.

Here are some screen cast where i demonstrate some of the things that were discussed in the SELinux Lockdown series.

1. Create custom SELinux users.

Here i create a new SELinux User called new_u and map the staff_r, system_r and unconfined roles to this user. This SELinux User also has also has access to all available MCS categories.

Linux user joe is mapped to the new_u SELinux user. Default contexts for new_u SELinux were copied from those of staff_u since new_u is based of off staff_u with minor modifications (access to unconfined_r instead of sysadm_r)

Sudo is also set up to allow joe root access and to automatically Domain Transition to unconfined_t User Domain.

http://www.youtube.com/watch?v=NmkQqNq0DJE



2. Quick demonstration of PAM SEPermit.

http://www.youtube.com/watch?v=-0qge9vtPjg



3. Quick demonstration of unconfined_login boolean.

http://www.youtube.com/watch?v=Ky3jm5n4f8M



4. How to extend staff_t User Domain to allow listing of /var (part1)

http://www.youtube.com/watch?v=0gaxh0lZ4MU



4.1 How to extend staff_t User Domain to allow listing of /var (part2)

http://www.youtube.com/watch?v=Rnrca8khz1w



5. Create a new unprivileged (secondary) User Domain.

http://www.youtube.com/watch?v=bDFTiZOteiA



6. The newrole command is useful for unprivileged User Domain transitions.

http://www.youtube.com/watch?v=9N0WsncDrfY



7. Demonstration of how to create a Application Domain to achieve listing of /var for staff_t (part1)

http://www.youtube.com/watch?v=c06sjcC9CNs



7.1 Demonstration of how to create a Application Domain to achieve listing of /var for staff_t (part2)

http://www.youtube.com/watch?v=U2GDBor1BsQ



7.2 Demonstration of how to create a Application Domain to achieve listing of /var for staff_t (part3)

http://www.youtube.com/watch?v=riXisTFPEzo



Looks like the last episode turned out a bit too long for YouTube. Heres a trimmed down version:

http://www.youtube.com/watch?v=9UJUxqf3NkY



Excuse my bad english and funny dialect :)

A lot was discussed in the previous nine articles. This is the last article in this series. In this article i will in short repeat the steps to maximize the security that SELinux provides. Details about any of these steps can be found in the previous articles.

1. SELinux User.

Map Linux Users by default to a confined SELinux User. Think least privilege. Use for example guest_u: sudo semanage login -m -s guest_u -r s0-s0 __default__

If you wish to override the default SELinux User for a new Linux User then you can do so with the useradd and -Z option.

Do not map Linux users to the unconfined_u SELinux user. An exception to this rule can be the root user. Root users should not be allowed to login except via TTY in emergencies.

2. PAM SEPermit.

Add entries for all your confined SELinux Users to /etc/security/sepermit.conf to block logins when SELinux is in permissive mode.

You can decide to create a unique SELinux User for yourself that is exempted from SEPermit.

3. Permissive mode Vs. Permissive Domains.

Always prefer the use of Permissive Domains over Permissive Mode.

4. Do not modify your default SELinux Users. If you need a custom SELinux User and or SELinux user Domain then create a new one. You can base them of off existing ones.

5. Use Role based Access control to confine root and user privileges.

6. Do not modify existing Roles/ User Domains.

If you need a custom role then base it of off an existing role and map the new role to a new SELinux user. You can however map existing roles to new SELinux users.

7. Use sudo. Not SU and newrole.

8. Remove the unconfined domain(s).

Be sure to sudo semodule -r unconfined to disable system services that have no policy defined. use sudo semodule -r unconfineduser to completely disable unconfined user environments (not recommended) If you do decide to remove unconfineduser, then make sure to configure your SELinux User mappings to reflect this. Use sysadm instead of unconfined

I prefer unconfined User Domain over sysadm User Domain for a secondary all purpose privileged user domain because:

a. unconfined_login boolean can be set to disable unconfined user logins.
b. ssh_sysadm_login, and xdm_sysadm_login booleans do not work.
c. sysadm is a drunken unconfined.
d. root logins are disabled.
e. i only use unconfined user domain as a secundary privileged user domain that can only be accessed via sudo
e.1. except for the root Linux User which can only login via TTY in emergencies.

9. Remove as much policy as possible by either disabling or enabling booleans.

set unconfined_login to off
set xserver_object_manager to on
set *_exec_content to off
consider the secure_mode_booleans

Booleans are blocks of policy that can be added or removed on the fly by toggling a boolean. The old NSA Example policy was based on a least privilege model. This means that as little as possible was allowed to successfully achieve a task. Almost each rule that gets added to SELinux policy adds new privileges. To maximize security that SELinux provide the mount of active rules should be kept to a minimum.

In Fedora 11 There is some policy enabled with booleans that your environment may not need. It is recommended that this policy is removed and that it is only added when it is needed.

Some booleans add policy when enabled, others add policy when disabled. A simple description of a booleans functionality can be displayed with the command: sudo semanage boolean -l. These descriptions are usually enough to understand its functionality but the descriptions are short. If you run a AVC denial through the audit2why command than audit2why will display which boolean to set in order to solve the issue if the problem can be solved by toggling a boolean.

Sometimes it is best to look to the contents of booleans to understand what they allow. Booleans are defined in Source Policy. You would have to have access to the Source Policy and you would have to know how to find the blocks of policy that are the content of the boolean.

There are three older tools that help you list, set and toggle SELinux booleans: getsebool, setsebool and togglesebool. In Fedora 11 the functionality that these tools provides has been built into the semanage command: semanage boolean.

The names of booleans should point to the Source Policy Module where the boolean is defined. Unfortunately it often is not that easy to find the location of the boolean definition in Source Policy. In a prefect scenario that name of the boolean has the name of the module where it is defined prepended.

Example: How to find the meaning and content of gpg_agent_env_file boolean:

# semanage boolean -l | grep gpg
gpg_agent_env_file -> off Allow usage of the gpg-agent --write-env-file option. This also allows gpg-agent to manage user files.

As the name of the boolean suggest, the boolean is defined somewhere in the gpg module:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/apps/gpg.te
On line 196 to line 203 the actually content of the boolean is defined.

This boolean allows programs that run in the gpg_agent_t SELinux Domain to write files in the user home space with the generic user_home_t type when the boolean is set to on.

I think there is actually a but in the block of policy as the gpg_agent_t may only type transition to user_home_t files and not to directories.

The boolean declaration can be found on line 9 to line 15. The declaration has a short description of the functionality of the boolean.

The reason why i showed you how to find a description and the actual content of a boolean is because i cannot discuss each and every boolean in this article. If it is decided to lock-down booleans one can look up whether it actually adds or removes policy when toggled on and what it actually does. Then the boolean can just be switched on and off to see if you need to policy it provides. If required that AVC denials can be fed to audit2why to see if there is a boolean available to allow the functionality.

There are a few booleans that i would like to highlight in this article:

The unconfined_login boolean:

unconfined_login -> off Allow a user to login as an unconfined domain

This boolean was discussed the Part Eight of this series. If set to on then users can login to the system in the unconfined_t User Domain.
Security can be improved much by setting this to off. The content of this boolean can be found in the unconfineduser.te file in Source Policy.

The ssh_sysadm_login and xdm_sysadm_login booleans:

ssh_sysadm_login -> off Allow ssh logins as sysadm_r:sysadm_t
xdm_sysadm_login -> off Allow xdm logins as sysadm

This boolean is similar to unconfined_login for the sysadm_t User Domain. This boolean currently does NOT work. Therefore it is not recommended to map any SELinux Users to the sysadm_r role. Users with access to this role can log into the system directly in this privileged domain.

The *_allow_exec_content_t booleans:

allow_sysadm_exec_content -> off allow_sysadm_exec_content
allow_xguest_exec_content -> off allow_xguest_exec_content
allow_user_exec_content -> off allow_user_exec_content
allow_staff_exec_content -> off allow_staff_exec_content
allow_guest_exec_content -> off allow_guest_exec_content

The description of this boolean is not very helpfull as you can see. When this boolean is set to on then users that operate in any of the mentioned User Domains can execute user content in their user space. This means files with type user_home_t, user_tmp_t or when nfs or samba home directories are enabled types nfs_t and cifs_t respectively. This boolean is Fedora specific and its contents can be found in the userdomain.if Source Policy file.

The secure_module boolean:

secure_mode -> off Enabling secure mode disallows programs, such as newrole, from transitioning to administrative user domains.

The secure_mode boolean can be enabled to disallow User Domain transitions to privileged User Domains. The content of this boolean can be found in the selinuxutil.te Source policy file: http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/system/selinuxutil.te

The policy for this boolean starts on line 289 and ends on line 295. This boolean currently only works for the newrole command. It does NOT work for the sudo command. Therefore it is encouraged to not depend on this boolean.


The secure_mode_insmod boolean:

secure_mode_insmod -> off Disable transitions to insmod.

When this boolean is set to on then confined users will not be able to transition to the insmod Domain. Restricted user domain will not be able to insert Linux Kernel modules. This boolean is defined in the modutils.te Source Policy file: http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/system/modutils.te

The policy starts on line 120 and end on line 122. The declaration for this boolean can be found on line 4 to line 6.

The secure_mode_policyload boolean:

secure_mode_policyload -> off boolean to determine whether the system permits loading policy, setting enforcing mode, and changing boolean values. Set this to true and you have to reboot to set it back

The description of this boolean is quite good. When enabled there is no policy to permit the loading of policy, setting the enforcing mode and changing of booleans. This policy can be found in the selinux.te Source Policy file: http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/kernel/selinux.te

The content of this boolean starts on line 44 and ends on line 52.

The xserver_object_manager boolean:

xserver_object_manager -> off Support X userspace object manager

This boolean is quite powerful. By enabling this boolean the X Server access control extensions become enable. XACE allows the operator to define how processes can interact with X Server. The default policy still has rough edges. XACE is implemented for the SELinux Multi Level Security Policy Model which enforces confidentiality. By default it is disabled with SELinux Policy Targeted. If you feel brave, enable it and experience the power of Xace.
After you set this boolean to true you are required to restart the X server.

The content of this boolean can be found in the xserver.te Source Policy file: http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/xserver.te

The content of this boolean starts on line 749 and ends on line 766.

It is not always easy to find where booleans are defined unfortunately. There is room for improvement with the naming of booleans.

Conclusion:

To achieve greater security minimize the amount of policy.
Sometimes policy is added by turning a boolean on and sometimes policy is added by turning a boolean off.
Content of booleans can be reviewed in Source Policy.

Refer: man getsebool, man setsebool, man togglesebool, man audit2why, man semanage