SELinux Mandatory Access Control

Git daemon and SELinux with RHEL6

2011-08-23T11:10:00.000-07:00

RHEL6 does not ship with a manual page for configuring Git daemon SELinux policy, and so decided to publish a demonstration on youtube:

Part 1. Git system daemon, shared repositories.

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

Part 2. Git session daemon, personal repositories.

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

By the way you can look at the manual page (source) here:

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=blob;f=man/man8/git_selinux.8;h=e9c43b190c394f8ea7e68d9dd29f45c831340bf5;hb=ccadbe7d6ae709cdfd3b06d496477e069a2f13ee

selinux q&a

2011-02-08T14:22:00.001-08:00

23:15 < someone> What's the difference between httpd_sys_rw_content_t and
httpd_sys_content_rw_t?
23:19 < dgrift> none
23:19 < dgrift> their aliased
23:19 < dgrift> theyre

frequently asked questions: selinux booleans in detail.

2011-02-06T14:44:00.000-08:00

Q: "btw, anyone know if each of the selinux booleans are documented in detail somewhere?"

A: two levels of detail here:

1. semanage boolean -l | grep httpd_enable_homedirs
A written description (usually not very detailed) for the "httpd_enable_homedirs" boolean.

2. sesearch --allow -SC -T | grep httpd_enable_homedirs
All the "allow" type statement rules and type transition rules related to the "httpd_enable_homedirs" boolean. Very detailed but hard to interpret.

common issues -- part 1

2011-02-06T13:41:00.000-08:00

22:13 < _Tassadar> hi
22:14 < _Tassadar> http://fedoraproject.org/wiki/SELinux/samba <- i'm reading this document, on how to
configure selinux to allow samba to share a certain directory
22:14 < _Tassadar> now i'd like to share /data/files so i issued chcon -t samba_share_t /data/files
22:14 < _Tassadar> it worked, according to ls -Z
22:14 < _Tassadar> but access is still denied
22:15 < _Tassadar> should i recursively set that label to every file in the share as well?
22:16 < SwifT> _Tassadar: (without reading the file) check your AVC denials on what is actually denied, but I
would say "yes, you'll probably want to recursively set the type"
22:17 < _Tassadar> SwifT: what is the best way to check my AVC denials?
22:17 < _Tassadar> it's a server, i don't have any gui tools
22:20 < dgrift> _Tassadar: try Fedora manage confined services
22:20 < _Tassadar> hm no new entries appear in /var/log/audit/audit.log
22:20 < SwifT> _Tassadar: depends on your system log configuration; try tail -f /var/log/messages or
/var/log/audit.log
22:20 < _Tassadar> some stuff from cron appears every five mins, but nothing from smb
22:20 < dgrift> _Tassadar this is a common issue
22:20 < dgrift> its this:
22:21 < dgrift> youve created a new mountpoint called /data
22:21 < dgrift> selinux doesnt know that location
22:21 < dgrift> and so it labels it with a type: default_t
22:21 < dgrift> this is a type for locations unknown to selinux
22:21 < dgrift> and selinux silently denies access to type default_t
22:22 < dgrift> because it should not happen
22:22 < dgrift> all locations should be labelled properly
22:22 < _Tassadar> ah
22:22 < _Tassadar> i see
22:22 < dgrift> so how to fix it?:
22:22 < _Tassadar> with restorecon probably
22:22 < dgrift> well you should start by labelling /data
22:22 < dgrift> what type to label it, that depends on your requirements for /data
22:23 < _Tassadar> well it's all user data
22:23 < dgrift> var_t should probably do
22:23 < dgrift> i see
22:23 < _Tassadar> no binaries, no devices
22:23 < _Tassadar> lots of mp3's :)
22:23 < dgrift> whats in /data?
22:23 < dgrift> only dirs?
22:23 < _Tassadar> yes
22:23 < _Tassadar> /data/home/user1 /data/home/user2
22:24 < _Tassadar> /data/home/public_area
22:24 < _Tassadar> /data/public_area i mean
22:24 < dgrift> whats your distro?
22:24 < _Tassadar> Fedora 14
22:24 < dgrift> ok heres my suggestion
22:24 < dgrift> what is /data/home/user1 labelled?
22:24 < _Tassadar> nothing yet
22:25 < dgrift> but thats a user home dir?
22:25 < _Tassadar> drwx------. joe users unconfined_u:object_r:samba_share_t:s0 joe
22:25 < _Tassadar> well
22:25 < _Tassadar> i labelled it samba_share_t
22:25 < dgrift> ok
22:25 < _Tassadar> that's what the docs told me to do :)
22:26 < dgrift> what do you want?
22:26 < _Tassadar> well it doesn't work yet
22:26 < dgrift> what do you want with those dirs?
22:26 < _Tassadar> i would like the user to be able to mount his directory from a windows workstation
22:26 < dgrift> what is your requirement
22:26 < dgrift> i see
22:26 < _Tassadar> users are allowed read/write access to their own directories
22:26 < dgrift> and not use it locally?
22:26 < _Tassadar> and also in the public_area
22:26 < _Tassadar> no
22:26 < dgrift> ok
22:26 < _Tassadar> no shell access
22:27 < _Tassadar> no local processes are to be started from /data
22:27 < dgrift> so label /data root_t and the other dirs in there samba_share_t
22:27 < _Tassadar> recursively?
22:27 < dgrift> semanage -a -t root_t -f -d /data
22:28 < dgrift> semanage -a -t samba_share_t "/data/home(/.*)?"
22:28 < dgrift> restorecon -R -v /data
22:28 < dgrift> that will label the data dir root_t
22:28 < _Tassadar> nice
22:28 < _Tassadar> what does root_t mean?
22:28 < dgrift> and /data/home and all below it samba_share_t
22:29 < dgrift> it means it the type for filesystem roots
22:29 < dgrift> basically its accessable by all
22:29 < _Tassadar> oh okay, that makes sense in this case
22:29 < dgrift> see if it work
22:29 < _Tassadar> what would the -a option do?
22:29 < _Tassadar> my system doesn't know -a
22:29 < _Tassadar> oh
22:29 < _Tassadar> it does
22:29 < dgrift> oops
22:30 < _Tassadar> something else is wrong
22:30 < dgrift> non i made a booboo
22:30 < _Tassadar> okay
22:30 < dgrift> semanage fcontext -a -t root_t -f -d /data
22:30 < dgrift> semanage fcontext -a -t samba_share_t "/data/home(/.*)?"
22:30 < dgrift> restorecon -R -v /data
22:31 < _Tassadar> lol okay that could take a while
22:31 < _Tassadar> i'll run it without -v
22:31 < dgrift> hopefully it works for you
22:31 < dgrift> yes ok
22:31 < _Tassadar> it's a 11TB mount ;)
22:31 < dgrift> ouch....
22:31 < dgrift> all data on it?
22:31 < _Tassadar> yeah, no worries though, i'm not in a hurry
22:32 < _Tassadar> it's 60% used ;)
22:32 < dgrift> geez
22:32 < dgrift> i hope we get this right first time...
22:32 < dgrift> might want to test first
22:32 < dgrift> with a small dir
22:32 < _Tassadar> heh
22:32 < _Tassadar> i suppose so
22:32 < _Tassadar> ....
22:33 < dgrift> chcon -R -t samba_share_t /data/home/smalluserdir
22:33 < dgrift> chcon -t root_t /data
22:34 < _Tassadar> okay i'll try that
22:34 < dgrift> errr
22:34 < dgrift> its like this:
22:34 < dgrift> chcon -t root_t /data
22:34 < dgrift> chcon -t /data/home
22:34 < dgrift> err
22:34 < _Tassadar> ?
22:34 < _Tassadar> lol
22:34 < dgrift> chcon -t samba_share_t /data/home
22:34 < dgrift> chcon -R -t samba_share_t /data/home/smalluserdir
22:35 < dgrift> so three lines
22:35 < _Tassadar> yeah i understand, but restorecon is already running so /data and /data/home are already done
;)
22:35 < dgrift> because theres 3 dirs
22:35 < _Tassadar> i just tried with a small userdir and it works great !
22:35 < dgrift> ok
22:35 < _Tassadar> but, how do i keep everything neat
22:35 < _Tassadar> does restorecond do that?
22:35 < _Tassadar> i mean every time someone adds a file
22:36 < _Tassadar> it should get the right label immediately
22:36 < dgrift> it inherites the type of the parent dir
22:36 < dgrift> so should be fine
22:36 < _Tassadar> ah i see
22:36 < _Tassadar> so what does restorecond do then?
22:36 < dgrift> try it
22:36 < dgrift> well it watches directories for mislabelled files
22:36 < dgrift> but in your case its not applicable
22:37 < dgrift> because theres only one type
22:37 < _Tassadar> -rw-rw----. joe users unconfined_u:object_r:samba_share_t:s0 zzzzz.txt
22:37 < _Tassadar> yeah that works
22:37 < dgrift> samba_share_t
22:37 < _Tassadar> ah mislabelled, so not unlabelled
22:37 < _Tassadar> i understand
22:37 < _Tassadar> real 5m32.340s
22:37 < dgrift> well and unlabelled aswell
22:37 < _Tassadar> done :)
22:37 < dgrift> fast system
22:37 < _Tassadar> yeah :)
22:38 < dgrift> i should blog about this issue
22:38 < dgrift> its very common
22:38 < _Tassadar> definately
22:39 < dgrift> and people wonder why its not logging denials
22:39 < _Tassadar> yeah and the fact that audit.log doesn't show anything makes it hard to track for newbies like
me
22:39 < _Tassadar> exactly :)
22:39 < dgrift> can i use this chat log?
22:39 < dgrift> to publish?
22:39 < _Tassadar> errrr :)
22:39 < _Tassadar> i suppose

Yet another step by step introduction to policy development.

2011-01-24T06:35:00.000-08:00

Due to several requests for guides to writing SELinux policy i have decided to create another screen cast detailing how to create a policy for a user application, and some of the things that may help one get familiar with policy writing.

As per usual by now, it is just a amateur production for amateurs. These recordings are pretty boring and long. I do advise that you view the whole thing in the proper order. Because things may not be explained well all the time, but most of it should become more clear in the course of the series.

Sometimes i make mistakes that i later notice. By the end of the series everything is pretty much sorted out (except atleast one pretty minor issue that i consider as an exercise to the watcher to troubleshoot and solve).

Also note that i encountered a conflict with restorecond -u (run in a gnome-session) with regard to labelling a file in the user home directory. I worked around that issue, but it will work fine when one logs out and back in, when it occurs.

part 1. Setting up an optimal environment for policy writing and in the mean time i explain my view on policy writing and every aspect of it.

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

part 2. Do it yourself: create a simple script and write raw policy for it. Introduction to type transition, allow, dontaudit and other type statements. A start at translating raw policy that SELinux understands into policy that is maintainable and readable by humans and that is scalable in a modular environment.

http://www.youtube.com/watch?v=G5gUt1-ttGg

part 3. Proceed with translation of raw policy to m4 macro language powered policy. Merge our loadable policy module into upstream tresys reference policy.

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

part 4. troubleshoot remaining issues and fix them.

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

If you have specific question with regard to the series above feel free to ask for clarification.

Note to self: all the stuff a pulseaudio client needs.

2010-12-16T03:08:00.000-08:00

basically i figured out about three scenarios so far:

1: The basics.
Pulseaudio is running normally, and the pulseaudio client needs to make some sound i guess

# manage a pulse-shm file in /dev/shm
manage_files_pattern($1, $2_tmpfs_t, $2_tmpfs_t)
fs_tmpfs_filetrans($1_t, $2_tmpfs_t, file)
fs_getattr_tmpfs($1_t)

# allow the user of the app to manage and relabel that file as well
allow $3 $2_tmpfs_t:file { relabel_file_perms manage_file_perms };

# 1. This add an attribute to the pulse client process so that i can allow each pulse client progress to signull any other pulse client process
# 2, This also adds an attribute to the pulse client tmpfs file so that i can allow each pulse client to read write and delete any others pulse client tmpfs file.
gnome_pulseaudio_client($1, $2)
# read write pulseaudio files in ~/pulse (a directory that is actually owned by gnome settings daemon)
gnome_rw_gsettingsd_pulseaudio_files($1)
# read gnome settings daemon home content for example some symlink in ~/.pulse to a pulseaudio sock file
gnome_read_gsettingsd_home_content($1)
# connect to pulseaudio with a unix stream socket
gnome_stream_connect_gsettingsd_pulseaudio($1, $2)
# search /tmp/pulse-*
gnome_search_gsettingsd_tmp_dirs($1)
# set attributes of ~/.pulse directory
gnome_setattr_gsettingsd_home_dirs($1)

# manage /.cache sound-event-cache files.
xdg_manage_generic_user_cache_files($1)

2: The not so basics.
These pulse client seem to be required to be able to (re) start the main pulseaudio process as well in some particular cases)

# domain transition to the gnome settingsd daemon pulseaudio domain when pulseaudio is executed.
gnome_spec_domtrans_gsettingsd_pulseaudio($1, $2)

3: When pulseaudio is not running.
When you kill pulseaudio and run a pulseaudio client app. It, i guess, expects some pulse audio network functionality because pulse is not running on the local system.

# the pulse client is trying to find pulseaudio on the network i guess...
allow $1 self:netlink_route_socket r_netlink_socket_perms;
allow $1 self:tcp_socket create_socket_perms;
allow $1 self:unix_dgram_socket sendto;

corenet_all_recvfrom_netlabel($1_t)
corenet_all_recvfrom_unlabeled($1_t)
corenet_tcp_bind_generic_node($1_t)
corenet_tcp_sendrecv_generic_if($1_t)
corenet_tcp_sendrecv_generic_node($1_t)
corenet_tcp_connect_pulseaudio_port($1_t)
corenet_tcp_sendrecv_pulseaudio_port($1_t)
corenet_sendrecv_pulseaudio_client_packets($1_t)

# if that isnt enough, the pulseaudio client wants to be a dbus system bus client. Dont ask me why but
its probably looking for pulseaudio run as a dbus system domain or init daemon.
dbus_system_bus_client($1)

..Heck it may even need more like maybe sysnet_read_config, i have not been able to confirm this yet.

The amount of access(policy) a simple gui application needs to be able to spit out a sound with pulseaudio is simply amazing.

My Fedora 14 policy for the adventurous.

2010-11-29T11:22:00.001-08:00

My Fedora 14 policy for the adventurous.

I have been working on a policy for Fedora 14. Three different policies actually. One for a minimal fedora installation (--nobase), one for a minimal fedora installation with libvirt and a policy for a minimal gnome desktop system.

The minimal policy for Fedora 14 gnome desktops is the interesting one. It aims to confine the gnome desktop on workstations. That means it supports almost none system services, excepts the base essentials. It does not have policy for any mail servers, it does have policy for ssh and even httpd. Http policy because gnome-user-share relies on it (dav)

What it lacks in system services it makes up for in application domains. That is to say it supports some gnome apps, and the user apps that do not have policy should be able to make to work by toggling the gnome_$1_targeted boolean where $1 is your user role prefix. Caution though that this hasnt been tested yet because my sole priority lies with a confined gnome, and this is enough work as is.

There are atleast some things to do if one decides to give it a spin.

One should add the following directories to /etc/skel:
.config
.config/enchant
.config/gtk-2.0
.cache
.local
.local/share
.gnome2
.gnome2/accels

One should also modify /usr/share/dracut/modules.d/98selinux/selinux-loadpolicy.sh

comment out:

mount --bind /dev "$NEWROOT/dev"
chroot "$NEWROOT" /sbin/restorecon -R /dev

..and then use dracut to build a new initramfs for your current kernel.

Also fix /root:

semanage fcontext -a -e /home/joe /root
restorecon -R -v /root

Typically you would:

