Tired of ads? Upgrade to paid account and never see ads again!


Dan Walsh's Blog

Got SELinux?

Previous Entry Share Next Entry
How do I make local customizations in RHEL 5?
With the release of Red Hat Enterprise Linux 5 Beta 2, I am getting more questions about customizing policy.  In RHEL4 we advised people to install the selinux-policy-targeted-sources packages and then to create a local.te file in the /etc/selinux/targeted/src/policy/domains/misc directory.  You could use audit2allow to translate the AVC messages into allow rules and then the admin could rebuild policy and reload.  The problem with this was that everytime a new policy package got released it would have to exec the Makefile in order to try to keep the local policy.  Well with the release of Red Hat Enterprise Linux 5, this all changes.  We have eliminated the "sources" rpm packages altogether.  We are treating the policy packages more like the kernel, and if you want to look at the sources used to build the policy, you need to install source rpm, selinux-policy-XYZ.src.rpm.  We have added an selinux-policy-devel package, which I will talk about later. 

So what does an administrator do when he wants to make some small modifications to policy?

We have introduced the concept of modular policy.  This allows vendors to ship SELinux policy separate from the OS Policy.  It also allows administrators to make local changes to policy and not have to worry about the next policy install.  Modular policy was introduced in Fedora Core 5 and more features were added in Fedora Core 6. The major command that was added was semodule.
>man semodule

SEMODULE(8)                           NSA                          SEMODULE(8)

       semodule - Manage SELinux policy modules.

       semodule [options]... MODE [MODES]...

       semodule is the tool used to manage SELinux policy modules, including installing, upgrading, listing and remov-
       ing modules.  semodule may also be used to force a rebuild of policy from the module store and/or  to  force  a
       reload  of policy without performing any other transaction.  semodule acts on module packages created by semod-
       ule_package.  Conventionally, these files have a .pp suffix (policy package), although this is not mandated  in
       any way.


If you want to view the policy modules on a system you can use the semodule -l command

# semodule -l
amavis  1.1.0
ccs     1.0.0
clamav  1.1.0
dcc     1.1.0
evolution       1.1.0
iscsid  1.0.0
mozilla 1.1.0
nagios  1.1.0
oddjob  1.0.1
pyzor   1.1.0
razor   1.1.0
ricci   1.0.0
smartmon        1.1.0

This command does not show you the base policy module which is also installed. You can read all about loadable policy modules at tresys.  Also the excellent book,
SELinux by Example,  has some great information on SELinux and modules.  And no I do not recieve commisions.  :^)

If you look in /usr/share/selinux/targeted/ you will see a lot of policy package (*.pp) files there.  These files are included in the selinux-policy rpm and are used to build the policy file. 
So lets get back to builind a local policy module. Lets look at an example. Currenly there is a bug in policy.  The ypbind init script executes the setsebool command which in turn tries to use the terminal.  This is generating a denial

type=AVC msg=audit(1164222416.269:22): avc:  denied  { use } for  pid=1940 comm="setsebool" name="0" dev=devpts ino=2 scontext=system_u:system_r:semanage_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=fd

While this is not a big deal, since everything works correctly, it can be an aggravation.  To eliminate this AVC, you could use audit2allow to generate a rule that looks like this.

# grep setsebool /var/log/audit/audit.log  | audit2allow
allow semanage_t init_t:fd use;

But since we do not have policy sources what do you do? Well audit2allow now has the  ability to build policy modules.

#  grep setsebool /var/log/audit/audit.log  | audit2allow -M mysemanage
Generating type enforcment file: mysemanage.te
Compiling policy
checkmodule -M -m -o mysemanage.mod mysemanage.te
semodule_package -o mysemanage.pp -m mysemanage.mod

******************** IMPORTANT ***********************

In order to load this newly created policy package into the kernel,
you are required to execute

semodule -i mysemanage.pp

The audit2allow rule has actually gone out and built a type enforcement file (mysemanage.te).  audit2allow  then executed the checkmodule command to compile a module file (mysemanage.mod). Finally it uses the semodule_package package up a policy package (mysemanage.pp). If you look at the te file:

cat mysemanag.te
module mysemanage 1.0;