setenforce 0
rpm -ev selinux-policy selinux-policy-targeted
rpm -Uvh selinux-policy-2.20100524-1.fc14.noarch.rpm selinux-policy-bare_gui-2.20100524-1.fc14.noarch.rpm
edit /etc/selinux/config and set selinux back to enforcing and point to bare_gui instead of targeted
relabel the file system
best to add a new user (make it staff_u as its user_u by default (sorry no unconfined_u in this policy by default)
make sure to add the user to sudo:
echo "joe ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL" > /etc/sudoers.d/joe
chmod 0440 /etc/sudoers.d/joe
reboot

This policy confines all domains. also kernel_t and rpm_t. installation of packages and updting of packages should probably be done in permissive mode for now because the rpm domain needs some more loving. (common packages will work but dont try to install a kernel in enforcing mode or some service that gets restarted in the post-install script.

As said, this only works with gnome if it works at all (dont worry i am using it on my desktops) but only try this if youre a bit familar with selinux, are feeling adventurous and if you dont panic quickly.

By default the minimal gnome environment is confined. Gnome apps by default arent allowed to interact with users and often arent allowed to run generic applications. For example the printer applet currently is not confined (i dont like printing its a waste of paper and ink), thus gnome will not be able to run the printer applet until a policy for it is implemented.

The idea is that gnome can easily be allowed to interact with these generic apps and be allowed to communicate with users by toggling the gnome_$1_targeted boolean. However this is still untested.

Youll notice that youll have to unlock youre gnome keyring on each login. I am not sure why but gnome keyring daemon or whatever runs it (probably dbus, maybe xdm?) tries to manipulate selinux into running in the user domain which i forcefully prevent so that it can be made to run confined.

If something is confined then youll be able to run it in a confined environment with gnome_$1_targeted boolean set to off, Else you wont be able to run it untill some policy for it gets implemented.

The apps you are able to run may not be confined perfectly yet for all use cases (its a lot of work).

Stuff that works for me:

a lot of default gnome apps/applets/session services

totem
rhythmbox
evince
compiz
gedit
terminator
screen
mutt
irssi
firefox
thunderbird
eclipse
vinagre
empathy/telepathy
gpg
metacity
nautilus
gnome schedule
seahorse

Stuff that is not supported (atleast):

hal
mlocate

So one should be able to do some of the basics.

Why confining the desktop? Not so much to protect generic user content. I use to think this is important but as my policy evolved i discovered that the important thing here is the integrity of gnome and user apps.

For example: protect access to your keyring, gpg data, ssh data, firefox data etc.

Not protecting access to your generic ~/.porn directory

So how would you get started?

We you can get a tar ball of a recent snapshot here:

http://217.19.30.59/~dgrift/stuff/

Just put the tarball in your ~/rpmbuild/SOURCES directory. Extract the support/selinux-policy.spec from the tarball and put that into ~/rpmbuild/SPECS/
then just rpmbuild -ba ~/rpmbuild/SPECS/selinux-policy.spec
it will spit out 3 packages by default (bare_gui and its docs package) which you can install. You do not require the docs rpm but installing it doesnt hurt either.

If you want to try the bare or bare_virt model you can do so by editing the selinux-policy.spec and set the %define for that model to 1. it will build an rpm for that aswell.

Remember, expect plenty boogs i would love to receive some feedback or even help in improving the policy. It is a lot of work but the concept is very powerful. By confining the layer between the user and the system (the desktop) we achieve a lot more flexibility. We can then define what each user domain can and cannot do by simply implementing a boolean.

The idea about the bare and bare_virt models is that its strict, the unconfined module is install but not used. Another important property of bare and bare_virt is small footprint. It only installs the bare minimum modules which keeps the policy small. if one decides to run a service that is not currently supported in bare or bare_virt then one can use loadable module to implement it. The policy is focussed on advanced administrators that value small foot print and want total control over have gets installed and what not.

Questions comments? domg472 at gmail dot com

Some background information:

the policy is based off of recent refpolicy. refpolicy aims the be a base for basically any kind of model. Unfortunately i had to edit refpolicy atleast to remove unconfined_domains ( i think refpolicy probably shouldnt have unconfined domains as its easier to add and unconfined domain than to remove one) also i had to remove and/or redo most of refpolicies user application policies. I think it may be better for refpolicy to ignore user application policies or atleast prefix them all. domains like ssh_t arent helpful in a confined user space, as a confined user space relies heavily on user role prefixes.

Why not base it on fedora policy?

All of the above discussed issues apply, plus. Fedora tends to avoid issues by adding modules to base. This causes problems. My policy only has modules in the kernel layer in base all other modules can be disabled in theory. Fedora focusses on usability. little things like easily allowing access to all user content makes it hard to confine the user space.

user home directory contexts

2010-08-07T11:05:00.000-07:00

Some where in this commit: 0bf4290c235b514c39ed9c8d3f3f2fbb95f60cfa ( in one of the file context specifications there ) is something that makes and breaks whatever creates the per user home directory contexts.

Without it, semodule (what use to be genhomedircon?) only creates contexts for the "__default__" login.

It took me almost a day to narrow it down to this. I would like to know which file context specification exactly is causing it and why

The advantages and disadvantages of domain prefixes.

2010-08-05T14:22:00.001-07:00

I am trying to merge restricted xwindows users and common users. The idea is to make them both use the same policy and be able to lock down what we know as user_t to a restricted user that we know as xguest by toggling booleans. That will make it easier to adept user environments to meet your requirement. You do not have to write custom policy. Simply enable/disable the functionality that you need with booleans and go.

To achieve this i use the good old per_role_templates. We used to use them for role based separation, But once user based separation was introduced there seemed to be not much use to these templates any more. However the domain prefixes used in the per role templates can play an important role in enabling and disabling functionality for different users using the same policy. We can use the domain prefix to define tunable policy.

user joe is allowed to access the network via his web browser. User jane can only access the network with her favourite game. Both use the same policy but have different booleans toggled.

But consider this: joe is allowed to use the browser. The browser can use stuff like java, flash, a video player, email client etc. Its not joe directly run those its the browser running it for joe. So how is it achieved that when it is allowed that joe can use the web browser, that joe can also watch a video clip via his web browser. Or that joe is not allowed to watch video via his browser but some other user is permitted that.

This, i believe can be achieved by called per_role_templates in per_role_templates.

I tried this before in more than one ways and always stumbled on duplicate declarations or out of scope issues. Today i tried a different approach. To avoid duplicate declarations i decided to try and split the per_role_templates into templates for policy and for declarations. The declaration per role templates should only be called by user domains. Whilst the policy per role templates can additionally be called by other policy per role templates. This way booleans, types and attributes are declared once but can be used more than once. For example user X can connect to a streaming port if he runs totem, but he can also connect to a streaming port if he runs totem via his browser. The same can be done for things like java, gpg, flash, web browsers, you name it

Another thing i have to deal with is xserver duplicated declarations, and so i also split those declarations for the policy and added the declaration interface to the per role declaration template for the various applications and the policy to the per role policy template.

This stuff becomes important if you truly want to confine the user space. Take for example nautilus. If you click on a video file in nautilus. How does the SELinux know who did it and thus who's policy to apply? All it knows is that nautilus ran the video file and nautilus is not a user its an application. There are may more such examples. Domain prefixes can help here.

There are also issues with calling per role templates from per role templates. Consider this. You can click on a web url in an E-mail message and you can also use the E-mail client from the web browser. So you called the E-mail per role template from the browser per role template, and you call the browser per role template from the E-mail per role template. This will get you into a loop that never ends. You can wait until you way less than a ounce and policy will still not finish compiling. So that is a issue to consider.

Just to show you what a per role declaration template for a GUI app would look like:

########################################
##

## Role access for mozilla declarations.
##

##
##

## Prefix to be used
##

##
##
##

## Role allowed access
##

##
#
interface(`mozilla_declarations_role',`
gen_require(`
attribute mozilla_domain;
type mozilla_exec_t;
')

##
##

## Allow Mozilla to execute anonymous memory (execmem))
## files.
##

##
gen_tunable(mozilla_$1_execmem, false)

##
##

## Allow Mozilla to read all user home.
## files.
##

##
gen_tunable(mozilla_$1_read_content, false)

##
##

## Network access for mozilla.
## files.
##

##
gen_tunable(mozilla_$1_network_connect, false)

type $1_mozilla_t, mozilla_domain;
application_domain($1_mozilla_t, mozilla_exec_t)
ubac_constrained($1_mozilla_t)

role $2 types $1_mozilla_t;

xserver_object_types_template($1_mozilla)
')

I am aware that this is a pretty dirty hack, and i am not even sure if this indeed works out the way it appears, but i am just glad and hopeful that it does.

About dbus_connect_session_bus and dbus_session_domain. (and other interfaces that include the dbus_session_type attribute)

2010-07-25T08:51:00.000-07:00

These interfaces currently use the session_bus_type attribute in Fedora.
The problem is that all restricted xwindows and the unconfined users have this attribute assigned to their dbus domain.

Take for example telepathy, which is a framework that is started by dbus session domains. If you use the dbus_session_domain() interface to start telepathy processes, then this means all restricted xwindows and the unconfined users automatically transition to the telepathy domains when they run telepathy programs from their dbus domains.

Same goes for the dbus_connect_session_bus() interface in terms of which process that acquire service to which dbus session domains.

In my branch i went ahead to try and fix this. Instead of using the session_bus_type attribute i use $1_dbusd_t type instead. This way i can define which dbus session can start a program that needs to be started by session dbus domains.

The problem is that the compiler does not like and permit this. You will run into duplicate declaration issues of the dbus session type ($1_dbusd_t).

There is a way out of this but it is an ugly work around: Call the interfaces described above in the same optional policy block as where the dbus_role_role is called from.

By the way: i do not see how dbus can be considered optional.

The end result is that domains started by dbus session domains can not be optional and should be compiled into the base module.

Which programs am i talking about? For starters Gnome. Stuff like Gnome configuration daemon, settings daemon, keyring daemon, VFS daemon etc. Then Telepathy, Empathy, Gnome DVB daemon, Vino and who knows what else.

Also: The dbus_session_bus_client is, in my view, too coarse. It also uses the session_bus_type attribute, allowing the caller to send DBUS messages to all dbus session domains and allowing the caller to stream socket connect to all dbus session domains.

This is what i am currently using for the two interfaces described above (i left other interfaces affected by dbus_session_type in the current state for now)

########################################
##

## Connect to the specified session BUS
## for service (acquire_svc).
##

##
##

## Prefix to be used.
##

##
##
##

## Domain allowed access.
##

##
#
interface(`dbus_connect_session_bus_to',`
gen_require(`
type $1_dbusd_t;
class dbus acquire_svc;
')

allow $2 $1_dbusd_t:dbus acquire_svc;
')

########################################
##

## Allow a application domain to be started
## by the session dbus.
##

##
##

## Domain allowed to transition.
##

##
##
##

## Type to be used as a domain.
##

##
##
##

## Type of the program to be used as an
## entry point to this domain.
##

##
#
interface(`dbus_session_domain',`
gen_require(`
type $1_dbusd_t;
')

domtrans_pattern($1_dbusd_t, $3, $2)

dbus_session_bus_client($2)
dbus_connect_session_bus($2)
')

Moral of this article: I would be nice if we came up with a proper solution for the issues i described.

My branch is "hacked" in a way that it works for a large part but it means that my branch diverged even further from upstream than it already did...

As always: Changes i have made can be reviewed in my Git repository.

My thoughts on the user domain.

2010-07-17T00:37:00.000-07:00

- Unconfined_t users are unrestricted except: exec{mod,heap,stack,mem}. They stay in the unconfined domain wherever possible. Sometimes they transition to other unconfined domains. This is only done for the type transition functionality. (to make sure objects get created with the right types)

- Common users are restricted in the sense that they transition to restricted domains where possible. Besides that, common users should be limited in their functionality as little as possible. They should be able to do anything a normal Linux user can do except run setuid applications. Common users can be divided into the following:

user_u: plain common user. should "feel" unrestricted, but domain transitions wherever possible. Also can not run setuid applications.

staff_u: main difference with user_u is that staff users CAN run setuid applications.

sysadmin_u: should be able to do most everything a normal root can by domain transitioning wherever possible.

- Restricted users/restricted Xwindows users, domain transition where ever possible but can only do what they should be able to do. Thus by default the restricted user templates should have limited functionality. Ofcourse these user can not run setuid applications either. Examples of restricted users are.

guest_u: least privilege restricted login users with only access via ssh, no network access. no setuid.
xguest_u: least privilege restricted login users with only access via xdm. no network access. no setuid.

These restricted users are almost never tailor made for a specific need. (although xguest is currently modified to be allowed more then it should by default in my view)

Basically one would modify restricted users and restricted xwindows users to allow then exactly what they need plus/minus some policy that is tunable on the fly.

- Base users: Are even more limited than restricted users. They also cannot manage any user content. They are a base for task specific roles. privileged or unprivileged. Same as with restricted users these base users need to be tailored because by default all you can do is sudo to them (if you have access to setuid)
Examples of base user usage is: webadm, dbadm

What got me to blog about this? As staff user i was able to run traceroute in the staff_t domain. I was under the assumption that i should have domain transitioned and that user_ping boolean would have denied access.

Looking closer in the netutils policy i found conflicting rules. There were conditional transition interfaces available (using user_ping condifition) and there was main tunable policy where ping and traceroute are not able to use terminals if user_ping is set to false. This got me curious. Should this apply to common users? The answer in my view is: no.

Common users should always be able to run traceroute and ping but they should domain transition to the respective domains to do so.

That leaves us with the conditional interfaces. They can be used with restricted users. If you want to design a restricted user with permission to ping or traceroute on the fly, then you can use these booleans. They are not implemented into the restricted user templates by default because this is not core functionality. plus you may want to use this boolean for one class of restricted users but not for another class.

I ended up, removing the tunable_policy from the netutils type enforcement source policy file.

The conclusion i take away from this and other experiences is that there is some confusion about how the various user domains should behave. Over time , the user domain templates have become inconsistent (at least in Fedora.

Some other examples are that base users can run all applications and can run usr_t files.

Rethinking interaction with user content.

2010-07-13T10:42:00.000-07:00

In the user space there is often a lot of policy to write that defines how users can interact with user content. We usually use the role templates for this. If an confined app create user home, tmp and tmpfs content. We have to allow the user running the app to manage and relabel this content as well.

In Fedora a start was made to simplify this a bit. Users that have access to the userdom_manage_home_role template are able to manage and relabel any content that is declared userdom_user_home_content. This way we do not have to explicitly define that a user can manage/ relabel some confined apps user home content. Less policy to write. Fedora has this idea only implemented for user_home_content and not for user_tmp or tmpfs_content.

The userdom_manage_user_home_role is an old template that dates back to the time when we used roles to separate access to content. Also Fedora combines policy to manage/ relabel and do a bunch of other stuff in this single template. This is not really tidy.

Ive been wanting the idea that Fedora implemented for user home content, for user_tmp and tmpfs content as well. It might save me from writing more policy then strictly required. Hopefully also for pulseaudio which requires processes to manage files on tmpfs. Each application that uses pulseaudio needs to be able to read and delete every other apps pulseaudio tmpfs file, and then send a null signal that the application that owned the tmpfs file it deleted or read. A LOT of policy, which i am hoping to simplify.

There are some things to consider as well. We have different classes of users. We have unconfined users, which obviously should be able to manage all user content. We also have confined common users. These users are restricted but should behave as normal Linux users as much as possible. Thus should also be able to manage and relabel all user content.

Then there are the restricted users. These users have least privileges required. There are two kinds of those. restricted users and restricted xwindows users. An example of an restricted user domain is guest_t, and an example of an restricted xwindows user is xguest_t.

restricted xwindows users need to be able to manage and relabel user content like pulseaudio tmp, tmpfs and user content. And content like Gnome content, Gconf, Window manager, home bin,cert,video, audio etc.

normal restricted users like guest only need to be able to manage generic user content.

Xguest_t also needs some special permission besides the basic restricted xwindows permissions, namely managing and relabelling mozilla_user_content and nsplugin_user_content. and since mozilla_t can transition to for example totem_t, these users should also be able to manage totem user content for example.

So i started by declaring three attributes: user_home_type, user_tmp_type and user_tmpfs_type. These attributes get assigned to all user content. So if an user app manages a file in home, then the type of that content is assigned the user_home_type attribute. If it manages a file on tmpfs it gets assigned the user_tmpfs_type attribute and if it manages a file in tmp the type of that content gets assigned the user_tmp_type attributes. This is done in the userdom_user (home,tmp,tmpfs) content templates which should be used if a type for that purpose is declared.

I have replaced the userdom_manage (home.tmp,tmpfs) role templates by templates that differentiate between generic user content and all user content. If have also separated the manage, relabel and file transition permissions.

The way i plan to use this is as follows: The userdom_login_user_template is shared by all login users (except unconfined users in fedora) So that means both common and restricted users. Therefore, if i add the userdom_manage_all_home_content template call there then that would mean that restricted users can manage all user content. Not what i want. Instead i will add permission to manage relabel and file transition to generic user content to this template. For common users i additionally plan to add permissions to manage and relabel all user content. Unconfined users also get access to manage and relabel all content in the unconfined user module obviously.

Next thing i plan to do is to extend the restricted_xwindows template to permit managing and relabelling of content that is required for GUI interfaces like gnome content etc.

Permissions specific to xguest like managing mozilla user content (xguest is permitted to un firefox in the mozilla_t domain) etcetera will be added to the xguest module.

With this i hope to achieve that i can simplify user content and at the same time keep privileges as tight as possible.

If you want to see what i have implemented of above thus farm have a look in my Git repository. Use Git log/show to find and review the related commits.

Targeted configured semi-strict with UBAC for Fedora/Redhat distros.

2010-07-12T02:06:00.000-07:00

I am maintaining an SELinux policy that is based off of Fedoras' SELinux policy and it aims to merge changes refpolicy as much as possible. It use to have only rather minor differences compared to refpolicy and Fedora but lately it has been diverging pretty much. The source policy is available in my personal shared Git repository and depending on my time it is updated pretty often. I aim to merge any Fedora and refpolicy updates as much as possible as soon as possible. In theory it is latest Fedora policy with refpolicy changes and my own changes. In practice its Fedora plus/minus some bugs/features that i introduced.

The main property of my policy is that, besides the usual, it aims to confine the user space by default.
As opposed to Fedora, my policy has user based access control enabled. This feature aims to isolate selinux users. In practice it has some rough edges and gothas but it is worth it. So one of the issues is that one has to make sure that the selinux identity field in the security context tuple of user home directories is labeled properly. This is a problem when you add new users. So if a new user is added one should chcon -R -u newuser_u /home/newuser. The second issue is system administration. In my policy, root is mapped to sysadm_u selinux identity, but usually logins as root are not encouraged, and so one logs in as staff_u and then role transitions to either sysadm_r or unconfined_r. This means that you will be root in a sufficient domain but with a ubac constraints. Fortunately unconfined_t has access to the system_r role and can use runcon to run commands using the system_u selinux identity. This is required for many sysadm commands. Example: runcon -u system_u useradd joe.

My policy installs with root mapped to the selinux identity of root but the root selinux identity does not have default contexts for unconfined. Meaning root cannot login as unconfined_t. Root logs in, in the sysadm_t domain. That should be sufficient. On installation the unconfined module is disabled. It can optionally manually be enabled after installation. updating policy will not try to disable it again if you did. The unconfined_u selinux user mapping was removed by default. You can manually add it if required but my policy does not encourage unconfined logins. This is also why unconfined_login boolean is set to false by default.

Users that need to have access to privileged domains and dacs root should be mapped to staff_u. These users should use sudo to change to root and to role transition:

echo "joe ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL" >> /etc/sudoers

My policy adds some confinement for some user apps. Most notably currently:
firefox, nsplugin, totem, telepathy, mutt, thunderbird, elinks, irssi, metacity, gnome dvb, seahorse-daemon, vino_server and others.

So it is targeted policy that is configured in a semi strict fashion. unconfined logins by default are prohibited but the unconfined role/domain can be used as an replacement for sysadm_r/sysadm_t to use with sudo. Also the policy has selinux user isolation, so the various selinux users cannot interfere with eachother.

To make an rpm of my policy is pretty straight forward on fedora.
You can clone my refpolicy repository:

git clone git://217.19.30.59/refpolicy.git

or update it after you cloned it:

cd refpolicy; git pull

(Mind you that my IP address is dynamic. It does not change often but it can change. Just "/whois" me on irc.freenode.org to get my current IP address and use that.

To determine my main policy version either look at the tags or see "Version ; .." in the spec file in "redhat/selinux-policy.spec"

Replace the version number with the version number in the following commands:

git archive --format=tar --prefix=refpolicy-3.8.6/ refpolicy | gzip > ~/rpmbuild/SOURCES/refpolicy-3.8.6.tar.gz

git diff refpolicy master > ~/rpmbuild/SOURCES/refpolicy-3.8.6.patch

Make sure the path exists (install rpmdevtools) run rpmdev-setuptree.

Next copy the redhat/selinux-policy.spec from the Git repository:

cp redhat/selinux-policy.spec ~/rpmbuild/SPECS/

And build the packages:

cd ~/rpmbuild/SOURCES/; rpmbuild -ba ../SPECS/selinux-policy.spec

If you're installing my policy for the first time. e.g. if your current installed policy is stock redhat/fedora policy, then it is encouraged to start clean.

This means you will lose any modifications that you may have made:

setenforce 0
yum erase selinux-policy selinux-policy-targeted
mv /etc/selinux /etc/selinux.backup
yum install selinux*.rpm (the build rpms)
touch /.autorelabel && reboot

on reboot login as root, you should be in sysadm_t domain and you should be able to add/ fix your login user mapping to staff_u. Once youre login user is mapped to staff_u be sure to fix your login users home and tmp directories context:
semanage login -a -s staff_u -r s0-s0:c0.c1023 joe
chcon -R -u staff_u /home/joe
chcon -R -u staff_u /tmp/joe
chcon -R -u staff_u /var/tmp/joe

That should be sufficient.

If pulseadio does not start, then remove ~/.esd_auth ~/.pulse /tmp/.esd* and relogin or restart pulse.
Also you may when you first log in get AVC denials for stuff like metacity trying to access ~/.config (staff_wm_t -> user_home_t), and maybe others as well, ignore it. This is because that directory and others at that point are not restored yet. restorecond -u runs in a gnome-session and should have restored your home directory contexts in the mean time.

Be prepared to stumble on bugs, issues etcetera. Feel free to contact me if you have questions or comments. Patches welcome.

I am using this policy myself on two desktop systems (fedora13/Gnome) and several headless servers.

Warning: Only consider trying this if you are familiar to, and not intimidated by SELinux.

About apache_content_template

2010-02-14T13:29:00.000-08:00

In refpolicy there are about eight modules that have calls to apache_content_template in their private policy. These template calls are located in optional policy blocks. This is so that these modules do not depend on the apache module being present.

The problem is that seven out of these eight modules have file context specifications containing a executable type, that is declared in the apache content template, in their file context file. As far as i know file context specifications are never optional.

So even though calls to apache content template are optional, they really aren't because the file context specifications that accompany them are not optional.

This means that eight modules depend on the apache module being installed. Try to de-install the apache module (semodule -r apache) and you will be presented with some very unclear errors. Most people will not know what to do.

So how can we fix that?

Well here is an example. We use the apache_cgi_domain() instead:

########################################
#
# BackupPC admin private declarations.
#

type backuppc_admin_t, backuppc_domains;
type backuppc_admin_exec_t;
domain_type(backuppc_admin_t)
domain_entry_file(backuppc_admin_t, backuppc_admin_exec_t)
role system_r types backuppc_admin_t;

########################################
#
# BackupPC admin private policy.
#

optional_policy(`
apache_cgi_domain(backuppc_admin_t, backuppc_admin_exec_t)
')

/usr/share/BackupPC/sbin/BackupPC_Admin -- gen_context(system_u:object_r:backuppc_admin_exec_t, s0)

This way we can make the call to apache_cgi_domain() *really* optional. It is a bit more work initially but in my view this is maintainable unlike apache_content_template.

Test Git daemon policy.

2010-01-14T01:41:00.000-08:00

Clone my latest selinux-modules git repository:

git clone git://84.245.6.206/selinux-modules.git
cd selinux-modules && make -f /usr/share/selinux/devel/Makefile gitd.pp
semodule -d git; semodule -i gitd.pp
cp gitd.if /usr/share/selinux/devel/include/services/gitd.if

To test the Git session server you should build a custom module calling the gitd_session_role template for your role:

echo "policy_module(mygittest, 1.0.0)" > mygittest.te;
echo "optional_policy(\`" >> mygittest.te;
echo "gen_require(\`" >> mygittest.te;
echo "# Assuming you want to test as unconfined_t" >> mygittest.te;
echo "type unconfined_t;" >> mygittest.te;
echo "role unconfined_r;" >> mygittest.te;
echo "')" >> mygittest.te;
echo "gitd_session_role(unconfined_r, unconfined_t)" >> mygittest.te;
echo "')" >> mygittest.te;

make -f /usr/share/selinux/devel/Makefile mygittest.pp
semodule -i mygittest.pp

Make sure that port tcp:9418 open and that tcp-wrappers is configured to accept connectivity on this port.

install git-daemon and its dependencies: yum install git-daemon.

You must edit /etc/xinetd.d/git. set "disable" to "no", "server" to "/usr/libexec/git-core/git-daemon", and remove the "daemon" argument from "server_args". Keep an eye on /var/log/messages in case it behaves strange.

Restore the following contexts:

restorecon -R -v /var/lib/git
restorecon -v /usr/libexec/git-core/git-daemon
restorecon -v ~/.gitconfig
restorecon -v ~/public_git

Start xinetd: service xinetd start.

Set up a default git shell user for generic shared repositories:

groupadd git
useradd -Z git_shell_u -M -s /usr/bin/git-shell joe
usermod -a -G git joe
passwd joe

Set up a bare "test" shared repostory:

mkdir /var/lib/git/test.git
cd /var/lib/git/test.git && git --bare init
chown -R root:git /var/lib/git/test.git
chmod -R g+w /var/lib/git/test.git
chmod -R g+s /var/lib/git/test.git
chmod -R +t /var/lib/git/test.git

From your "normal" user account clone the bare repository:

git clone git://localhost/test.git
cd test

Make changes to it:

echo "test" > test;
git init
git add .
git commit -a -s -m "My initial commit."

As user "joe" push to the shared repository:

git push --all git+ssh://joe@localhost/var/lib/git/test.git
git pull
git status
git show

Testing Git session:

Stop xinetd and in your "normal" (we are done with "joe" for now) user home directory make sure ~/public_git exists.
restorecon -R -v /public_git
Previously we called a "gitd_session_role" template for users operating in the unconfined_t domain. This means when your id -Z returns: unconfined_u:unconfined_r:unconfined_t:s0, git with the daemon option will run in a Git session SELinux environment for you.

Create a new personal repository in ~/public_git:

mkdir ~/public_git/hello
cd ~/public_git/hello
git init
echo "hello" > hello
git add .
git commit -a -s -m "My initial commit."

Serve your personal repository with the following command:

git daemon --export-all --user-path=public_git

In another terminal clone the repository:

git clone git://localhost/~yourloginnamehere/hello

Make a commit to it:

cd hello
echo "bye" >> hello
git commit -a -s -m "Add good bye"

Push the change to your personal repository:

git push --all ssh://yourloginnamehere@localhost/~/public_git/hello

Hosting personal repositories with Git system daemon.

Stop your Git session daemon (ctrl-c) and start xinetd.

Set the boolean to allow the Git system daemon to search user home directories for personal Git repositories to serve:

setsebool gitd_system_enable_homedirs on

Now clone the personal repository again:

git clone git://localhost/~yourloginnamehere/hello
cd hello
echo "hi" >> hello
git commit -a -s -m "Added Hi."

And push to the personal repository:

git push --all ssh://yourloginnamehere@localhost/~/public_git/hello

Create a customized Git Shell user that has access to a restricted shared repository (besides having access to any generic system repositories) Also create a restricted repository and allow our created Git shell user access to this new restricted repository.

echo "policy_module(secret_git_shell, 1.0.0)" > secret_git_shell.te;
echo "gitd_role_template(secret_git_shell)" >> secret_git_shell.te;
echo "gitd_content_template(secret)" >> secret_git_shell.te;
echo "gitd_content_delegation(secret_git_shell_t, gitd_secret_content_t)" >> secret_git_shell.te;
echo "gen_user(secret_git_shell_u, user, secret_git_shell_r, s0, s0)" >> secret_git_shell.te;

echo "/var/lib/git/secret\.git(/.*)? gen_context(system_u:object_r:gitd_secret_content_t, s0)" > secret_git_shell.fc;

make -f /usr/share/selinux/devel/Makefile secret_git_shell.pp
semodule -i secret_git_shell.pp

Create a secret Git shell user:

useradd -Z secret_git_shell_u -M -s /usr/bin/git-shell jane
usermod -a -G git jane
passwd jane

Create a bare secret shared repository:

mkdir /var/lib/git/secret.git
cd /var/lib/git/secret.git && git --bare init
chown -R root:git /var/lib/git/secret.git
chmod -R g+w /var/lib/git/secret.git
chmod -R g+s /var/lib/git/secret.git
chmod -R +t /var/lib/git/secret.git

Restore the context of the secret repository:

restorecon -R -v /var/lib/git/secret.git

Everyone can read it but only jane can push to it. As a "normal" user clone the secret repository.

git clone git://localhost/secret.git
cd secret
echo "secret" > secret
git init
git add .
git commit -a -s -m "My first commit."

Push it as user "jane"

git push --all git+ssh://jane@localhost/var/lib/git/secret.git
git pull
git status
git show

Make another commit:

echo "Joe here" >> secret
git commit -a -s -m "add Joe here"

Now try to push it as user "joe" (joe can push generic shared repositories but joe is not allowed to push to the secret repository)

git push --all git+ssh://joe@localhost/var/lib/git/secret.git

Git daemon, SELinux and Fedora 12 Beta.

2009-10-21T01:45:00.000-07:00

Recently i decided to redo my Git daemon domain and reinstall a Git daemon server.

This article will explain the issues i had to consider.

SELinux can be used to confined the Git daemon and Git Shell. I have not used SELinux in a optimal way here but i decided to implement a mix of MAC, DAC and Git ACL.

As for SELinux i have installed the following module:

gitd.te:

[code]

policy_module(gitd, 1.0.0)

########################################
#
# Git daemon global private declarations.
#

attribute gitd_type;
attribute gitd_content_type;

type gitd_exec_t;

# FIXME
type gitd_port_t;
corenet_port(gitd_port_t)

########################################
#
# Git daemon system private declarations.
#

##
##

## Allow Git-shell to modify and execute public files
## used for public file transfer services. Directories/Files must
## be labeled public_content_rw_t.
##

##
# gen_tunable(gitd_allow_anon_write, false)

##
##

## Allow Git daemon system to search home directories.
##

##
gen_tunable(gitd_system_enable_homedirs, false)

##
##

## Allow Git daemon system to access cifs file systems.
##

##
gen_tunable(gitd_system_use_cifs, false)

##
##

## Allow Git daemon system to access nfs file systems.
##

##
gen_tunable(gitd_system_use_nfs, false)

type gitd_system_t, gitd_type;
inetd_service_domain(gitd_system_t, gitd_exec_t)
role system_r types gitd_system_t;

type gitd_shared_t, gitd_content_type;
files_type(gitd_shared_t)

# permissive gitd_system_t;

########################################
#
# Git shell private declarations.
#

gen_require(`
attribute unpriv_userdomain, userdomain;
class context contains;
')

attribute gits_file_type;
attribute gits_usertype;

type gits_t, userdomain, gits_usertype, unpriv_userdomain;
domain_type(gits_t)

role gits_r types gits_t;
allow system_r gits_r;

corecmd_shell_entry_type(gits_t)
corecmd_bin_entry_type(gits_t)

domain_interactive_fd(gits_t)
domain_user_exemption_target(gits_t)

# permissive gits_t;

########################################
#
# Git daemon session session private declarations.
#

##
##

## Allow Git daemon session to bind
## tcp sockets to all unreserved ports.
##

##
gen_tunable(gitd_session_bind_all_unreserved_ports, false)

type gitd_session_t, gitd_type;
application_domain(gitd_session_t, gitd_exec_t)
ubac_constrained(gitd_session_t)

type gitd_personal_t, gitd_content_type;
userdom_user_home_content(gitd_personal_t)

# permissive gitd_session_t;

########################################
#
# Git daemon global private policy.
#

allow gitd_type self:fifo_file rw_fifo_file_perms;
allow gitd_type self:netlink_route_socket { create_socket_perms nlmsg_read };
allow gitd_type self:tcp_socket create_socket_perms;
allow gitd_type self:udp_socket create_socket_perms;
allow gitd_type self:unix_dgram_socket create_socket_perms;

# FIXME
allow gitd_type gitd_port_t:tcp_socket name_bind;

corenet_all_recvfrom_netlabel(gitd_type)
corenet_all_recvfrom_unlabeled(gitd_type)

corenet_tcp_sendrecv_all_if(gitd_type)
corenet_tcp_sendrecv_all_nodes(gitd_type)
corenet_tcp_sendrecv_all_ports(gitd_type)

corenet_tcp_bind_all_nodes(gitd_type)

corecmd_exec_bin(gitd_type)

files_read_etc_files(gitd_type)
files_read_usr_files(gitd_type)

fs_search_auto_mountpoints(gitd_type)

kernel_read_system_state(gitd_type)

logging_send_syslog_msg(gitd_type)

miscfiles_read_localization(gitd_type)

sysnet_read_config(gitd_type)

optional_policy(`
nis_use_ypbind(gitd_type)
')

optional_policy(`
nscd_read_pid(gitd_type)
')

########################################
#
# Git daemon system repository private policy.
#

list_dirs_pattern(gitd_system_t, gitd_content_type, gitd_content_type)
read_files_pattern(gitd_system_t, gitd_content_type, gitd_content_type)
files_search_var(gitd_system_t)

# This will not work since git-shell needs to execute gitd content thus public content files.
# There is currently no clean way to execute public content files.
# miscfiles_read_public_files(gitd_system_t)

tunable_policy(`gitd_system_enable_homedirs', `
userdom_search_user_home_dirs(gitd_system_t)
')

tunable_policy(`gitd_system_enable_homedirs && use_nfs_home_dirs', `
fs_list_nfs(gitd_system_t)
fs_read_nfs_files(gitd_system_t)
')

tunable_policy(`gitd_system_enable_homedirs && use_samba_home_dirs', `
fs_list_cifs(gitd_system_t)
fs_read_cifs_files(gitd_system_t)
')

tunable_policy(`gitd_system_use_cifs', `
fs_list_cifs(gitd_system_t)
fs_read_cifs_files(gitd_system_t)
')

tunable_policy(`gitd_system_use_nfs', `
fs_list_nfs(gitd_system_t)
fs_read_nfs_files(gitd_system_t)
')

########################################
#
# Git shell private policy.
#

allow gits_t self:context contains;
allow gits_t self:fifo_file rw_fifo_file_perms;

corecmd_exec_bin(gits_t)

kernel_read_system_state(gits_t)

files_read_etc_files(gits_t)

files_search_home(gits_t)

gitd_execute_shared_files(gits_t)
gitd_manage_shared_content(gits_t)

miscfiles_read_localization(gits_t)
# miscfiles_read_public_files(gits_t)

ssh_rw_stream_sockets(gits_t)

# FIXME
# This will not work since git-shell needs to execute gitd content thus public content files.
# There is currently no clean way to execute public content files.
# tunable_policy(`gitd_allow_anon_write', `
# miscfiles_exec_public_files(gits_t)
# miscfiles_manage_public_files(gits_t)
# ')

tunable_policy(`gitd_system_enable_homedirs && use_nfs_home_dirs', `
fs_exec_nfs_files(gits_t)
fs_manage_nfs_dirs(gits_t)
fs_manage_nfs_files(gits_t)
')

tunable_policy(`gitd_system_enable_homedirs && use_samba_home_dirs', `
fs_exec_cifs_files(gits_t)
fs_manage_cifs_dirs(gits_t)
fs_manage_cifs_files(gits_t)
')

tunable_policy(`gitd_system_use_cifs', `
fs_exec_cifs_files(gits_t)
fs_manage_cifs_dirs(gits_t)
fs_manage_cifs_files(gits_t)
')

tunable_policy(`gitd_system_use_nfs', `
fs_exec_nfs_files(gits_t)
fs_manage_nfs_dirs(gits_t)
fs_manage_nfs_files(gits_t)
')

optional_policy(`
nscd_read_pid(gits_t)
')

########################################
#
# Git daemon session repository private policy.
#

list_dirs_pattern(gitd_session_t, gitd_personal_t, gitd_personal_t)
read_files_pattern(gitd_session_t, gitd_personal_t, gitd_personal_t)
userdom_search_user_home_dirs(gitd_session_t)

userdom_use_user_terminals(gitd_session_t)

tunable_policy(`gitd_session_bind_all_unreserved_ports', `
corenet_tcp_bind_all_unreserved_ports(gitd_session_t)
')

tunable_policy(`use_nfs_home_dirs', `
fs_list_nfs(gitd_session_t)
fs_read_nfs_files(gitd_session_t)
')

tunable_policy(`use_samba_home_dirs', `
fs_list_cifs(gitd_session_t)
fs_read_cifs_files(gitd_session_t)
')
[/code]

gitd.if
[code]
##

Git daemon is a really simple server for Git repositories.

##
##

## A really simple TCP git daemon that normally listens on
## port DEFAULT_GIT_PORT aka 9418. It waits for a
## connection asking for a service, and will serve that
## service if it is enabled.
##

## It verifies that the directory has the magic file
## git-daemon-export-ok, and it will refuse to export any
## git directory that has not explicitly been marked for
## export this way (unless the --export-all parameter is
## specified). If you pass some directory paths as
## git-daemon arguments, you can further restrict the
## offers to a whitelist comprising of those.
##

## By default, only upload-pack service is enabled, which
## serves git-fetch-pack and git-ls-remote clients, which
## are invoked from git-fetch, git-pull, and git-clone.
##

## This is ideally suited for read-only updates, i.e.,
## pulling from git repositories.
##

## An upload-archive also exists to serve git-archive.
##

##

#######################################
##

## Role access for Git daemon session.
##

##
##

## Role allowed access.
##

##
##
##

## User domain for the role.
##

##
#
interface(`gitd_session_role', `
gen_require(`
type gitd_session_t, gitd_exec_t, gitd_personal_t;
')

########################################
#
# Git daemon session shared declarations.
#

##
##

## Allow transitions to the Git daemon
## session domain.
##

##
gen_tunable(gitd_session_transition, false)

role $1 types gitd_session_t;

########################################
#
# Git daemon session shared policy.
#

tunable_policy(`gitd_session_transition', `
domtrans_pattern($2, gitd_exec_t, gitd_session_t)
', `
can_exec($2, gitd_exec_t)
')

allow $2 gitd_session_t:process { ptrace signal_perms };
ps_process_pattern($2, gitd_session_t)

exec_files_pattern($2, gitd_personal_t, gitd_personal_t)
manage_dirs_pattern($2, gitd_personal_t, gitd_personal_t)
manage_files_pattern($2, gitd_personal_t, gitd_personal_t)

relabel_dirs_pattern($2, gitd_personal_t, gitd_personal_t)
relabel_files_pattern($2, gitd_personal_t, gitd_personal_t)
')

########################################
##

## Allow the specified domain to execute
## Git daemon shared files.
##

##
##

## Domain allowed access.
##

##
##
#
interface(`gitd_execute_shared_files', `
gen_require(`
type gitd_shared_t;
')

exec_files_pattern($1, gitd_shared_t, gitd_shared_t)
files_search_var($1)
')

########################################
##

## Allow the specified domain to manage
## Git daemon shared content.
##

##
##

## Domain allowed access.
##

##
##
#
interface(`gitd_manage_shared_content', `
gen_require(`
type gitd_shared_t;
')

manage_dirs_pattern($1, gitd_shared_t, gitd_shared_t)
manage_files_pattern($1, gitd_shared_t, gitd_shared_t)
files_search_var($1)
')

########################################
##

## Allow the specified domain to manage
## Git daemon personal content.
##

##
##

## Domain allowed access.
##

##
##
#
interface(`gitd_manage_personal_content', `
gen_require(`
type gitd_personal_t;
')

manage_dirs_pattern($1, gitd_personal_t, gitd_personal_t)
manage_files_pattern($1, gitd_personal_t, gitd_personal_t)
files_search_home($1)
')

########################################
##

## Allow the specified domain to read
## Git daemon personal content.
##

##
##

## Domain allowed access.
##

##
##
#
interface(`gitd_read_personal_content', `
gen_require(`
type gitd_personal_t;
')

list_dirs_pattern($1, gitd_personal_t, gitd_personal_t)
read_files_pattern($1, gitd_personal_t, gitd_personal_t)
files_search_home($1)
')

########################################
##

## Allow the specified domain to read
## Git daemon shared content.
##

##
##

## Domain allowed access.
##

##
##
#
interface(`gitd_read_shared_content', `
gen_require(`
type gitd_shared_t;
')

list_dirs_pattern($1, gitd_shared_t, gitd_shared_t)
read_files_pattern($1, gitd_shared_t, gitd_shared_t)
files_search_var($1)
')

########################################
##

## Allow the specified domain to relabel
## Git daemon shared content.
##

##
##

## Domain allowed access.
##

##
##
#
interface(`gitd_relabel_shared_content', `
gen_require(`
type gitd_shared_t;
')

relabel_dirs_pattern($1, gitd_shared_t, gitd_shared_t)
relabel_files_pattern($1, gitd_shared_t, gitd_shared_t)
files_search_var($1)
')

########################################
##

## Allow the specified domain to relabel
## Git daemon personal content.
##

##
##

## Domain allowed access.
##

##
##
#
interface(`gitd_relabel_personal_content', `
gen_require(`
type gitd_personal_t;
')

relabel_dirs_pattern($1, gitd_personal_t, gitd_personal_t)
relabel_files_pattern($1, gitd_personal_t, gitd_personal_t)
files_search_home($1)
')

########################################
##

## All of the rules required to administrate an
## Git daemon system environment
##

##
##

## Prefix of the domain. Example, user would be
## the prefix for the user_t domain.
##

##
##
##

## Domain allowed access.
##

##
##
##

## The role to be allowed to manage the Git daemon domain.
##

##
##
#
interface(`gitd_system_admin', `
gen_require(`
type gitd_system_t, gitd_exec_t;
')

allow $1 gitd_system_t:process { getattr ptrace signal_perms };

kernel_search_proc($1)
allow $1 git_system_t:dir list_dir_perms;
read_files_pattern($1, gitd_system_t, gitd_system_t)
read_lnk_files_pattern($1, gitd_system_t, gitd_system_t)

manage_files_pattern($1, gitd_exec_t, gitd_exec_t)

# This will not work since git-shell needs to execute gitd content thus public content files.
# There is currently no clean way to execute public content files.
# miscfiles_manage_public_files($1)

gitd_manage_shared_content($1)
gitd_relabel_shared_content($1)

seutil_domtrans_setfiles($1)
')
[/code]

gitd.fc
[code]HOME_DIR/public_git(/.*)? gen_context(system_u:object_r:gitd_personal_t, s0)
HOME_DIR/\.gitconfig -- gen_context(system_u:object_r:gitd_personal_t, s0)

/srv/git(/.*)? gen_context(system_u:object_r:gitd_shared_t, s0)

/usr/libexec/git-core/git-daemon -- gen_context(system_u:object_r:gitd_exec_t, s0)

# Conflict with Fedora cgit fc spec.
# /var/lib/git(/.*)? gen_context(system_u:object_r:gitd_shared_t, s0)
[/code]

I manually labelled tcp:9418 gitd_port_t
[code]
semanage port -a -t gitd_port_t -p tcp 9418
[/code]

I also manually added a SELinux user mapping:

semanage user -a -L s0 -r s0 -R "gits_r" -P gits_u

echo "system_r:sshd_t:s0 gits_r:gits_t:s0" > /etc/selinux/targeted/contexts/users/gits_u

I edited /etc/xinetd.d/git:
[code]

# default: off
# description: The git dæmon allows git repositories to be exported using \
#       the git:// protocol.

service git
{
        disable         = no
        socket_type     = stream
        type            = UNLISTED
        port            = 9418
        wait            = no
        user            = nobody
#        server          = /usr/bin/git
#        server_args     = daemon --base-path=/srv/git --export-all
--user-path=public_git --syslog --inetd --verbose
        server          = /usr/libexec/git-core/git-daemon
        server_args     = --base-path=/srv/git --export-all
--user-path=public_git --syslog --inetd --verbose
        log_on_failure  += USERID
# xinetd doesn't do this by default. bug #195265
        flags           = IPv6
}
[/code]

Basically the selinux policy has 3 parts. one part is for the gitd system inetd server. the second part is for running gitd as a unprivileged user, and the third part is policy for the system wide git-shell environment.
So we secure the system wide gitd process, gitd process that users run and the git-shell process that is used to push pull to shared repositories.

When you compile git-daemon, configured it like above and install the selinux module, restore the contexts of the paths in gitd.fc. then start xinetd: youll notice that inetd_t is not allowed to bind to gitd_port_t.
You can simply use audit2allow with the -M option to allow inetd_t to bind to gitd_port on behalf of gitd_system_t

I use DAC to give usergroups access to the particular repositories and i use git ACL to restrict access to branches, tags etc.

I used this great web site do implement this:

http://www.kernel.org/pub/software/scm/git/docs/everyday.html

I wrote two simple scripts:

1. to add new users
2. to add new repostiries

create_repository:

crepo.sh:
[code]
#!/bin/bash

# crepo.sh 

groupadd $1 || exit 1;
usermod -a -G $1 badabing || exit 1;

mkdir /srv/git/$1.git || exit 1;
chmod -R +t /srv/git/$1.git || exit 1;
cd /srv/git/$1.git && git --bare init || exit 1;

cp /home/dgrift/create_repository/update /srv/git/$1.git/hooks/ || exit 1;
cp /home/dgrift/create_repository/allowed-users /srv/git/$1.git/info/ || exit 1;

chown -R nobody:$1 /srv/git/$1.git || exit 1;

chmod -R g+s /srv/git/$1.git/branches || exit 1;
chmod -R g+s /srv/git/$1.git/hooks || exit 1;
chmod -R g+s /srv/git/$1.git/info || exit 1;
chmod -R g+s /srv/git/$1.git/objects || exit 1;
chmod -R g+s /srv/git/$1.git/refs || exit 1;
chmod -R g+w /srv/git/$1.git || exit 1;

exit 0;

#EOF
[/code]

This script installs the git ACL files update and allowed-users:

update:
[code]
http://www.kernel.org/pub/software/scm/git/docs/howto/update-hook-example.txt
[/code]

allowed-users:
[code]
refs/heads/master       badabing
+refs/heads/pu          badabing
refs/heads/bw/.*        badabing
refs/heads/tmp/.*       .*
refs/tags/v[0-9].*      badabing
[/code]

I also created a script to do part of what is required to add new users (i havent tested this script yet:

[code]
#!/bin/bash

# agits.sh  

useradd -Z gits_u -s /usr/bin/git-shell $1 || exit 1;
usermod -a -G sshusers,$2 $1 || exit 1;

echo "Do not forget to set a password!"
echo "Manually add entries for $1 in /etc/security/namespace.conf!"
echo "You may need to edit /srv/git/$2.git/info/allowed-users!"

# TODO: usrquota

exit 0;
[/code]

By the way xinetd and selinux dont play nice so you may need to edit the xinetd init script:

[code]
https://bugzilla.redhat.com/show_bug.cgi?id=529681
[/code]

So that is basically it.
The SELinux policy for the git system service should work by default. Additionally there are some booleans to to toggle for example to allow the git system service to also host personal repositories in ~/public_git, allow git to use any unreserved port for mass git repostory hosting. enable disable transition to git_session_t which is the user daemon.
For this to work you must also enable git policy for users by creating a module:

for example if you want unconfined users to transition to git domain if they run git daemon <...>

myunconfined.te:
[code]
policy_module(myunconfined, 0.0.1)
optional_policy(`
gen_require(`
 type unconfined_t;
')

git_session_role(unconfined_r, unconfined_t)
[/code]

build and install that:

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i myunconfined.pp

That should work and make unconfined_t users transition to git_session_t when they run git daemon <...>

For me this setup works, but i have not thoroughly tested the git_session_t domain yet.

Would be nice to get some feedback so that i can improve this.


The git selinux policy is malformed above use the command below to pull the current gitd policy from my git repository

git clone git://82.197.205.60/selinux-modules.git

My view on domains, domain types, roles, domain transitions and more.

2009-10-06T15:14:00.000-07:00

A domain is an environment in which a process operates. That environment is defined by the access vectors where a particular process is the sources.

Sometimes people refer to types of processes as domains. This is technically incorrect. Types of processes are domain types.

A domain is a general term for process environments. Processes can have different natures or properties. For example a user process environment can be called a domain and a process of a program can also be called a domain.

In SELinux world we like to "label" everything. So instead of calling a user process environment a domain we call it a user domain. The type of a user process is called a user domain type although technically its a domain type since user processes are processes.

Besides user domains, there are more different domains. These domains are defined by who transitioned to them. For example, init daemons are started by init scripts. The init script process sandbox is called init script domain and process environments that init script domains transition to are called init daemon domains.

Examples of init daemon domains are the environment of the httpd_t init daemon domain type, or postgresql. The main property is that these processes are started by init scripts.

Process environments of programs that user process environments transition to are called application domains, and the type of such a process is called a application domain type.

It depends on what transitions to what, that defines what domain it is. A cgi webapp that operates in its own environment is called a apache daemon domain if the httpd_t init daemon domain transitions to the process environment of a cgi webapp.

There are many more such domains and they are defined by what domain transitioned to them.

Domain transitions occur upon entrypoints. An entrypoint is a defined path to usually a executable file. Types of executable files are called executable file types. They are important in entrypoints to domains.

For example:

apache init script has a executable file type called for example httpd_initrc_exec_t.
When the init_t domain type executes the file with executable file type httpd_initrc_exec_t,
the process of that executable file type will get the initrc_t domain type and the process will operate in the init script domain (init script process environment).

The entrypoint is:
init_t -> httpd_initrc_exec_t

This entrypoint leads to the initrc_t process environment. (init script domain)

Now this starts all over again when the process that has domain type initrc_t runs the apache executable.

Assuming in this example that /usr/sbin/httpd is apaches executable file and that it has a executable file type of httpd_exec_t.

The entrypoint is:
initrc_t -> httpd_exec_t

The init script domain type runs the apache executable file type. There is a rule that says:
when initrc_t executes httpd_exec_t, then transition to the httpd_t process environment type.

initrc_t -> httpd_exec_t -> httpd_t

initrc_t is a (init script) domain type. policy where initrc_t is the source type is called a init script domain.

httpd_exec_t is a executable file type.
initrc_t -> httpd_exec_t is the entrypoint to the httpd_t domain (type)
httpd_t -> is a (init daemon) domain type. policy where httpd_t is the source type is called a init daemon domain.

There are api available that make transitioning to these types of domains easier.

For example you can simply call the init_daemon_domain() interface if your process is started by a init script. proper calling of this single interface will take care of some of the declarations that are required. it will also set up a domain transition pattern.

type myinitdaemondomaintype_t;
type myinitdaemondomaintypeexecutablefiletype_t;
init_daemon_domain(myinitdaemondomaintype_t, myinitdaemondomaintypeexecutablefiletype_t)

This will instruct SELinux to let processes that run in the initrc_t init script domain that execute files with executable file type myinitdaemondomaintypeexecutablefiletype_t, domain transition to the myinitdaemondomaintype_t process enviroment and give that process the init daemon domain type.

initrc_t -> myinitdaemondomaintypeexecutablefiletype_t -> myinitdaemondomaintype_t

This ofcourse requires that file files in question are labelled accordingly.

application domains are handled a bit differently. This is mainly because of RBAC.

Role based access control is a mechanism that allows a single user to operate in various environments (user domains)

This means that you must also define which role is allowed to use the target domain type.

user_t: user domain type
userapp_exec_t: (application) executable file type of the application to transition to.
userapp_t: application domain type

entrypoint:
user_t -> userapp_exec_t

Target of the entry point:
userapp_tRole of the user that this domain transition pattern is defined for:
user_r

type user_t;
type userapp_exec_t;
application_domain(user_t, userapp_exec_t)
role user_r types userapp_t;

domain_transition_pattern(user_t, userapp_exec_t, userapp_t)

Again same idea but its just a bit more complicated than the init daemon domain because users
(and applications started by users) can have different roles.

Applications started by init (system) can only have one role(system_r), So that makes the init daemon domains less complicated.

Explained:
When a user process that operates in the user_t user process environment runs a file with executable file type myapp_exec_t, then the process of that executable file type will run in the myapp_t application process environment (application domain).

Since users can have different roles we also define that particular role to have access to the application domain type.

We also manually define a domain transition pattern (user_t -> myapp_exec_t -> myapp_t)

Keep in mind that domains transitioned to by users also have to deal with roles, unlike domain transitioned to by system processes. processes where the role field in the context is system_r.

Your policy source has many example of the different domains. If you want to write policy for a init daemon than look up an example of a init daemon domain in the source policy, and see if that can get you started. Idem ditto for application domains, apache daemon domains, xinet service domains, dbus service domains and etcetera.

User domains are different. They arent started by other processes. instead a real person logs into the system and by running a tty or pts a new domain is initiated. These transtions are defined both in the user domain policy and selinux mappings, many of which can be defined with the semanage command.

for example:
(real human) -> tty_device_t -> user_t

I wont go into much detail here but i want to touch on the different user domains to consider. Users can have different roles. Roles are mappings to domains. and as explained domain are environments in which processes operate, defined by the policy in which a domain type is a source.

There are two different classes of user domain to consider. user domains that need a login environment, and user domains that do not need a login enviroment. i refer to them as primary and secondary user domains.

An example of a primary login user domain is staff_t. A user can login to a system in the staff_t user domain.

An example of a secundary user domain is webadm_t.

A primary user domain can be allowed to domain transition via roles (RBAC) to this secondary user domain. Thus may not be required to login and have a home directory and etcetera. Secondary user domains are often used for environments that have super user privileges. Like for example the webadm_t environment allows a user process to manage the webserver environment.

Have a look at the different defined user domain in the source policy. look at both staff domain and webadm domain and keep in mind that the first is a primary domain and the latter a secondary domain. By mapping the webadm_r and staff_r roles to a selinux user and mapping this selinux user to a linux login you can make selinux allow users that operate in the staff_t user domain to use Role based access control to domain transition to the secondary webadm_t user domain via sudo or su in conjunction with newrole.

AVC Denials: Example

2009-09-17T05:46:00.000-07:00

SELinux logs policy violations to /var/log/audit/audit.log if audit is installed and enabled. If audit is
not installed or enabled, than SELinux sends policy violation notices to dmesg or /var/log/messages.

The policy violations that SELinux logs are called AVC denials. AVC is an abbreviation for Access Vector
Cache. Which is the SELinux cache with Access Vectors. Access vectors are the rules that govern access.

Reading AVC denials properly helps troubleshoot issues. In this article i will talk about, and highlight
some of the information you can retrieve from AVC denials. I will also touch on some of the tools that
assist in listing, parsing and translating SELinux Access Vector Cache denials.

Example of a AVC denial:

avc: denied { getattr } for pid=7604 comm="firefox" path="/usr/lib64/firefox-3.5.3/firefox" dev=dm-2 ino=1311607
scontext=dgrift_u:dgrift_r:gwibber_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mozilla_exec_t:s0 tclass=file

The line above provides much information about what has been denied:

1. What process was denied access.
2. What domain type did the source process operate in when it was denied access.
3. What object or subject was the source process denied access to.
4. What was the object/subject type of the target.
5. What permission was denied.
6. What is the class of the target.
7. What was the process identity of the source.
8. What was the inode number of the target object.
9. What happened.

Security is about managing interaction. Interaction has a source and a target. Interaction involves atleast
a subject as a source (an interacting party) and a subject or object as a target. The target of the
interaction. Subjects are interacting entities, and object non-interacting entities. Subjects can interact
with object, but subjects can also interact with other subjects.

The target class in a AVC denial tells us what the class (origin) of the target in an interaction is.
A source of a interaction is always a subject (interacting entity). Object can not interact and thus can
never be a source of an interaction.

Lets try and connect the dots and see if we can make sense of the example AVC denial above. We will try to
answer each of our 9 questions in the check list:

1. What process was denied access.

comm="firefox" shows use the name of the command that was run. The firefox program was denied access.

2. What domain type did the source
process operate in when it was denied access.

scontext=dgrift_u:dgrift_r:gwibber_t:s0-s0:c0.c1023 shows that the source firefox was operating with the
gwibber_t domain type. The type is the third field in the security context tuple.

3. What object or subject was the source process denied access to.

path="/usr/lib64/firefox-3.5.3/firefox" Shows what the target of the source in this interaction was.

4. What was the object/subject type of the target.

tcontext=system_u:object_r:mozilla_exec_t:s0 shows the type of the target.

5. What permission was denied.

{ getattr } Shows the syscall (permission) that was denied.

6. What is the class of the target.

tclass=file shows that the class of the target in our interaction was file.

7. What was the process identity of the source.

pid=7604 shows that the process id of the source of our interaction was 7604

8. What was the inode number of the target object.

ino=131160 shows that the inode number of the target object in our interaction was 131160.

9. What happened.

denied shows that the particular Access Vector was denied.

We have all the detail that we need to established *what* happend.

1. The command /usr/bin/firefox was executed but some interacting entity.
2. This command was executed with the gwibber_t domain type.
3. The target of the source /usr/bin/firefox was /usr/lib64/firefox-3.5.3/firefox
4. The type of the target was mozilla_exec_t
5. The source /usr/bin/firefox that operated with the gwibber_t domain type was denied the "getattr"
syscall on the target /usr/lib64/firefox-3.5.3/firefox that had type mozilla_exec_t.
6. The class of the target /usr/lib64/firefox-3.5.3/firefox is a file (the target is a file object)
7. The process of /usr/bin/firefox had the process id of 7604 when this Access vector occured.
8. The inode number of the target file object is 131160
9. Access was denied.

These are the SELinux facts:

the /usr/bin/firefox command was denied to get the attributes of the /usr/lib64/firefox-3.5.3/firefox file
source domain type gwibber_t was denied get attribute of a file object with type mozilla_exec_t

What this means is that there was no rule to allow this access, thus access was denied.

From here on out things get less obvious:

We know some facts but this has raised other questions:

1. Are the types of the source and target correct?
2. We know what was denied but we dont know why.
3. Should we allow this access?
4. Does it signal intrusion?
5. If we allow it access what would be the best way to do it.
6. What are the problems if we do it the other way?

The reason that these questions are harder to answer is because it depends on the policy that is created by
the policy author. But if you see an AVC denial we can usually narrow the cause down to:

a. The source and/or the target is mislabelled (wrong type)
b. It is a bug in policy.
c. Intrusion was detected and prevented.

So let's try to answer all these questions:

1. Are the types of the source and target correct?

This is the first thing we must verify. If the types are incorrect than we must correct them first to be able to learn the real reason
about what happend. Objects sometimes get mislabelled. For example if created the object whilst you had SELinux disabled and forgot to
restore the context. Another reason might be that you have moved the file from another location as opposed to copying it, and forgot
the restore the context.

How do we determine whether the types are correct? Well the answer is that we have to dig into some of the properties of the policy.
We have to put ourselves into the shoes of the policy author.

To verify whether the type of the source (gwibber_t) is correct we have to ask ourselves which policy module owns this type?
This is a hard question to answer. Really the only way to figure this out is to grep for the gwibber_t type in the source of the
policy. In this case there is a policy module installed called gwibber.

For example:

grep -r "type gwibber_t" Modules/

We are looking for the declaration of the gwibber_t type. Types are usually declared in files with .te suffixes (type enforcement
source policy files)

So we could narrow our grep a bit:

grep -r "type gwibber_t" Modules/ | grep "\.te"

Modules/gwibber.te:type gwibber_t;
Modules/gwibber.te:type gwibber_tmpfs_t;

The type is declared in the gwibber.te source policy type enforcement file. We can now grep this file for the policy_module
declaration to figure out what the name of the module is:

grep policy_module Modules/gwibber.te
policy_module(gwibber, 0.0.1)

The policy module name is gwibber and the version number is 0.0.1, Now we can determine whether this module is installed:

sudo /usr/sbin/semodule -l | grep gwibber
gwibber 0.0.1

The module is installed, we know that the type gwibber_t is owned by the gwibber module.

Now we should figure out what the type of the firefox command is. the firefox command is located in /usr/bin/firefox.
We can use ls -alZ /usr/sbin/firefox to determine the type of this command:

-rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/firefox

The type of the firefox command is bin_t. This type has a special property that is specific to the policy model. You could look up the
properties of this type the same way that we are currently looking up the properties of type gwibber_t.

But to not overly complicate things i will explain the main property of the bin_t type.

The bin_t type is a generic type for executable files in bin and sbin directories. These commands get run with the domain type of the
subject that executed the command. So if a process that was operating with the gwibber_t domain type executed a command with the bin_t
type, than that command would run with the gwibber_t domain type.

With this in we have to figure out whether processes with the gwibber_t domain type are allowed to execute files with the bin_t type:

sudo sesearch --allow -s gwibber_t -t bin_t -c file -p execute
Found 1 semantic av rules:
allow gwibber_t bin_t : file { ioctl read getattr lock execute execute_no_trans open } ;

The sesearch command queries the policy store and looks if there is a rule which allows the source gwibber_t domain type to execute
target objects of the files class with type bin_t.

A line is returned confirming that this is allowed. This tells us that the source in our interaction is likely correclty labelled.
This is what happened. Some process that run with the gwibber_t domain type ran /usr/bin/firefox which has the bin_t type causing the
firefox command to run with the gwibber_t domain type.

Now we need to determine whether the type of our target is correct. In our interaction that fortunatly is pretty easy.
We know the path of our target: /usr/lib64/firefox-3.5.3/firefox
We can run the matchpathcon command to see what type is defined for this location and if that defined type corresponds to the target
type in our avc denial: mozilla_exec_t.

sudo /sbin/matchpathcon /usr/lib64/firefox-3.5.3/firefox
/usr/lib64/firefox-3.5.3/firefox system_u:object_r:mozilla_exec_t:s0

This confirms that the labelling in the interaction is correct for both source and target.

Sometimes however, the full path of the target is not shown in a avc denial. In that case you can use the inode number to find the
full path:

find / -inum 131160
/usr/lib64/firefox-3.5.3/firefox

2. We know what was denied but we dont know why.

This is another hard question to solve. We are no psychics. We cannot read the mind of the policy author.
We can try:

Should gwibber be able to run firefox? It should be able to run the default browser yes but in this case (the case where i am the
policy author of the gwibber policy module) it was decided to not allow this funcionality. It is obvious that the gwibber_t domain
type was not allowed the access/see (get attributes) the mozilla executable file with type mozilla_exec_t. So either that was done on
purpose or it is a bug in the policy.

3. Should we allow this access?
3. Should we allow this access?
4. Does it signal intrusion?
5. If we allow it access what would be the best way to do it.
6. What are the problems if we do it the other way?

Another tough question. if we allow gwibber_t to get attributes of files with type mozilla_exec_t it will probably want more after
that. Chances are that gwibber wants to execute the file (run firefox), since gwibber is designed to open pages in the default
browser.

If we want gwibber to be able to open the browser, do we want to allow gwibber_t to run the browser with the gwibber_t type or should
we lets gwibber_t domain transition to the mozilla_t domain type? Well my personal opinion is to domain transition where ever possible
but it depends on the situation. In this case a domain transition from gwibber_t to mozilla_t via mozilla_exec_t would likely be the
best decision. However this requires that policy is written manually to make it do what we want it to do.

But what if we just want to allow this single access vector? We could use the audit2allow tool to translate the avc denial into policy
language and to create a module. Than we could load the created policy module into the policy store with the semodule command.

echo "avc: denied { getattr } for pid=7604 comm="firefox" path="/usr/lib64/firefox-3.5.3/firefox" dev=dm-2 ino=1311607
scontext=dgrift_u:dgrift_r:gwibber_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mozilla_exec_t:s0 tclass=file" | audit2allow -M
mygwibber; sudo semodule -i mygwibber.pp

Or we could do it ourselves:
echo "policy_module(mygwibber, 0.0.1)" > mygwibber.te;
echo "require { type gwibber_t, mozilla_exec_t; }" >> mygwibber.te;
echo "allow gwibber.te mozilla_exec_t:file getattr;" >> mygwibber.te;
make -f /usr/share/selinux/devel/Makefile mygwibber.pp
sudo semodule -i mygwibber.pp

So:

a. The source and/or the target is mislabelled (wrong type)

The types were correct.

b. It is a bug in policy.

It is a bug in policy because we determined that it is usually behaviour for gwibber to try to run the default browser to display
pages. Either we should allow it gwibber to run the browser (be it with the gwibber_t domain type or by domain transition with the
mozilla_t domain type) or we should make sure that no AVC denials are displayed when gwibber_t tries to access the mozilla executable
file with type mozilla_exec_t.

The rule that i am going to implement is this:

dontaudit gwibber_t mozilla_exec_t:file getattr;

Which says if domain type gwibber_t tries to get attributes of files with type mozilla_exec_t than "dontaudit" which means do not
print an avc denials (e.g. silently deny this)

That is just my personal preference. Its not something fixed. It is my security decision, whether good or bad.

c. Intrusion was detected and prevented.

No not really an intrusion since gwibber is designed to open pages in the default web browser which is firefox. So it is expected
behaviour. However i dont want to allow it. But i dont want to log the AVC denial when it happens either because its not important.

A perspective on SELinux

2009-09-16T14:39:00.000-07:00

Many people think SELinux is complicated. SELinux is actually beautifully simple if you keep in mind that it
allows you to manage security very granular in computer systems which are very complex.

In this article i will try to explain the basics of SELinux. The things you need to know to find your
way around the SELinux environment.

SELinux can roughly be categorized in a few separate parts (ordered by importance):

1. The SELinux framework.
* 2. The tools to manage SELinux.
* 3. The policy.

In this article i will talk about The SELinux framework and the Type enforcement security model.

Knowledge of the SELinux framework is fundamental. If you are familiar with this it will enable you to
find your way around the rest.

Knowledge of the different SELinux security models is also important in this part i will talk about how
the Type enforcement security model fits into the SELinux Framework.

To learn about SELinux you have to know a bit about security and about computer systems.

What is security? Security is managing parties in an interaction. So for example if you want to secure a
human sitting on a chair. You have to manage the human and the chair. The human interacts. this is
called a subject, the chair does not interact and this is called an object. You could create policy that allows
the human to sit on the chair but not stand on it. Standing on it may cause it to break.

How do computer systems work? Computer systems are similar. processes are like humans. We call them
agents. A process therefore is a subject just like the human in my chair example. Processes interact. A
file in a computer system does not interact. The subject interacts with it. A file is a object. In a
computer system there are many classes of objects just like there are many kind of classes of object in
real life. My example was a chair but it could have been a bed or a bike etc. In a computer system a
object could be a file or a network port. Generally keep in mind that subjects interact and object get
interacted with.

So simplified:
Real life: human, chair, sit
Computer system: process, file, read

Humans can be categorized in many classes, the most obvious is man and woman but there are many types of
different humans. Processes in a computer system can also be categorized in many classes, for example a
process of a user or a process of a program.

Chairs can also be categorized in many classes. Theres rocket chairs and theres oother chairs as well,
but they are all chairs and objects. Objects in computer systems can also be categorized. There are
files and directories etcetera.

If you want to manage all these subjects and objects than you will want to categorize them. So that you
can create policy for each.

Subjects interact, objects dont. Lets look at some policy for the examples i gave.

real life:
allow man chair:rocket_chair sit;

computer system:
allow user file:dir read;

So in the real life example we allow a subject: human of the type: man to sit on a chair that is of the
class rocket_chair.

In the computer system example we allow a subject: process of the type user to read a file that is of
the class dir.

Our rule start with allow to signal that we want to allow the rule that follows, than follow our source
of the interaction. Which is always a subject since subject interact and object do not. Next is the
target. targets can be either subject or objects. subjects can interact with other subjects. for example
a man talking with a woman. Next is the class of the target. in our man/woman interaction the class
would of the target human would be woman. The last part defines the permission. What interaction is
allowed? in our man/chair example the man is allowed to site on a rocket_chair in our computer system
example the user process is allowed to read a dir. In our recent man talks to woman example we allow a
man to talk to a woman.

So back to SELinux. How does SELinux relates to all this. SELinux is for a large part in the kernel. It
is a framework. That means that SELinux provides us with some attributes so that we can create policy to
define what may and what may not. The attributes that SELinux provides are classes and permissions.
SELinux knows the classes of the parties involved in interaction in a computer system. It knows
subjects and the different classes of objects. SELinux also knows how subject interact with the
different object. In the real life example: SELinux knows theres a human interacting with a chair. It
knows the chair is a rocket chair and it know in what ways humans interact with chairs (sit for example)

So the framework provides us with the attributes to create rules. What it cannot do is make further
destictions between different subjects and objects. And to be able to manage everything we must make
distinctions as much as possible. This is what policy authors do. They make categorize sources and
targets in an interaction. for example. SELinux knows a human wants to site in a chair. It even knows it
is a rocket chair. But what if we want to make a destinction between a yellow rocket chair and a red
rocket chair? We want to be able to allow the human to site in the red rocket chair but not the yellow
one. SELinux framework does not know the color, we do. This is where types come in.

Policy authors assign types to subjects and objects. so in the real life example:

allow human chair:rocket_chair sit;

allow human_man_type red_chair_type:rocket_chair sit;

In the computer system:

allow process file:dir read;

allow user_process_type home_file_type:dir read;

Types allow us to further categorize the parties in an interaction.

If sufficient for now to know that the SELinux framework provides us with the classes and permission
attributes and that it allows us the further categorize the source and target in an interaction, be it
subjects or objects.

Type enforcement is a model where policy is enforcement for interaction between the types of the parties
involved. The types can be defined by the policy author and the best types depend on the environment.

In a computer environment you might want to make a destinction between a log file and a library file, a
program or a user. In a real life environment you might want to make a destinction between man or woman,
red rocket chair or yellow rocket chair. It depends on what colors rocket chairs exist in you
environment. Types enable us to define the properties of our environment.

By default all interaction is forbidden. if we want to allow something we have define what is allowed.
If there are many types and classes of parties in interaction in an environment you might be able to
imagine to amount of rules required to manage all this. For now it is sufficient to know that there are
also ways to group or tag different types.

If you want a human to be able to sit on all colored rocket chairs you could for example tag the
red_chair_type and the yellow_chair_type to be colored_chair_types and use the tag to make one single
rule for both colored chairs.

allow human_man_type colored_chair_types:rocket_chair sit;

So that is a very important thing to understand about SELinux and security in general. The enforcement
of types is the most important security model of SELinux.

Besides the "allow source target:target_class permission;" rules, there is another thing to understand
and that is called a type transition. You can make one type transition to another type.

For now it is suffice to know that subject and object types can be triggered to change. Subject types
can change via rules that define what should happen if a process executes a file and object
types can transition via rule that define what should happen if a file is created under a certain
parents type.

Type transitions help you futher categorize parties which will let you define rule for types in certain scenarios.

This is the basics about SELinux. Types are configured by policy authors. The have special meanings and those meanings can vary per
policy. So the only thing that really always applies are classes and permissions they stay the same. Types are defined by humans and
to learn what a certail type is allowed you would have to reference the policy to determine that.

And that is want you we are often confronted with, types. rules that govern how one type can interact with another. What we dont know
is what a certain type of a subject is supposed to be allowed to do to a certain type of a object.

These things can be figured out by referencing the policy and asking yourself the question what is the meaning of the type? what are
its properties? This is what makes SELinux environments complex because policy is based on a policy authors vision on a system. And
that vision may differ per policy model and environment.

SELinux itself is not complicated but if you want to manage a complex system you will have to create many different types and thats
where SELinux gets complex. If you have a simple system to manage than SELinux will also be simpeler. If you have a simple security
goal on a complex system you may also be able to implement a simpler policy that is targeted towards just reaching your simple
security goal.

Eventually its all just subjects, objects, classes and permissions when it comes to the SELinux framework and the type enforcement
security model.

The more granular the policy to govern how subject can interact with objects gets,the complexer selinux gets. But this is the strenght
of SELinux: it allows you to define very granular what is allowed and what not in a system.

Blame the policy author and the policy for the complexity of managing your Security-Enhanced Linux ( i bet the policy author will
blame Linux ;) )

A quick note about the tools:

What are the tools for:

labeling objects
parsing access vector denials
translating access vector denials to policy
finding suggestions to solutions for access vector denials
finding what type a object should have
changing types of objects
restoring types of objects
searching rules in the policy database
mapping linux logins to subject types

Some SELinux experiences that i want to share with you:

2009-09-10T03:53:00.000-07:00

Disclaimer: I am just thinking out loud here, and i am sure that in some cases i do not fully understand the complexity or the underlying ideas of, and behind the issues that i am about to describe.

1. (not fedora specific)
User space processes own files on tmpfs for pulseaudio. These user space processes want to read (and unlink) each others pulseaudio files on tmpfs. To facilitate this, it requires much policy and also by allowing a user space process to read another user space processes pulseaudio tmpfs files , you also give it access to the user space process non pulseaudio tmpfs files. which might not be desired.

maybe somehow we can implement a attribute for user space processes pulseaudio files on tmpfs. and/or create a generic interface for this interaction.

3. (fedora specific)
xserver policy has been modified and xserver_user_x_domain_template and xserver_x_domain_template have been added. These templates could be used instead of xserver_user_client and xserver_common_app.

By calling these templates other xserver related policy in the domain that call it can for a large part also be removed. The interfaces mentioned above include most of the required xserver policy for user and application processes to function.

There are some notable exceptions:

xserver_rw_xdm_home_files

Also it appears that the interfaces mentioned above were designed with mls policy in mind. To be able to enable xserver object manager in a way that could benefit targeted policy i think a solution could be found so that xserver policy can be easily extended to provide a basic multi purpose useable policy for targeted as well ( maybe create interfaces for the various scenarios ) so that interfaces (or maybe tunable policy) can be called to make xserver object manager work in a basic form and/or specific form in targeted policy.

So that the admin can easily extend xserver policy for his custom needs without having to write local policy himself or having to implement his own custom interfaces, at least as much as possible.

An example of stuff that currently has no policy implemented but in many cases is required is for example the functionality to change mouse button (for left handed people) and the use of acceleration (3d)

Also we should keep in mind that there is a allow_write_xshm boolean that probably should be used where ever required instead of allowing access to this by adding fixed policy.

My point is that i think xserver object manager could at least to some extend be usable in a targeted policy, and that it could be extendible. Currently in fedora there is no easy way to make openoffice work nice with XACE. I cannot extend its policy due to 'not within scope issues' (user domain prefixes). The java SELinux implementation suffers similar issues.

3. (not fedora specific)
This also brings me to staff and user domains. These domains do not have access to some devices (cannot rw to dri, cannot rw to wifi, webcam etc) maybe we should implement some booleans for this with a $1. e.g. userdom_$1_use_dri etc. or maybe create users domains that add this functionality. I think this is a requirement to makes confined domains acceptable for day-to-day GUI use. Also the allow_execmem boolean is a bit too coarse. Lets face it we are not close to a working none execmem/execstack environment yet. For example nautilus requires it, totem, etc. many of these apps run in the user domain. Setting allow_execmem would in my view be overkill to just allow a single user domain execmem permission. allow_$1_execmem, where $1 is a specific user domain would in my view be a reasonable temporary solution. In either case i do not think we should just ignore the issue.

The "easy" access to execmem and devices like dri are in my view important to help make confined user domains usable for the general public in a GUI environment.

Policy development: optional policy

2009-07-12T09:22:00.001-07:00

If you have looked into source policy you might have noticed optional policy blocks of policy in the type enforcement source policy files. Optional policy is used to make policy modular.

If you call a interface in your policy module that is hosted by another policy module then your module is dependent on that other module. If you decide to de-install the policy module that hosts the interface that you called in your policy module than your policy will no longer be able to build. This is because you're calling shared policy that no longer exists.

To avoid these dependencies, optional policy block are used.

Let's look at some examples:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/apps/mozilla.te

On line 244 to line 246 there is an optional policy block defined with policy that is borrowed from the gnome policy module.
This can determined since the interface is prefixed by the name (gnome) of the policy module that hosts the interface that is called by mozilla.

The interface facilitates permissions that allows firefox to connect to a unix stream socket that is owned by gnome gconf.

The interface is defined here:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/apps/gnome.if
(line 38 to line 55)

Let's use the semodule command to list both mozilla and gnome modules:

# semodule -l | grep gnome
gnome 2.0.0
gnomeclock 1.0.0

# semodule -l | grep mozilla
mozilla 2.0.1

We should be able to de-install both modules without getting into dependency troubles. If i decide to de-install the gnome module then the gnome_stream_connect_gconf interface becomes unavailable since it is defined in the gnome policy module that i just de-installed.

If we would have called gnome_stream_connect_gconf(mozilla_t) without using the optional policy block than we would run into trouble if we tried to de-install the gnome module. The compiler would complain about missing dependencies.

You should note that not all policy comes as a stand alone module. Some policies are not optional and they go into a single policy module called base.
As a rule keep in mind that if you can list a module with the semodule command then it can be de-installed.

If you borrow shared policy from another (optional) policy module then remember to place it into the optional policy block. For example all policy borrowed from gnome module can be placed into a optional policy block for gnome policy.

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/apps/mozilla.te
(line 225 to line 227)

These are two interfaces that are hosted by the apache policy module. Both interfaces can go into a single optional policy block since both interfaces are dependent on the same apache module.

FAQ: SELinux denies access but AVC denials can not be found.

2009-07-12T03:50:00.000-07:00

It happens. There are a few reasons for this:

1. Silenced AVC denials (access vector cache).

In policy one can define to silently deny access vectors. This means access is denied and attempts are not logged. Such a rule (access vector) would look like this for example (fictional):

dontaudit user_t var_t:dir { read open };

When a user that operates in the user_t user domain tries to read a var_t directory object type, access is denied. The attempt that was denied would not be logged.

In general the use of "dontaudit" rules should be kept to a minimum. The issue of being denied access and not finding an audit trail for this reason should not happen often at all.

There are exceptions, like restricted user domains. These processes are restricted/limited for reason and those restrictions/limits might give violation attempts when a user operating in such a domain tries to do something that is not allowed. In this case the AVC denials are anticipated and silenced to avoid flooding of the logs with meaning less entries.

There is a way to expose these silenced AVC denials, but be aware that this may fill up your logs quicker than expected.

The semodule command used with the -DB options unloads "dontaudit" rules on-the-fly. All attempts to violate policy are now logged.

The semodule command used with the -B option builds the policy with the "dontaudit" rules included. Silenced AVC denials are back in policy.

2. User space object managers.

User space object managers are SELinux extensions on application layers. Applications that implement a SELinux Access Control Extension provides classes and permissions to be used for SELinux Policy. The application itself enforces policy that is defined using the classes and permissions it has provided.

There are only few applications that are also user space object managers. DBus implements this and this feature is enabled by default. If some access is denied and you've unloaded the "dontaudit" rules using the semodule command with -DB option, but you still cannot find any audit trail, then chances are the DBUS access control extension is responsible.

In some cases, which might be due to a bug, DBUS sends its user_avc denials to /var/log/messages instead of the expected /var/log/audit/audit.log

So it is recommended to also see /var/log/messages or dmesg if you suspect SELinux denied access but you cannot find any audit trail.

SELinux denials are called AVC denials and can also be listed using the ausearch command with -m option and avc parameter.

User space object manager denials are called USER_AVC denials and can also be listed using the ausearch command with the -m option and user_avc parameter. Note that this only works for denials logged to /var/log/audit/audit.log

Conclusion:

If you suspect SELinux denied some access but you can not find the audit trail then consider building the policy without the "dontaudit" rules using semodule -DB. If you still cannot find any audit trail than maybe a user space object manager denied access. Look for USER_AVC denials in audit.log or look in /var/log/messages, or dmesg. The log file for the application itself may also have them.

I think the goal is to have everything log to audit.log for simplicity but at the moment this is not the case.

Tip:

You can use the sesearch command to list "dontaudit" rules that are currently built-in policy. For example to list "dontaudit" rules where the httpd_t is the source domain:

sesearch --dontaudit -s httpd_t

Have a look at "man sesearch"

Multi Category Security

2009-06-29T06:40:00.000-07:00

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

Mystaff SELinux User Domain

2009-06-28T06:11:00.000-07:00

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)

Policy module source

2009-06-28T04:44:00.000-07:00

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.

SELinux screencasts

2009-06-27T08:36:00.000-07:00

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 :)

SELinux Lockdown Part Ten: Conclusion

2009-06-27T03:25:00.000-07:00

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

SELinux Lockdown Part Nine: Booleans

2009-06-27T03:13:00.000-07:00

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

SELinux Lockdown Part Eight: Unconfined

2009-06-26T05:33:00.000-07:00

The unconfined space is for processes that require almost unrestricted access. Almost because writable memory execution is not permitted. The following permissions are restricted for processes that operate in the unconfined space unless specified otherwise: Execmem Execstack Execheap Execmod.

Processes that in a default Fedora 11 installation operate in this Unconfined Domain are the Linux Kernel, RPM, init scripts, and unconfined users.
Unconfined processes usually run programs unconfined too unless other otherwise specified. It is expected that unconfined processes are unrestricted and that children inherit this unconfined environment. Exceptions to this rule as said should be specified by creating policy that transitions the Unconfined Domain to a restricted space when a unconfined process runs a program.

Security can be greatly improved by removing the unconfined space. This will cause all processes to be restricted by SELinux. In Fedora 11 the unconfined space was split into two parts. The first part is the unconfined space for programs, and the second part is the unconfined space for users. This second part was renamed to the unconfineduser domain.

The result of this split is that now either or both environments can be removed. If the unconfined domain which is the domain for unconfined programs is removed then the init scripts will be restricted. This means that system services that do not have SELinux policy defined will run in the restricted init script environment and will not run unrestricted. This is a great way to ensure that no unrestricted system services are implemented on the system. The kernel and RPM processes stay unconfined because these processes need many permissions in order to operate successfully.

The unconfineduser domain can be removed to ensure that all users operate in a restricted environment. If it is decided to remove the unconfineduser domain than you must reconfigure your SELinux mappings to reflect this change.

There should be no reason to not remove the unconfined domain if the operator feels comfortable with SELinux. The operator can implement SELinux policy for any system process that does not have policy defined already.

The unconfineduser domain is usually handy to keep, as the operator can mannually configure which Linux users are mapped to this User Domain. SELinux can be configured to not allow unconfined logins via OpenSSH or Grapical User Interface. This means that users that have access to the unconfineduser domain can only login using this environment on the TTY or access the unconfined user space via the sudo command or SU with newrole command.

Using the unconfined user domain as a secondary domain only improves security if unconfined logins are not enabled.

Example: Remove the unconfined domain, disallow unconfined user logins, map unconfined_r role to existing staff_u SELinux User, Remove the sysadm_r role for the staff_u SELinux User. Add Linux user John and map the Linux user to the staff_u SELinux user. Add an entry for John to /etc/sudoers.

sudo setsebool -P unconfined_login off
sudo semanage user -m -L s0 -r s0-s0:c0.c1023 -R "staff_r system_r unconfined_r" -P user staff_u
sudo semodule -r unconfined
sudo useradd -Z staff_u john
sudo visudo (john ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL)

John logs into the system as the restricted Linux user staff_u. When John wants to acquire root privileges he simply runs the sudo command. John can open a root shell in the unconfined space by running the sudo command with the -s option.

This configuration should not change your ways of doing things too much since root logins are not encouraged and since the staff_t restricted user domain has all permissions that a unprivileged user requires. It is also possible to create a custom User Domain that is tailor made to your personal requirements and map its role to a custom SELinux Users together with the system_r and unconfined_r role. That way you can keep the staff_u SELinux User in its original state and can you modify your User Domain and SELinux user to your requirements.

Conclusion:

Consider removing the Unconfined Domain and or the Unconfineduser Domain to improve security.

Refer: man semanage, man semodule, man visudo, man setsebool, man sudo

SELinux Lockdown Part Seven: SU, Newrole, Sudo and Run_init.

2009-06-25T04:58:00.000-07:00

Before Fedora 9 was released users with access to roles would execute the newrole command to Domain Transition. This command can be installed as policycoreutils-newrole. The user would for example run: newrole -r , and get prompted to enter his user password. The newrole command would than verify whether the users has all access that is required to make the requested domain transition and allow or deny it.

If the user Transitioned to a privileged User Domain and wanted to perform a privileged task, he would then execute the SU command to meet that Discretionary Access Control requirements. The SU command prompts for the root password.

In a strict environment to become a privileged user, one would run two programs and enter two seperate passwords. A privileged user would require access to roots password to perform any privileged task this way.

For a user such as this to run a system service the is another command to execute. The Run_init command performs a Domain transition to the Init Script which in turn starts a system service in its proper Domain. This program also prompts for a password.

That is a lot of passwords and commands just to restart Apache for example.

In Fedora 9 the sudo command was modified to support Domain Transitions. The use of the sudo command is recommended over the SU and Newrole command.
Two main advantages of the Sudo command are that this command allows you to change Linux uid and SElinux Domain Transition in one turn and that you do not need the root password to do so as long as you are added to the /etc/sudoers configuration file.

The destination Domain can be specified as a parameter of the -t option, and the destination role can be specified as a parameter of the -r option. Sudo can also be configured to Transition to a specified role and domain by default in its /etc/sudoers file.

For example: Linux user joe logs into the system as SELinux user joe_u. SELinux User joe_u has access to the joe_r role as well as the webadm_r role and the system_r role. The joe_r role maps to the joe_t User Domain which has all the permissions required for a restricted login user. The joe_t User Domain has access to the system_r role as well as the webadm_r role in policy. An entry for joe in /etc/sudoers is as follows:

joe ALL=(ALL) TYPE=webadm_t ROLE=webadm_r ALL

This entry allows Sudo to transition user joe to webadm_r role and webadm_t role automatically when joe run the sudo command.

Joe logs in and finds himself in the joe_t User Domain. Then when Joe wants to start the Apache service he simple runs: sudo service httpd start.

Sudo changes Joes Linux UID to 0 and transitions Joes' Domain and Role automatically to the specified Role and Domain webadm_t and webadm_r.

Joe also has access to the system_r role that is required to transition to the Init script domain which starts httpd in its proper Domain. The Run_init command is no longer required.

If Joe has access to several roles then Joe can override the default role and domain specified in the Sudo configuration file by specifying the -t and -r options with the destination role and domain parameters.

Conclusion:

Prefer the Sudo command over the SU with Newrole commands.
Prefer access to the system_r role over the Run_init command.

Refer: man su, man sudo, man newrole, man run_init

SELinux Lockdown Part Six: Customized SELinux Roles

2009-06-24T03:27:00.000-07:00

In part four of this series i have demonstrated how to create and implement a customized SELinux User Domain. Creating Roles is done in very much the same way. As mentioned in my previous article about RBAC: Roles are mappings to User Domains. Some User Domains can be used by users to log into the system because those User Domains have permissions to access the user home directory for example. I refer those these User Domains as primary User Domains. Other User Domains are designed to be secondary. Users can Domain Transition using the sudo or su with newrole command to these secondary User Domains. Secondary User Domains can not be used by a user to log into the system.

In this Chapter i am going to demonstrate how such a secondary User Domain is create and implemented. The goal is to create a Privileged SELinux Role that provides the permissions required to manage a Bind DNS service. This role will be based of off the webadm_t User Domain that was discussed previously. I will also revisit some material from part four: Customized SELinux User Domains because the user primary User Domain must be modified to be able to access our new bindadm_r role.

As mentioned i will start with creating a new secondary User Domain called bindadm that is based of off the pre-defined webadm_t SELinux User Domain. The two SELinux Source Policy files i am going base my new User Domain of are:

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

SELinux Source Policy files that have a ".te" extension are called Type Enforcement files. Files with a ".if" extension are called Interface files. Type Enforcement files have Declarations and Policy that are personal or local to the Domain. Interface files have Declarations and Policy that are shared by the Domain with other Domains that may want to interact with our Domain.

mkdir ~/bindadm; cd ~/bindadm;
echo "policy_module(bindadm, 0.0.1)" > bindadm.te;
echo "role bindadm_r;" >> bindadm.te;
echo "userdom_base_user_template(bindadm)" >> bindadm.te;
echo "allow bindadm_t self:capability { dac_override dac_read_search kill sys_ptrace sys_nice };" >> bindadm.te;
echo "files_dontaudit_search_all_dirs(bindadm_t)" >> bindadm.te;
echo "files_manage_generic_locks(bindadm_t) >> bindadm.te;
echo "files_list_var(bindadm_t)" >> bindadm.te;
echo "selinux_get_enforce_mode(bindadm_t)" >> bindadm.te;
echo "seutil_domtrans_setfiles(bindadm_t)" >> bindadm.te;
echo "logging_send_syslog_msg(bindadm_t)" >> bindadm.te;
echo "userdom_dontaudit_search_user_home_dirs(bindadm_t)" >> bindadm.te;

This is the basic contents for a generic privileged secondary User Domain. I left out policy that is specific to managing the Apache service.
Now i will add policy that is specific to managing the Bind service. I am able to borrow this policy from the bind Source Policy. As i mentioned shared policy is located in Interface files. This means that if i want to include shared policy related to Bind i should be able to find this in the bind.te file if the policy is available:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/bind.if

Starting on line 252 in bind.if and ending on line 305 is policy shared by the Bind module to administrate the bind service. I just have to call this Interface in our bindadm Type Enforcement file to include this Policy:

echo "bind_admin(bindadm_t, bindadm_r)" >> bindadm.te;

This concludes my bindadm Type Enforcement file. Next my bindadm Source Policy should share policy that might be required by other Domains to be able to interact with our bindadm_t Domain. I will base this policy of off the webadm.if file.

echo "##

Bind administrator role

" > bindadm.if;

echo "########################################" >> bindadm.if;
echo "##

" >> bindadm.if;
echo "## Change to the bind administrator role." >> bindadm.if;
echo "##

" >> bindadm.if;
echo '## ' >> bindadm.if;
echo "##

" >> bindadm.if;
echo "## Role allowed access." >> bindadm.if;
echo "##

" >> bindadm.if;
echo "## " >> bindadm.if;
echo "## " >> bindadm.if;
echo "#" >> bindadm.if;
echo "interface(\`bindadm_role_change',\`" >> bindadm.if;
echo " gen_require(\`" >> bindadm.if;
echo " role bindadm_r;" >> bindadm.if;
echo " ')" >> bindadm.if;
echo " allow \$1 bindadm_r;" >> bindadm.if;
echo "')" >> bindadm.if;

The Bind Administrator Shared policy above will later be called by our user primary Customized SELinux User Domain. I am now finished with my bindadm_t User Domain.

My next step is to create a Customized SELinux User Domain for our Bind guy and allow that User Domain to transition to the bindadm_r role by calling the bindadm_role_change interface. This Customized SELinux User Domain will be based of off the staff_t User Domain:

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

echo "policy_module(bindguy, 0.0.1)" > bindguy.te;
echo "role bindguy_r;" >> bindguy.te;
echo "userdom_unpriv_user_template(bindguy)" >> bindguy.te;
echo "sudo_role_template(bindguy, bindguy_r, bindguy_t)" >> bindguy.te;
echo "ssh_role_template(bindguy, bindguy_r, bindguy_t)" >> bindguy.te;
echo "kernel_read_ring_buffer(bindguy_t)" >> bindguy.te;
echo "kernel_getattr_core_if(bindguy_t)" >> bindguy.te;
echo "kernel_getattr_message_if(bindguy_t)" >> bindguy.te;
echo "kernel_read_software_raid_state(bindguy_t)" >> bindguy.te;
echo "auth_domtrans_pam_console(bindguy_t)" >> bindguy.te;
echo "libs_manage_shared_libs(bindguy_t)" >> bindguy.te;
echo "seutil_run_newrole(bindguy_t, bindguy_r)" >> bindguy.te;
echo "netutils_run_ping(bindguy_t, bindguy_r)" >> bindguy.te;
echo "domain_read_all_domains_state(bindguy_t)" >> bindguy.te;
echo "domain_getattr_all_domains(bindguy_t)" >> bindguy.te;
echo "domain_obj_id_change_exemption(bindguy_t)" >> bindguy.te;
echo "files_read_kernel_modules(bindguy_t)" >> bindguy.te;
echo "kernel_read_fs_sysctls(bindguy_t)" >> bindguy.te;
echo "modutils_read_module_config(bindguy_t)" >> bindguy.te;
echo "modutils_read_module_deps(bindguy_t)" >> bindguy.te;
echo "miscfiles_read_hwdata(bindguy_t)" >> bindguy.te;
echo "term_use_unallocated_ttys(bindguy_t)" >> bindguy.te;

Now i will call the bindadm_role_change interface that i have defined in the bindadm.if Interface file to allow the bindguy_t User Domain to transition to the bindadm_t SELinux restricted environment:

echo "bindadm_role_change(bindguy_r)" >> bindguy.te;

I can also automatically create a SELinux User Mapping called bindguy_u which is mapped to the bindguy_r, bindadm_r and system_r role. The system_r role is included so that bindadm_t can stop, start and restart the bind system service.

echo "gen_user(bindguy_u, user, bindguy_r system_r bindadm_r, s0, s0 - mls_systemhigh, mcs_allcats)" >> bindguy.te;

To let the login programs know that bindguy is a valid login user i will add default contexts for this user based of off staff_u default contexts:

cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/bindguy_u
sed -i 's/staff/bindguy/g' /etc/selinux/targeted/contexts/users/bindguy_u

Both the bindguy and bindadm policy can now be build and installed:

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i bindguy.pp bindadm.pp

Now i can add a new Linux user with the useradd command and -Z option and bindguy_u parameter:

sudo useradd -Z bindguy_u bindguy

For bindguy to be able to use sudo to automatically transition to Linux user root and SELinux Domain bindadm_t i will add to /etc/sudoers:

echo "bindguy ALL=(ALL) ROLE=bindadm_r TYPE=bindadm_t ALL" >> /etc/sudoers;

When bindguy logs into the system he will find himself in the bindguy_t User Domain which is based of off the staff_t User Domain. The bindguy_t User Domain can domain transition to the bindadm_t User Domain which is a Domain to be used with root access, that can manage the Bind service.

Bindguy would be able to restart the bind service for example by executing:

sudo service named restart

Bindguy will also be able to edit the various Bind content and configuration files. Bindguy will not be able to change the root password for example.

Note: If you found any errors in this exercise or if you have any question or comments, please contact me. Thanks!

refer: man bind, man semodule, man sudo, man useradd

SELinux Lockdown Part Five: SELinux RBAC

2009-06-23T02:54:00.000-07:00

It was explained in part one of this series that SELinux users are mapped to SELinux User Domains and Multi Category Security Components. These mappings can be configured by running the semanage command with the user option, and the SELinux User mappings can also automatically be configured by calling the gen_user() interface in the Type Enforcement Source Module file for your User Domain.

SELinux RBAC is used to be able to assign several SELinux restricted environments to a single SELinux user.

SELinux User Roles are User Domains. When i refer to roles i often mean a SELinux Users' secondary User Domain. Often roles that were designed to be secondary User Domains differ from primary User Domains. This is because Linux Users do not actually use the roles that were designed to be secondary User Domains to log into the system.

Instead Linux users Domain Transition to their secondary role by using the sudo command or a combination of the su and newrole command.

Keep in mind that some roles were designed to be primary User Domains and other roles only support secondary User Domain functionality. Primary User Domains let a user log into the system and secondary User Domains can only be used with the sudo and su with newrole command.

Sysadm Role - An example of a role that is designed to be a primary User Domain:

The sysadm_u SELinux User is mapped to the sysadm_r role. This mapping can be listed by running: sudo semanage user -l | grep sysadm_u

Linux Users that are mapped to the sysadm_u SELinux User operate in the sysadm_r role by default. In this case sysadm_r is a primary User Domain.

The staff_u SELinux User is also mapped to the sysadm_r role. The primary User Domain for the staff_u SELinux user is staff_r role. The default contexts configured in /etc/selinux/targeted/contexts/users/staff_u define what User Domains users should be logged in with by default, and what User Domains users can log in with by for example specifying a User Domain to log in with.

By default a staff_u SELinux User logs into the system in the staff_t User Domain. The sysadm_r role which was designed to be a primary User Domain can optionally be used to log in by using for example: ssh joe/sysadm_r@localhost.localdomain.tld

The sysadm_r role can also be used to Domain Transition by running the sudo and su with newrole command the way secondary User Domains as accessed.

The sysadm_t User Domain is the default environment of operation for the sysadm_u SELinux User and is designed to be the secondary environment of operation for the staff_u SELinux User, but even the staff_u SELinux User can force the pam_selinux Pluggable Authentication Module to use sysadm_t as its primary User Domain.

Webadm Role - An example of a role that is designed to be a secondary domain:

Unlike the sysadm_r role, the webadm_t User Domain cannot be used to log in to the system directly. Instead it must be accessed from another User Domain with the sudo or su with newrole command. The webadm_t User Domain does not have the permissions required to run a full user environment.

To use the webadm_r role, it should be mapped to for example the staff_u SELinux user: sudo semanage user -m -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user staff_u

Please note that you are not encouraged to modify existing SELinux Users. It is preferred that the default SELinux Users are left in their original state. Instead add new customized SELinux Users:

sudo semanage user -a -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user webadm_u
cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/webadm_u

The webadm_r role can only be used as a secondary User Domain for two reason in this example. The first reason is the the webadm_t User Domain does not have enough permissions to support a full login environment. The second reason this that the we have based our webadm_u default context file in /etc/selinux/targeted/contexts/users of off the staff_u default contexts file. In this file the webadm_t User Domain is not a valid context to use for system logins.

Using Roles to confine Root:

Role Based Access Control can be used to create different User Domains with different permissions and assign those roles to SELinux Users. Although RBAC can be used for both unprivileged and privileged users, it is common to use it to restrict the privileged root user.

The webadm_u SELinux user i create above for example can be used to restrict a Linux User with root access to only be able to manage the Apache environment. The staff_t User Domain is unprivileged. This means that if i run in the staff_t User Domain as root, then i will not be able to use the root powers. The webadm_t User Domain is a limited privileged User Domain. If i operate in the webadm_t User Domain as root then i can access root resources that are permitted by the webadm_t restricted environment.

For example, i, dgrift am mapped to the webadm_u SELinux User. I am also allowed all root permissions in the sudoers configuration file in /etc/sudoers. When i log into the system by default i will find myself in the staff_t User Domain. If i run the sudo command as staff_t then i will for example not be able to restart the Apache service.

If i use the sudo command to Domain Transition to webadm_t before restarting the service i will be able to succeed:

sudo -r webadm_r -t webadm_t service httpd restart

If i try to use the sudo command to change root password i will fail because neither staff_t nor webam_t User Domains have access to this privilege.

This is a powerful feature. It means that it is not possible to delegate limited specified root privileges without having to share roots password.

Next i will explain some of the pre-defined roles available:

The guest_r role:
This is a primary User Domain only. See part one in this series for a explanation of the guest_u SELinux user.

The xguest_r role:
This is a primary User Domain only. See part one in this series for a explanation of the xguest_u SELinux user.

The user_r role:
This is a primary User Domain only. See part one in this series for a explanation of the user_u SELinux user.

The staff_r role:
This is a primary User Domain only. See part one in this series for a explanation of the staff_u SELinux user.

The sysadm_r role:
This User Domain can be used as both primary as well as secondary User Domain. The sysadm_u SELinux Users uses sysadm_r as its default role and the staff_u SELinux user uses sysadm_r as its optional role. The sysadm_r role has permissions sufficient for user logins. See part one in this series for a explanation of the sysadm_u user.

The system_r role:
This role is used by the system as a primary role. Users can use the system_r role as a secondary role to restart system services in their proper context.

The unconfined_r role:
This User Domain can be used both as primary as well as secondary User Domain. See part one in this series for a explanation of the unconfined_u user.

The webadm_r role:
This User Domain can be used as secondary User Domain only. This role has does not have access to user home directories and many other privileges required by login users. This User Domain has the permission required to manage the Apache environment.

The logadm_r role:
This User Domain can be used as secondary User Domain only. This role has does not have access to user home directories and many other privileges required by login users. This User Domain has the permission required to manage the logging environment.

Refer: man newrole, man su, man sudo, man semanage

SELinux Lockdown Part Four: Customized SELinux User Domains

2009-06-22T02:51:00.000-07:00

In the first chapter of this series i discussed SELinux users and explained some of the properties of the pre-defined SELinux Users. These profiles should cover most common usage scenarios. In the event that non of the pre-defined SELinux Users really fit a Linux users' profile one can decide to introduce a new restricted environment tailor made to the requirements that are determined.

The easiest way to do this is to base a new custom SELinux User Domain of off a existing one rather then create a new restricted environment from scratch. In this article i will show you how the create a Custom SELinux User Domain that is based of off the user_t restricted user environment. I will also show you ways to map this User Domain to a custom SELinux User so that Linux users can be mapped to this environment as described in the chapter called SELinux Users.

The case is the following: I have to add a restricted user to this system with requirements that are almost identical to the SELinux user user_u. The exeption is the this user also must be able to list the /var mountpoint.

To accomplish this, a new SELinux restricted user environment based of off the user_t User Domain should be created and installed with a SELinux Policy Module. We can extend this Policy Module to allow the listing of /var, and we can create a map for the new User Domain to a new SELinux user. We can also use the semanage command to manually map our new User Domain to a new SELinux User instead of adding this map to the Policy Module itself.

To complete this task i will need access to the SELinux Source Policy for referencing purposes. In this example i will use SELinux Source Policy that is publicly available and browsable at http://oss.tresys.com/projects/refpolicy/browser/trunk/. Although that in this example using upstream Tresys Reference Policy will suffice, it should be noted that in most cases one should refer to distribution specific SELinux Source Policy instead.

First let's have a look that the user_t User Domain SELinux Source Policy Module in the Tresys Source Policy here:
http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/roles/unprivuser.te

Our new User Domain called myuser_t will be based of off this user_t Policy Module. There will be some minor modifications to target the Fedora Distro specific policy instead:

mkdir ~/myuser; cd ~/myuser;
echo "policy_module(myuser, 0.0.1)" > myuser.te;
echo "role myuser_r;" >> myuser.te;
echo "userdom_unpriv_user_template(myuser)" >> myuser.te;

The policy above will create a new SELinux restricted User Domain that is almost identical to that of the user_t user environment that is mapped to the user_u SELinux User in a default installation.

Now i am going to add the policy that allows this environment access to list the /var mountpoint:

echo "files_list_var(myuser_t)" >> myuser.te;

Next i will programmatically map our myuser_t SELinux User Domain to a new SELinux user called myuser_u:

echo "gen_user(myuser_u, user, myuser_r, s0, s0)" >> myuser.te;

Note that the above policy is similar to running the following semanage command manually:

sudo semanage user -a -L s0 -r s0-s0 -R myuser_r -P user myuser_u

Policy for the customized User Domain is now ready. A binary SELinux Policy Module should now be build from the Source Policy:

make -f /usr/share/selinux/devel/Makefile

Alternatively the following commands can be used to build a binary Policy Module:

checkmodule -M -m -o myuser.mod myuser.te
semodule_package -o myuser.pp -m myuser.mod

Install the new binary Policy Module that has been created:

sudo semodule -i myuser.pp

Finally we should define default SELinux Security Contexts for our new SELinux user in order to let the login programs know which User Domain to use:

cp /etc/selinux/targeted/contexts/users/user_u /etc/selinux/targeted/contexts/users/myuser_u
sed -i 's/user/myuser/g' /etc/selinux/targeted/contexts/users/myuser_u

Now we can simply add a new Linux User and map this user to our fresh myuser_u SELinux User with the useradd command and -Z option or with the semanage command with the -m option.

Conclusion:
Instead of modifying default SELinux Users and SELinux User Domains create new ones.

refer: man semodule, man semanage, man checkmodule, man semodule_package

SELinux Lockdown Part Three: Permissive Mode Vs. Permissive Domains

2009-06-21T03:10:00.000-07:00

The SELinux Permissive Mode is a state where SELinux permits violation of SELinux policy system wide. In this system wide permissive state policy violations are merely logged. Permissive Mode can be used to troubleshoot and test SELinux related issues. The complication with a system wide permissive state is that is is wise to operate it in a safe environment and out of production. In some rare scenarios one could consider minimizing the risks that come with Permissive Mode by using the SEPermit Pluggable Authentication Module, but often this measure is not suffice because that only disables Linux user logins. System services remain vulnerable to policy violations.

Recently SELinux Permissive Domains were introduced to mitigate these issues. With Permissive Domains one can run a single SELinux Security Domain in a permissive state. By using Permissive Domains you can keep your system in production and for example disable public access to the Permissive Domain using IPTables, TCP Wrappers, PAM or using other methods.

The semanage command can be used to add and delete SELinux Permissive Domains. You do need to know in which Security Domain a process runs in order to make this Security Domain a Permissive Domain. The ps command used with the -Z option can help you find this information.

Example of how to make the Security Domain called httpd_t for Apache a Permissive Domain:

sudo semanage permissive -a httpd_t

Example of how to make the Security Domain called httpd_t for Apache be enforced again by SELinux:

sudo semanage permissive -d httpd_t

Example of how to use the semanage command to list SELinux Permissive Domains:

sudo semanage permissive -l

Conclusion:

Prefer SELinux Permissive Domains over Permissive Mode.
Add, list and delete Permissive domains with the semanage command.

Refer: man semanage, man tcpd, man pam_sepermit, man iptables

SELinux Lockdown Part Two: PAM SEPermit

2009-06-20T04:13:00.000-07:00

In a previous article i discussed the advantage of mapping Linux users to confined SELinux users. There may be times when you are required to troubleshoot issues on the system or solve issues that require you to operate in SELinux Permissive Mode.

The SELinux Permissive Mode is a state in which SELinux restrictions are not enforced. SELinux does however audit SELinux policy violations that would have normally be prevented. Look at Permissive Mode as a Intrusion Detection System where Enforcing Mode could be considered a Intrusion Prevention System.

In most cases one will want to move the system out of production whilst operating in Permissive Mode. In some cases this may not be so easy.

There are ways to minimize the risks involved with Permissive Mode. A feature that was recently introduced called SELinux Permissive Domains is a preferred method to accomplish this. Permissive Domains will be discussed in a later chapter.

The Pluggable Authentication Module called SEPermit can also help minimizing exposure of Permissive Mode.

PAM SEPermit can disable Linux user logins when the system operates in Permissive Mode. Consider operating a system where your local Linux users are restricted by SELinux. Permissive Mode effectively lifts those restrictions. Linux users may take advantage of this by accessing resources they would otherwise be restricted to use.

In Fedora 11 PAM SEPermit is enabled by default in the various appropriate files in /etc/pam.d/ like for example /etc/pam.d/sshd. One can simply configure SEPermit to disable Linux user logins in Permissive mode by adding Linux users and or SELinux users to the SEPermit configuration file located in /etc/security/sepermit.conf.

Appending %user_u to your sepermit.conf file in /etc/security for example, disable login for SELinux user user_u when the system is in Permissive Mode.

Be aware that SELinux Permissive Mode however also lifts SELinux restrictions for processes other then Linux users like for example system services.

In most cases you are still encouraged to move your system out of the Demilitarized Zone when troubleshooting issues in Permissive Mode. PAM SEPermit can however be helpful in some cases.

Try it out!

Conclusion:

Prefer SELinux Permissive Domains over SELinux Permissive Mode.
If Permissive Mode in a live environment is required on a system with SELinux restricted Linux users then you are encourage to disable Linux user logins with the SEPermit Pluggable Authentication Module.
Be aware that this only affects Linux Users and that system services will not be protected by SELinux in Permissive Mode.

refer: man pam_sepermit, man setenforce, man getenforce

SELinux Lockdown Part One: SELinux Users

2009-06-19T03:54:00.000-07:00

This article is the first in a series about tightening SELinux configuration for Fedora 11.

In Fedora 11, Linux users by default are mapped to the unconfined_u SELinux user. The unconfined_u SELinux user is mapped to the unconfined_r, system_r roles and to all available Multi Category Security compartments.

Both unconfined_r and system_r are roles that map to SELinux security domains. SELinux security domains are defined security environments for processes on the Linux system.

The unconfined security domain, unconfined_t, is a environment reserved for processes that are to a large extend exempted from SELinux restrictions. The system_r role maps to security domains for system processes.

The unconfined_u SELinux user has access to the system_r role to be able to run system processes in their security domains. SELinux user unconfined_u operates in the unconfined_t security domain via the unconfined_r role that it is mapped to.

The semanage command can be used to add, modify and delete Linux user to SELinux user mappings, as well as other settings related to SELinux management. Alternatively the system-config-selinux graphical user interface to semanage can be used to modify these settings.

To use the semanage command to list to which SELinux user, Linux users get mapped by default type: sudo semanage login -l | grep default

__default__ unconfined_u SystemLow-SystemHigh

In the example above Linux users are mapped to the unconfined_u SELinux user by default.

To modify this configuration to map Linux users by default to a confined SELinux user called user_u simply type: sudo semanage login -m -s user_u "__default__"

This will map new Linux users to the restricted user_u SELinux user by default.

You can override this mapping when you run the useradd command to add Linux users with the -Z option. This option specifies to which SELinux user the Linux user should be mapped. For example type: sudo useradd -Z guest_u joe

The usermod command with -Z option can also be used to modify a Linux user to SELinux user mapping.

This will add a Linux user called joe and will map joe to the guest_u SELinux user instead of mapping joe to the defined default SELinux user.

There are some SELinux user profiles predefined. These profiles can be listed with the semanage command. type: sudo semanage user -l

Next i will discuss some of the properties of these predefined SELinux users.

The guest_u SELinux user:

This profile is used for users that need to be tightly controlled. The guest_u SELinux user can only log in using OpenSSH. Guest users have no access to network resources, setuid, setgid programs.

The xguest_u SELinux user:

This profile is identical to that of guest_u. The exception is that Xguest users can only log in to Xwindows and cannot log in using OpenSSH. Another exception of Xguest users is that this partical user can access HTTP port using a SELinux restricted instance of Mozilla Firefox.

The user_u SELinux user:

The user_u SELinux user resembles a ordinary unprivileged SELinux confined user. This user can log in using Xwindows and OpenSSH, has access to network resources, but cannot use setuid and setgid programs.

The staff_u SELinux user:

This SELinux user is identical to user_u except that staff_u can access setuid and getgid programs. The staff_u SELinux user can also stat all process on the system amongst other minor extra privileges compared to user_u.

The sysadm_u SELinux user:

This user is designed for SELinux restricted root login, which is not recommended. This SELinux user is used in a Multi Level Security Environment where there is no unconfined_u.

The unconfined_u SELinux user:

The unconfined_u SELinux user is the environment where all Linux users are mapped to be default in Fedora Targeted policy. This user is to a large extend exempted from SELinux confinement. The exception is Memory Execution Protections.

Real Linux users, not root, should not be mapped to the unconfined_u SELinux user group if you want to improve security on your system. In many scenarios having unconfined users on a system creates a gaping hole in security.

Root logins should be prohibited always. Root should only be able to log in using the terminal in case of an emergency. In Fedora, the Linux user root is mapped to unconfined_u. This means that root logins are almost not protected by SELinux.

The improve the security of root logins one could map the root Linux user to the sysadm_u SELinux user. Although this does not provide much security over unconfined_u, and root will be able to bypass SELinux security.

Bottom line is that root logins should not be permitted except on the terminals in case of emergency.

The system_u SELinux user:

This SELinux user profile is reserved for the system. Linux users should not be mapped to the System_u SELinux user.

I explained how one can define a default SELinux user for new Linux users by default, and i explained how one can override this with the useradd command and -Z option.

The available predefined SELinux users were explained. What is left is to show how SELinux user mappings to Linux users can be altered.

To list all Linux user to SELinux user mappings:

sudo semanage login -l

To manually map a Linux user to a SELinux user:

sudo semanage login -a (...)

To modify a Linux user to SELinux user mapping:

sudo semanage -m (...)

To delete a Linux user to SELinux uper mapping:

sudo semanage -d (...)

Conclusion:

Configure SELinux to map Linux users to confined SELinux users by default to improve security.
Disallow root logins using OpenSSH and Xwindows altogether. Allow root to only login using the terminal in case of emergency. Either leave the root Linux user mapping to the unconfined_u SELinux user or map root to sysadm_u. (for example if you decide to de-install the unconfineduser SELinux module)
Map your Linux users to the appropriate confined SELinux user by using the profile that best fits.
Use the useradd command with -Z option to add Linux users, overriding the default Linux user to SELinux user mapping by the SELinux user that you pass as its argument.

Refer: man semanage, man useradd, man usermod