require {
        class fd use;
        type init_t;
        type semanage_t;
        role system_r;

allow semanage_t init_t:fd use;

You will see three sections in the te file.  The first section is the module command which identifies the name of the module and its version. This must be unigue, which is why I prefix "my" on my module names.  If I created a semanage module and one already existed the system would try to replace the existing module package with mine.  The last part of the module line is the version.  semodule has the ability to update module packages and will check the version versus the currently installed version.

The next block of the te file is the require block.  This is used to tell the policy loader semodule, which type, classes and roles are required to be already in the system policy before this module can be installed.  If any of these fields are undefined, the semodule command will fail.

Finally are the allow rules.  Now we could modify this line to dontaudit, since semodule does not need to access the file descriptor.

Why do we have to run the semodule_package command?

This command basically wraps up different policy files together in a policy package.  Usually just the module and potentially a file context file. The final step for the administrator is to load the policy package with the semodule command.

# semodule -i mysemanage.pp

This command will recompile the policy file and regenerate the file context file.  The changes are permanent and will survive a reboot.  Also the policy package file mysemanage.pp can be copied to other machines and installed using semodule.

Audit2allow shows you the commands it executed to create the policy package so you can edit the te file to add new rules if you want or change the allow to dontaudit. You could then recompile and repackage the policy package to be installed again.

There is no limit to the number of policy packages so you could create one for each local modification you want to make, or you could continue to edit one, but make sure your "require" statements match all of the allow rules.

cat loaded mudules


2006-11-29 10:01 am (UTC)

Is there a command to cat the content of a loaded module?
#semodule -l
local 1.0.0

How could I know what is "local" doing since I lost the file a long time ago?

Re: cat loaded mudules


2006-11-30 02:22 pm (UTC)

Excellent question. You have fired off the development team and expect a solution shortly.

Re: cat loaded mudules


2006-12-01 11:27 am (UTC)

Note that this is actually a real problem of mine :-)It would also be far easier to debug policies if you could see the actual policy loaded

Also, if you squint a little you can see how this can extend even further. If we see good usage, we can work with browser vendors to automatically ship these libraries.

> This must be unigue, which is why I prefix "my" on my module names

"mymysql"... :)

Can you target a single executable with a local policy?

Peter Klavins [getopenid.com]

2007-09-05 04:43 pm (UTC)

After following the steps to create a local policy for a new executable (from an rpm that I am developing) that complained about not being able to write a relocated shared library from a third party, the executable works. However, I worry about whether I haven't enabled all executables to relocate all shared libraries, because the contents of the .te file is simply:

module newexecutable 1.0;

require {
class file execmod;
type lib_t;
type unconfined_t;
role system_r;

allow unconfined_t lib_t:file execmod;

Is there a way of: 1) targetting the executable, or better, the directory containing the executables; 2) the particular shared libraries by the third party? I didn't want to chcon -t the third party shared libraries simply because they theoretically belong to a separate rpm installation that I shouldn't be modifying.

Peter K.

Re: Can you target a single executable with a local policy?


2007-09-05 06:37 pm (UTC)

In this case the simpler/better solution is to change the context of the library to textrel_shlib_t.

# semanage fcontext -a -t textrel_shlib_t PATHTOLIB
# restorecon PATHTOLIB

The policy that you added would allow most non confined applications to load any library file with execmod. So I don't think this is a good idea or what you had in mind.

The third option would be to write a policy for the executable that uses the shared library and give it the priv to execmod lib_t, or create a special context for this library and only allow the policy to execmod this library.

You should report a bug to the owners of the PATHTOLIB, with a link to

Re: Can you target a single executable with a local policy?


2007-09-05 08:06 pm (UTC)

Thanks for the quick response!

Yes, I accept that making PATHTOLIB textrel_shlib_t would solve the situation, but: 1) PATHTOLIB is supplied by a prominent commercial software company and I wouldn't like to tinker with their libraries for fear it would break their executables, which seem to operate fine without the need for textrel_shlib_t'ing their own libraries; 2) well, it's THEIR software and I don't want to change their installation anyway; and 3) if I disinstalled their software after doing the semanage fcontext, presumably the file context information relating to PATHTOLIB would be orphaned and not cleaned up.

So, I would like to stick to policies strictly related to my own executables and their installation and deinstallation scripts.

What would your third option look like, when applied only to my executable or directory of executables? How does a file or path name get entered into the .te file? Would I have to make my own MYEXECUTABLE_t type or category and thus have to supply more than just a simple .te file?

Peter K.

Org/IP/DRM/guide /) I recall the FBI warning saying something about not being able to reproduce if you were going to sell it.

Продаю сертификаты Вебмани.


2007-10-04 04:19 pm (UTC)

Продаю персональный сертификат WebMoney за $99.
Можете проверить: WMID 322973398779 Redfern
Всё чисто, не одной жалоб. Сделан на утерянные документы. Всё законно.
Если нужно, то есть сертификаты ещё.
Стучацо в личную почту на Вебмани.

Это не спам. Не пишите на мой WMID жалобы в арбитраж Вебмани.

Продаю сертификаты Вебмани.


2007-10-05 11:43 am (UTC)

Продаю персональный сертификат WebMoney за $99.
Можете проверить: WMID 322973398779 Redfern
Всё чисто, не одной жалоб. Сделан на утерянные документы. Всё законно.
Если нужно, то есть сертификаты ещё.
Стучацо в личную почту на Вебмани.

Это не спам. Не пишите на мой WMID жалобы в арбитраж Вебмани.

You are viewing danwalsh