Dan Walsh's Blog

Fedora 17 New Security Feature part X - Firewalld

dwalsh@redhat.com — Wed, 25 Apr 2012 12:37:48 GMT

FirewallD is a service daemon with a D-BUS interface that provides a dynamic managed firewall.

It will be the default firewall in Fedora 18, but will be available to run in Fedora 17.

NOTE: I was informed that this feature was supposed to be default in Fedora 17, but has been decided to wait until Fedora 18.

The problem with the previous firewall model was that it was static, you would need to basically reload the firewall rules any time you made a change, and this would break established connections. This is a real problem for virtualization (libvirt), since you might be changing your firewall often bringing up and down virtual machines. FirewallD provides a daemon that applications can talk to over DBUS, to request modifications to firewall rules.

Another nice feature would be to allow a user to have rules that control firewall rules depending on the wireless network to which they connect. For example NetworkManager could come up with a question of whether this is the Home Network, Work Network or Public Network. Firewall rules might allow Avahi to connect if you are on a Home or Work network but not a Public Network.

In the future I would like to add make FirewallD a SELinux Userpace Manager. This would allow a policy writer could to control which applications are able to manipulate firewall rules pertaining to which ports. Something like

allow cupsd_t cups_port_t:tcp_firewall { open close };

Fedora 17 New Security Feature part IX - File Name Transitions

dwalsh@redhat.com — Tue, 24 Apr 2012 14:12:18 GMT

File Name Transitions were introduced to the kernel in Fedora 16 by Eric Paris.

Eric actually expected policy writers to only add a few dozen file name transition rules, well in Fedora 17 we now have nearly 100,000 rules:

sesearch -T /etc/selinux/targeted/policy/policy.27 | grep \" | wc -l
94736

Most of these rules are to make devices created in /dev and files/directories created by the unconfined/admin processes be labelled correctly. A common problem users of SELinux have seen was when an unconfined_t user creating /root/.ssh or $HOME/.ssh. Then they would place authorization content in the directory. When they tried to use the content to gain access to the system via sshd, sshd would be blocked from the directory by SELinux because the directory and its contents had the wrong label. The user needs to run restorecon -R -v /root/.ssh to fix the labels.

Before File Name Transitions the directory would be created with the label based on the label of /root, admin_home_t. But as of Fedora 16 Policy Writers write rules that say: "If the unconfined_t user creates a directory named .ssh in a directory labelled admin_home_t, it will get created as ssh_home_t."

type_transition unconfined_t admin_home_t : dir ssh_home_t ".ssh";

How is this a security feature?

I explained in a previous blog, there are three ways content gets labeled within a directory. The File Transition rule is a mechanism the policy writer has used since SELinux was first developed to create content within a directory with a different label then the directories label. Policy writers wrote rules that said if a process running as NetworkManager_t created a file in a directory labeled etc_t it would be labeled net_conf_t.

type_transition NetworkManager_t etc_t : file net_conf_t;

Or if a process running as mozilla_t created a directory in a directory labeled user_home_dir_t, it would get created as mozilla_home_t.

type_transition mozilla_t user_home_dir_t : dir mozilla_home_t;

But this is not very fine grained control. A hacked NetworkManager could create any file in a any directory labeled etc_t, if it did not exist. If /etc/passwd did not exist for some reason SELinux would not block a confined NetworkManager from creating its own /etc/passwd. A hacked firefox running as mozilla_t would not be blocked from creating a missing $HOME/.ssh directory.

With File Name Transition rules, policy writers can now specify the file name. Meaning we can writer finer grained control. We can say NetworkManager can only create the "resolv.conf" file in a directory labeled etc_t or a confined firefox can only create the .mozilla directory in a users home directory

As an example of this the Thumbnail confinement added in Fedora 17 has:

type_transition thumb_t user_home_dir_t : file thumb_home_t "missfont.log";
type_transition thumb_t user_home_dir_t : dir thumb_home_t ".thumbnails";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-12";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-10";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-0.10";
type_transition thumb_t user_home_dir_t : dir gstreamer_home_t ".gstreamer-0.12";

Which means thumbnailers running as thumb_t can only create a file labelled missfont.log or directories labeled .thumbnails or .gstreamer-* in the home directory.

Nice job Eric, you increased the Security of SELinux and made it easier to use at the same time!

runuser versus su

dwalsh@redhat.com — Wed, 28 Mar 2012 12:40:09 GMT

Many years ago, we noticed SELinux having problems with the su command. Many confined domains were using su to switch user from root to some non privileged user. But this would generate lots of bogus SELinux errors such as:

Domain X_t wants to getattr on the fingerprint device or look at the pid file of the Smart Card reader.

su using the pam_stack was the cause of these errors. Depending on which pam_modules you had in the /etc/pam.d/su configuration, certain access would be checked. Services using su do not want/need these side effects of using the pam stack. SELinux policy writers do not want to allow the access or add dontaudit rules all over the place.

In order to fix this, we built a new application called runuser. runuser is actually built from the su.c source code. You just define the RUNUSER constant when compiling su.c. Basically runuser is just the su command with the pam stack removed as well as verifying the command is running as root, not setuid.

Whenever an service is running as root and wants to change UID using the shell it should use runuser.

When you are logged in to a shell as a user and want to become root, you should use su. (Or better yet sudo)

Eating my own dogfood.

dwalsh@redhat.com — Thu, 22 Mar 2012 14:19:45 GMT

I am going on a trip tomorrow, I went to the Jet Blue web site to print my boarding pass. The Jet Blue site has what I believe is a java application running in the browser that displays your boarding pass. I pressed the "Print" button on the screen and a print dialog came up, without any printers, and the "Print" button grayed out.   I did not notice the, setroubleshoot warning in gnome 3. Figuring the print application was just broken, I decided to select print from the browser. Sadly the browser printed a blank page. I then bad mouthed Firefox/Linux printing.

Mia Culpa

I noticed that I had AVC's that looked like mozilla_plugin_t was trying to getattr on lpr_exec_t.    I put mozilla_plugin_t into permissive mode, to find out all the access required.

# semanage permissive -a mozilla_plugin_t

I went back to Jet Blue and tried to print the boarding pass again. This time the printers showed up and I was able to print my boarding pass.

Now I had AVC's that indicated mozilla_plugin_t was executing lpr_exec_t. Also lpr was connecting to the cups and gnome-keyring daemon.

Should I transition or add allow rules for mozilla_plugin_t?

As a policy writer I had to choice whether to allow mozilla_plugin_t all of these accesses or have mozilla_plugin_t transition to the lpr_t domain when it executes /usr/bin/lpr.   These decisions are key to writing good security policy. My rule of thumb is if the domain i would transition to is very powerful, I hesitate to transition. Especially if the parent application requires limited access when executing the child. For example a user can run rpm in their current domain (staff_T) to list all rpm packages, while if I allowed them to transition to the rpm_t domain, they would be allowed install rpm packages. In the mozilla_plugin_t case the advantage of transitioning to lpr_t allows me to continue to prevent mozilla plugins from talking directly to the cups server and the gnome-keyring and lpr_t is a very limited domain, so I chose to transition.

My initial policy looked like this:

policy_module(mypol, 1.0)

require {
    type mozilla_plugin_t;
}
lpd_domtrans_lpr(mozilla_plugin_t)

Now I tried to print the boarding pass again, and now I had AVC's that stated lpr_t was trying to connect to keyring.

audit2allow -R indicated that I should use:

gnome_stream_connect_gkeyringd(lpr_t)

audit2allow also showed that I was failing on Roles Based Access Control (RBAC).   Users seldom see these types of errors. They show up in the log file as SELINUX_ERR rather then AVC.

type=SELINUX_ERR msg=audit(1332420617.119:909): security_compute_sid: invalid context staff_u:staff_r:lpr_t:s0-s0:c0.c1023 for scontext=staff_u:staff_r:lpr_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:lpr_t:s0-s0:c0.c1023 tclass=unix_stream_socket

This AVC is basically saying the staff_u:staff_r:lpr_t:s0-s0:c0.c1023 is an invalid label.

Hard to tell from this error what is wrong, but luckily audit2allow translates this into:

role staff_r types lpr_t;

Since I run with the staff_r role, I had to add an RBAC rule that would allow staff_r role to reach the lpr_t type.

My final policy looks like:

policy_module(mypol, 1.0)
require {
    type mozilla_plugin_t;
    type lpr_t;
    role staff_r;
}
lpd_domtrans_lpr(mozilla_plugin_t)
role staff_r types lpr_t;
gnome_stream_connect_gkeyringd(lpr_t)

Notice how I am transitioning from mozilla_plugin_t to lpr_t. This does not mean staff_t will transition to lpr_t when running /usr/bin/lpr.
In fact, staff_t executes lpr in the staff_t domain, since the staff_t domain has the ability to connect to the cups and gnome-keyring daemons.

But when staff_t executes a firefox plugin, the plugin will transition to a locked down domain mozilla_plugin_t. When the mozilla_plugin_t plugin executes /usr/bin/lpr, the lpr command will transition to the lpr_t domain.

Printing now works well. Now I can remove the permissive flag from mozilla_plugin_t.

# semanage permissive -d mozilla_plugin_t

I have added all these rules into Fedora 17 policy, it should show up in the next policy update.

This is why I live in Rawhide, I want to find problems before users do.

Solution to /myapache labeling problem from yesterday...

dwalsh@redhat.com — Tue, 20 Mar 2012 13:30:25 GMT

Twitter's @Plaimclock tweeted me @rhatdan yester.
He pointed out that yesterdays blog on SELinux Labeling did not provide a solution to the /myapache problem.

The solution is to label /myapache and all its children with a label httpd can read.

You can figure this out by using:

man httpd_selinux
...
      httpd_sys_content_t

       - Set files with the httpd_sys_content_t type, if you want to treat the
       files as httpd sys content.

       Paths:
            /usr/share/icecast(/.*)?,                  /usr/share/htdig(/.*)?,
            /etc/htdig(/.*)?,                         /var/www/svn/conf(/.*)?,
            /usr/share/doc/ghc/html(/.*)?,       /usr/share/mythtv/data(/.*)?,
            /var/lib/htdig(/.*)?,                         /srv/gallery2(/.*)?,
            /srv/([^/]*/)?www(/.*)?,               /usr/share/ntop/html(/.*)?,
            /usr/share/mythweb(/.*)?,                /var/lib/cacti/rra(/.*)?,
            /usr/share/openca/htdocs(/.*)?,            /usr/share/selinux-pol‐
            icy[^/]*/html(/.*)?,   /usr/share/drupal.*,   /var/lib/trac(/.*)?,
            /var/www(/.*)?, /var/www/icons(/.*)?

Or

# ls -lZd /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

You could simply put the labels in place using chcon.

chcon -R -t httpd_sys_content_t /myapache

The best solution is to tell SELinux about the label change.

# semanage fcontext -a -t httpd_sys_content_t '/myapache(/.*)?'
# restorecon -R -v /myapache

Done

Note: If you wanted to allow httpd to write to the directory you would use the httpd_sys_rw_content_t type.

SELinux Types Revisited.

dwalsh@redhat.com — Mon, 19 Mar 2012 16:06:00 GMT

A common mistake people make with SELinux is thinking all types are the same.

I often get bugzilla's from people who first got a bug saying that httpd_t can not read some directory, say /myapache. The admin then does some limited research and discovers the chcon command. The admin then assumes if he uses the chcon command with the httpd type, it will solve his problem.

# chcon -t httpd_t /myapache
chcon: failed to change context of `/myapache' to `staff_u:object_r:httpd_t:s0': Permission denied

What, wait I am unconfined_t, why won't this be allowed.

# setenforce 0
# chcon -t httpd_t /myapache
#

Works, I guess I am all set.
# setenforce 1

Apache blows up.

Now they have AVC messages that indicate they need

allow unconfined_t httpd_t:dir relabelto;
allow httpd_t fs_t:filesystem associate;

Since the admin forced the label onto the system, other parts of SELinux start to break. Later locate runs and they get an AVC that requires

allow locate_t httpd_t:dir getattr;

What the ...

The assumption, the administrator mistakenly made, was that all types are created equally. But SELinux groups different types and then controls what "Classes" they can be assigned to. SELinux block you from assigning a type to unsupported objects.

For example SELinux has types for Files (file_type), Processes(domain), Ports (port_type), Ethernet Interfaces (netif_type), Node names (node_type), filesystems (filesystem_type) ...

Types are grouped together using the policy attribute notated above within the ().

SELinux only allows administrators to assign file_type to a filesystem_type object. This access is controlled by the associate access.

# sesearch -A -s file_type -t filesystem_type -p associate | grep file_type
   allow file_type fs_t : filesystem associate ;
...

If you want to list all file_types, execute:

seinfo -afile_type -x
   file_type
      bluetooth_conf_t
      cmirrord_exec_t
      colord_exec_t
...

I have added an setroubleshoot plugin to Fedora 17 to try to help the administrator out.

SELinux is preventing chcon from relabelto access on the directory myapache.

***** Plugin associate (99.5 confidence) suggests **************************

If you want to change the label of myapache to httpd_t, you are not allowed to since it is not a valid file type.
Then you must pick a valid file label.
Do
select a valid file type. List valid file labels by executing:
# seinfo -afile_type -x

Hope this hopes, although I agree this is a difficult concept to understand.

Secure Boot versus Ksplice.

dwalsh@redhat.com — Thu, 15 Mar 2012 12:50:56 GMT

I have been attending many talks on Secure Boot. The basic idea behind secure boot is to ensure that the bios/bootloader and kernel have not been hacked. My understanding of how this is done is everything is signed and verified during the bootup. Nothing can run in the kernel that was not signed and verified.

Then we Oracle pushing Ksplice.

I can't help but ask the question?

Is ksplice a security disaster waiting to happen?

Fedora 17 New Security Feature part VIII - New SELinux Domains in F17

dwalsh@redhat.com — Tue, 13 Mar 2012 14:47:35 GMT

Each Fedora we release a bunch of new domains that will run in permissive mode for the release. When the next release is released, the permissive domains are made enforcing.

In my blog,10 things you probably did not know about SELinux.. #4, I describe how you can interact with permissive domains.

Any ways these are the permissive domains in Fedora 16 that will now be confined.

Fedora 16 Permissive Domains

pptp_t quota_nld_t sshd_sandbox_t nova_ajax_t nova_api_t nova_compute_t nova_direct_t nova_network_t nova_objectstore_t nova_scheduler_t nova_vncproxy_t nova_volume_t rabbitmq_epmd_t rabbitmq_beam_t deltacloudd_t iwhd_t mongod_t thin_t chrome_sandbox_nacl_t matahari_sysconfigd_t

Fedora 17 Permissive Domains

couchdb_t (/usr/bin/couchdb)
blueman_t (/usr/libexec/blueman-mechanism)
httpd_zoneminder_script_t (/usr/libexec/zoneminder/cgi-bin(/.*)?)
zoneminder_t (/usr/bin/zmpkg.pl)
selinux_munin_plugin_t (/usr/share/munin/plugins/selinux_avcstat)
sge_shepherd_t (/usr/bin/sge_shepherd)
sge_execd_t (/usr/bin/sge_execd)
sge_job_t
matahari_rpcd_t (/usr/bin/sge_execd)
keystone_t (/usr/bin/keystone-all)
pacemaker_t (/usr/sbin/pacemakerd)

Of course I reserve the right to add to this list. our goal is to make sure all init/dbus services run with a type other then initrc_t.

If you see a process on your machine that is shipped from Fedora running as initrc_t, please open a bugzilla on SELinux policy.

Fedora 17 New Security Feature part VII - thumbnail protection.

dwalsh@redhat.com — Mon, 12 Mar 2012 15:55:56 GMT

John Leyden wrote an interesting article Linux vulnerable to Windows-style autorun exploits, about how security researches had discovered that Linux is potentially vulnerable to a user sticking a USB device or CDRom into a locked machine. The basic idea was that "Nautilus" would execute thumbnail drive code, to display thumbnails icons in the file browsers based on the content on the removable media, even if the machine was locked. If the thumbnail executables were vulnerabile, a cracker could use the code used to process the thumbnail images to kill the screensaver/lock.

Never mind this, just plugging in a USB stick when you a logged in, could allow a cracker to take over your machine.

At that time, I wrote policy for all thumbnail drivers to be locked down with SELinux, but I only turned it on for confined users.
I and other users have been running this confinement thoughout Fedora 16.

In Fedora 17 I have turned this on for the unconfined user.

We are confining the following applications.

/usr/bin/evince-thumbnailer
/usr/bin/ffmpegthumbnailer
/usr/bin/gnome-exe-thumbnailer.sh
/usr/bin/gnome-nds-thumbnailer
/usr/bin/gnome-xcf-thumbnailer
/usr/bin/gsf-office-thumbnailer
/usr/bin/raw-thumbnailer
/usr/bin/shotwell-video-thumbnailer
/usr/bin/totem-video-thumbnailer
/usr/bin/whaaw-thumbnailer
/usr/lib(64)?/tumbler-1/tumblerd

I have seen these applications try to "execstack" when running mplayer executable on an thumbnails, kind of scary.

If you know of other thumbnail applications that get launched as thumbnails, please tell me.

Fedora 17 New Security Feature part VI - man pages for SELinux user/role domains

dwalsh@redhat.com — Thu, 08 Mar 2012 16:46:18 GMT

Ok, maybe this should be Security Feature IV.5 but Roman numerals do not support decimal points. :^)

After I wrote the tool to generate service domains man pages, Miroslav Grepl thought it would be a good idea to generate similar policy for user domains and roles.

We hacked up a new script called segenuserman, which generates 13 new SELinux user and Role man pages.

auditadm_selinux.8 git_shell_selinux.8 logadm_selinux.8 secadm_selinux.8 sysadm_selinux.8 user_selinux.8 xguest_selinux.8 dbadm_selinux.8 guest_selinux.8 nx_server_selinux.8 staff_selinux.8 unconfined_selinux.8 webadm_selinux.8

Note segenuserman also requires senetwork.py.

Here is the staff_selinux.8 for an SELinux user, and webadm_selinux.8 for an SELinux role.

I have also updated the SELinux service domain man pages to include booleans,process types, file context paths, better descriptions, network ports.

Here is an update zebra_selinux.8

Excuse me son, but your code is leaking !!!

dwalsh@redhat.com — Thu, 08 Mar 2012 04:34:27 GMT

I have written over the years about leaked file descriptors, and what a pain they have been to SELinux.

C on Unix many many years ago was designed to leak by default. A file descriptor is leaked if you open a file descriptor or socket and then do a fork/exec. The new process will automatically get access to the file descriptor unless SELinux blocks it.

When SELinux blocks the leaked file descriptor you usually end up with a strange looking AVC about the new domain trying to read or write a random file or a socket owned by the parent or even worse an ancestor.

Talking with Uli Drepper the other day about leaked file descriptors. He reminded me that the gcc/glibc teams had added a flags to open,fopen, socket, accept4 to change the default.

man open
...
By default, the new file descriptor is set to remain open across an execve(2) (i.e., the FD_CLOEXEC file descriptor flag described in fcntl(2) is initially disabled; the O_CLOEXEC flag, described below, can be used to change this default).
...
O_CLOEXEC (Since Linux 2.6.23) Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Additionally, use of this flag is essential in some multithreaded programs since using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor at the same time as another thread does a fork(2) plus execve(2).

Sadly this can not be made the default, but as a good programing practice all open/socket,accept and fopen calls should use this flag in order to close the file descriptor by default.

open(path, O_CLOEXEC | flags)
socket(DOMAIN, SOCK_CLOEXEC | type, PROTOCOL)
accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, SOCK_CLOEXEC | flags);
fopen(path, "re")

If you can not open a file descriptor with one of these commands then you can execute

fctnl(fd, F_SETFD, FD_CLOEXEC)

He gcc developers or code analysys tools, you probably should catch when leaks happen, especially if they are not STDIN, STDOUT, STDERR.

Just be neat and stop leaking all over the place.

bash completion for setsebool/getsebool added for Fedora 17

dwalsh@redhat.com — Tue, 06 Mar 2012 16:43:32 GMT

policycoreutils-python-2.1.10-26.fc17.x86_64 now has bash completion scripts for semanage and setsebool/getsebool

/etc/bash_completion.d/semanage-bash-completion.sh
/etc/bash_completion.d/setsebool-bash-completion.sh

# getsebool -<tab>
# getsebool -a

# getsebool samba_<tab>
samba_create_home_dirs   samba_export_all_ro      samba_share_fusefs
samba_domain_controller samba_export_all_rw      samba_share_nfs
samba_enable_home_dirs   samba_run_unconfined

# setsebool -<tab>
# setsebool -P<tab>

# setsebool -P samba_<tab>
samba_create_home_dirs   samba_export_all_ro      samba_share_fusefs
samba_domain_controller samba_export_all_rw      samba_share_nfs
samba_enable_home_dirs   samba_run_unconfined

semanage completion is a little more complicated.

# semanage <tab>
boolean     fcontext    login       node        port
dontaudit   interface   module      permissive user

# semanage fcontext -<tab>
-a           -d           --deleteall -f           --help       --modify
--add        -D           -e           --ftype      --locallist -t
-C           --delete     --equal      -h           -m           --type

# semanage fcontext -a -t samba<tab>
samba_etc_t                     samba_secrets_t
sambagui_exec_t                 samba_share_t
samba_initrc_exec_t             samba_unconfined_script_exec_t
samba_log_t                     samba_unit_file_t
samba_net_exec_t

...

Try it out. If you find problems, patches accepted... :^)

senetwork: new tool for examining SELinux networking policy.

dwalsh@redhat.com — Fri, 02 Mar 2012 21:35:09 GMT

A couple of years ago I added some python bindings for setools. I hoped we would start to see new tools arise to analyze SELinux policy. Maybe making SELinux easier to user and understand.

Lately I have gone back to these tools and started playing with them to see what tools I could build.

Last couple of days I have hacked together a little script called senetwork.

The goal was to answering questions like:

What ports can a particular domain connect to? Bind to?

# senetwork ftpd_t
ftpd_t tcp name_connect
    ephemeral_port_t: 32768-61000
    ldap_port_t: 389,636,3268
    dns_port_t: 53
    ocsp_port_t: 9080
    kerberos_port_t: 88,750,4444
ftpd_t tcp name_bind
    ephemeral_port_t: 32768-61000
    ftp_port_t: 21,990
    ftp_data_port_t: 20
    unreserved_port_t: 1024-32767,61001-65535
    port_t: all ports with out defined types

What type(s) are associated with a particular port number?

# senetwork 8080
8080: tcp unreserved_port_t 1024-32767
8080: udp unreserved_port_t 1024-32767
8080: tcp http_cache_port_t 8080

What ports are associated with a particular port_type?

# senetwork ftp_port_t
ftp_port_t: tcp: 21,990
ftp_port_t: udp: 990

Basically senetwork looks at the argument and figures out whether or not it is a number, port type or domain type
and then prints out the information.

I plan on packaging up these little scriptlets with setools-console.

VMWare wants you to turn SELinux off? Really?

dwalsh@redhat.com — Thu, 01 Mar 2012 13:50:07 GMT

i·ro·ny
1. The use of words to convey a meaning that is the opposite of its literal meaning: the irony of her reply, “How nice!” when I said I had to work all weekend.
2. an outcome of events contrary to what was, or might have been, expected.

One of the great features of KVM Virtualization is that each virtual machine is wrapped in an SELinux sandbox. All the software used to run a virtual machine on a host is called a hypervisor. When you run virtual machines, you have to worry about hypervisor vulnerabilities, which would allow your guest operating system to attack the host or other virtual machines you have running on the host.

We strive to make the Linux KVM Hypervisor as secure as possible, but bugs happen. SELinux can control what the virtual machine process can and can not do on the host machine. If you are running virtual machines on you Fedora or Red Hat box, you really should be running SELinux in enforcing mode.

It has come to my attention that VMWare support is suggesting people turn off SELinux... I guess SELiux is too complicated for the VMWare crack support team to handle.

At Red Hat we consider security a priority, VMWare I am not so sure.

If you are having a problem running any VMWare product on a RHEL or Fedora Operating system, contact me dwalsh@redhat.com and I will help you run your virtual machines and leave the security in place...

April 2011 "How it Works" issue of Popular Science, by Marie Pacella

Fedora 17 New Security Feature part VI - systemd-journal

dwalsh@redhat.com — Wed, 29 Feb 2012 14:53:13 GMT

There has been a lot written about the systemd-journal, this link gives a pretty good description of why it is good from a security point of view, although I don't see this as a full replacement of syslog.

http://techspear.com/2011/11/systemd-journal-an-alternate-for-the-syslog/

Since the syslog format is ubiquitous, I don't see it going away. Also systemd-journal caused a lot of people who were working on "Structured Logging" to get all up in arms over it, since Lennart and Kay did not work with them.

I still like it.

systemd has become the central point of launching system apps, so it knows more about what is going on in the system then any other process save the kernel.

Years ago when the audit system was being build Karl MacMillan of Tresys believed that some of the problems that the audit system was trying to fix could be handled by extending syslog to record all the information about the sending process. ALL of the UIDs associated with a process as well as recording the SELinux Context. Systemd-journald now does this.

Let me give an example of where systemd-journal could be used to increase security.

SELinux controls processes by only allowing them to do what they were designed to do. Sometimes even less depending on the security goals of the policy writer. This means SELinux would prevent a hacked ntpd process from doing anything other then handle Network Time. SELinux would prevent the hacked ntpd from reading mysql database or credit card data from the users home directory, even if the ntpd process was running as root. However, since the ntpd process sends syslog messages, SELinux would allow the hacked process to continue to send syslog messages. The hacked ntpd could format syslog messages to match other daemons and potentially trick and administrator or even better a tool that reads the syslog file (Intrusion detection tools?) into doing something bad. If all messages were verified with the systemd-journal then the administrator or syslog analysis tool could notice that ntpd_t is sending messages about sshd, and we could realize your ntpd daemon was hacked.

.cursor=s=f328cc4b2615417189ab76b00c7ae041;i=2;b=4c3d0faf6b774fb7930972c1a4a5f87
.realtime=1329940273078467
...skipping...
SYSLOG_IDENTIFIER=sshd
SYSLOG_PID=2302
MESSAGE=sshd Fake message from sshd.
_PID=2302
_UID=0
_GID=0
_COMM=ntpd
_EXE=/usr/sbin/ntpd
_CMDLINE=/usr/sbin/ntpd -n -u ntp:ntp -g
_SYSTEMD_CGROUP=/system/ntpd.service
_SYSTEMD_UNIT=ntpd.service
_SELINUX_CONTEXT=system_u:system_r:ntpd_t:s0
_SOURCE_REALTIME_TIMESTAMP=1330527027590337
_BOOT_ID=4c3d0faf6b774fb7930972c1a4a5f870
_MACHINE_ID=432d8198a8fc421caf2dca48ccde1cf2
_HOSTNAME=dhcp-189-250.bos.redhat.com

Fedora 17 New Security Feature part V - sudo can now use sssd for authorization data (sudoers)

dwalsh@redhat.com — Tue, 28 Feb 2012 17:03:55 GMT

Currently sudo can be configure to read the /etc/sudoers file locally or to look it up via sudoers content via LDAP. The LDAP server provides a useful feature for organizations which wanted to centralize authorization data.

But, as in all types of centralized authorization/authentications systems, it does not work well when your machine is disconnected
from the network.

sssd - System Security Services Daemon to the rescue.

sssd was added to Fedora a few releases ago, as I blogged about back in March 2011.

One of the biggest benefits of sssd is that it allows for disconnected access to cached authorization/authentication data.
A new feature in Fedora 17 adds sssd as a source for sudoers data.

The benefits of this integration as described on the feature page are:

offline access - sudoers rules would be stored in a persistent cache, allowing sudo to fetch the rules seamlessly even in cases when the LDAP server is not reachable such as user roaming with a laptop.
unified configuration of LDAP parameters such as the servers used, timeout options and security properties at one places (sssd.conf)
sudo would take advantage of the advanced features SSSD has such as server fail over, server discovery using DNS SRV lookups and more
only one connection to the LDAP server open at a time resulting in less load on the LDAP server and better performance

And from an SELinux point of view one less network access for the sudoers application.

caching of the rules - less load on the LDAP server and better performance on the client side as the client wouldn't have to go to the server with each request
back end abstraction - data may be stored in NIS or other databases and accessed by the sudo transparently

Imagine if sssd and IPA could eventually cache SELinux Roles/Confined Users, maybe sometime in the not too distant future ...

Fedora 17 New Security Feature part IV - man pages for SELinux service domains

dwalsh@redhat.com — Mon, 27 Feb 2012 16:11:34 GMT

A couple of weeks ago, I began to look at the man pages for SELinux policy that we had written for SELinux several years ago.    I wanted to update them and maybe add a few new ones.    When I looked at the httpd_selinux man page, I noticed it was missing lots of descriptions of booleans and file types associated with the httpd domain. When I started adding the boolean definitions, I quickly became board and realized this would not scale.

I decided to write a tool genman.py, that would query the SELinux Policy and write a man page for every executable service domain.
DOMAIN_selinux.8

I made a few assumptions that a service domain had an entrypoint ending in "_exec_t". Which we have pretty much standardized on. Then I truncated the first part of the name off and searched for types and booleans containing this name.

httpd_exec_t -> httpd for example.

I actually took is a step further and truncated a "d" off if the domain name ended in "d", since this is common.

httpd -> http.

Booleans have a description in policy so this was fairly easy to add to the man pages.

# semanage boolean -l | grep http

Would give you all the booleans that mention http, for example.

Since we don't have a description for each file type associated with a domain, I had to hard code a big it/then table with common definitions, for example.

def explain(f, k):
    if f.endswith("_var_run_t"):
        return "store the %s files under the /run directory." % prettyprint(f, "_var_run_t")

Then I added a special section for any domains that use public_content_t.

Bottom line the tool was generated over 400 man pages that have been added to the selinux-policy-doc rpm.

For example abrt man page.

Are these man pages perfect? NO.

But they are a lot better then nothing. Now if you want to know the types/and or booleans associated with a service, all you need to execute is man SERVICE_selinux.

If anyone wishes to enhance this, by perhaps adding file context definitions, patches welcomed...

Fedora 17 New Security Feature part III - systemd starting daemons

dwalsh@redhat.com — Fri, 24 Feb 2012 17:02:20 GMT

Ok, this is not really a new feature in Fedora 17.

systemd has been starting some daemons in Fedora 16, but more and more daemons and privileged processes are being started by systemd in 17.

Why is this a security feature?

Symbols: @ means Execute, -> indicates transition, === indicates a client/server communication

In the past daemons would be started in two ways. At boot init (sysV) launches an initrc script and then this script would launch the daemon, or an admin could log in and launch the init script by hand causing the daemon to run.

From an SELinux point of view this looked like:

init_t @ initrc_exec_t -> initrc_t @ httpd_exec_t -> httpd_t:
This apache processes would end up running with the full label of:
system_u:system_r:httpd_t:s0
If apache created content it would be labeled
system_u:object_r:httpd_sys_content_rw_t:s0

When an administrator started restarted the process say through service httpd restart
unconfined_t @initrc_exec_t -> initrc_t @httpd_exec_t -> httpd_t
The process would adopt the user portion of the SELinux label that started it
unconfined_u:system_r:httpd_t:s0
Content would be created by this apache would be:
unconfined_u:object_r:httpd_sys_content_rw_t:s0
SELinux ends up confusing the user since we have to ignore the user componant of the SELinux label. If you wanted to write policy to confine based on user type, you can't.

With systemd this improves greatly.

The transitions is very different.
init_t @ httpd_exec_t -> httpd_t
system_u:system_r:httpd_t:s0

But if you want to restart the Apache daemon as admin you now do.
unconfined_t === init_t @ httpd_exec_t -> httpd_t
system_u:system_r:httpd_t:s0

With systemd we don't have the labeling problem and we can tighten up the SELinux policy.

Systemd starting daemons affects more than just SELinux.

Over the years lots of vulnerabilities and administration failures had to be worked around because of admins restarting daemons. Daemons need to be coded to cleanup any leaked information from the admin process influencing the way the Daemon ran.

Need to clean $ENV
Need to change working directory

cd / in order to make sure they don't blow up because they lack access to the current working directory (service script does for them).

Need do something with the terminal, close stdin, stdout, stderr after they start.

In SELinux we are always in a quandary about this, since if we allow the daemon access to the terminal, a hacked daemon could present the admin with passwd: and trick him into revealing the admin password.)

Changing the controlling terminal
Change the handling of signals
...

If a daemon writer screws up on one of these he could make the system vulnerable or end up with unexpected bugs.

Using systemd to start daemons, guarantees the daemon always gets started with the same environment whether they are started at boot or restarted by an administrator.

Fedora 17 New Security Feature part II - PrivateTmp

dwalsh@redhat.com — Thu, 23 Feb 2012 14:34:28 GMT

One of the reasons I am really excited about Fedora 17 is amount of new Security Features we have added, and not all of them involve SELinux ...

As I blogged a few weeks ago, we have stopped the ability for one process to look at another processes memory even if they have same UID, with the deny_ptrace feature.

PrivateTmp

But today I want to talk about PrivateTmp. One of my goals over the years has been to stop system services from using /tmp.

I blogged about this back in 2007. Any time I have found out a daemon was using /tmp, I tried to convince the packager to move the content to /run directory if it was temporary or /var/lib if it was permanent.

Over the years there have been several vulnerabilities (CVEs) about this. For example:

CVE-2011-2722, which covered a case where hplib actually included code like.

fp = fopen ("/tmp/hpcupsfax.out", "w"); // <- VULN
system ("chmod 666 /tmp/hpcupsfax.out"); // <- "

Meaning if you setup a machine running cups daemon, a bad user or a application that a user ran could attack your system.

I have convinced a lot of packages to stop using /tmp, but I can't get them all and in some cases services like Apache,  need to use /tmp.   Apache runs lots of other packages that might store content in /tmp.

Well systemd has added lots of new security features (more on these later).  

PrivateTmp, which showed up in Fedora 16,  is an option in systemd unit configuration files.

      > man system.unit
       ...
       A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a   
     swap file or partition, a start-up target, a file system path or a timer controlled and supervised by systemd(1).

     > man systemd.exec
     NAME
       systemd.exec - systemd execution environment configuration
     SYNOPSIS
       systemd.service, systemd.socket, systemd.mount, systemd.swap
     DESCRIPTION
       Unit configuration files for services, sockets, mount points and swap devices share a subset of configuration 
       options which define the execution environment of spawned processes.
      ...
       PrivateTmp=
           Takes a boolean argument. If true sets up a new file system namespace for the executed processes and mounts a 
           private /tmp directory inside it, that is not shared by processes outside of the namespace. This is useful to secure 
           access to temporary files of the process, but makes sharing between processes via /tmp impossible. 
           Defaults to false.

PrivateTmp causes systemd to do the following any time it starts a service with this option turned on:

   Allocate a private "tmp" directory
   Create a new file system namespace 
   Bind mount this private "tmp" directory within the namespace over /tmp
   Start the service.  

This means that processes running with this flag would see a different and unique /tmp from the one users and other daemons sees or can access.

Note:  We have found bugs using PrivateTmp in Fedora 16, so make sure you test this well before turning it on in Production.

For Fedora 17, I opened a feature page that requested all daemons that were using systemd unit files and /tmp to turn this feature on by default.

Apache and Cups now have PrivateTmp turned on by default in Fedora 17, along will several other daemons.

Giving three options as a Developer of System Service, I still believe that you should not use /tmp, you should use /run or /var/lib.  But if you have to use /tmp and do not communicate with other users then use PrivateTmp.  If you need to communicate with users be careful...

How can I allow a process to listing all processes on a system.

dwalsh@redhat.com — Mon, 20 Feb 2012 16:45:00 GMT

SELinux blocks lots of domains from listing all processes on the system.

Lots of useful information can be optained from reading the process info on a machine, so we would like to block this by default. But sometimes users/policy writers really need to allow their domains to be able to list the processes on a system.

Ole on the Fedora SELinux Users Mail list asked:

I have a problem with SELinux not allowing PHP to list other users' processes with the "ps" command.

If I disable SELinux with "setenforce 0" it works immediately.

Is it possible to allow PHP to do this without disabling SELinux completely?

Processes are listed by reading all of the contents of /proc. SELinux linux labels everything in /proc based on the label of the process.

ps -eZ | grep sshd | head -1
system_u:system_r:sshd_t:s0-s0:c0.c1023 853 ? 00:00:00 sshd

ls -lZ /proc/853 | head -1
dr-xr-xr-x. root root system_u:system_r:sshd_t:s0-s0:c0.c1023 attr

If you want a confined process to run ps, it needs to list /proc/PID, it needs to read certain files in this directory, needs to read symbolic links in this directory and needs to getattr on the process.   When writing policy we have added a macro for this access.

define(`ps_process_pattern',`
    allow $1 $2:dir list_dir_perms;
    allow $1 $2:file read_file_perms;
    allow $1 $2:lnk_file read_lnk_file_perms;
    allow $1 $2:process getattr;
')

If we wanted to allow one process type (myuser_t) to read another process /proc data on sshd (sshd_t), we would need to write a line like:

ps_process_pattern(myuser_t, sshd_t)

What if I want to allow a type to list all processes types?

In SELinux policy language we use attributes are used to group multiple types together.
SELinux calls processes "domains". When we write policy we always give process types the domain attribute.

So if you wanted to allow a process myuser_t to list all the processes on a system, you would write a rule like.

ps_process_pattern(myuser_t, domain)

Dominic Grift answered Ole question by suggesting he install a local policy module that looked like:

policy_module(mytest, 1.0.0)
gen_require(` 
  type httpd_t; 
  attribute domain; 
')
ps_process_pattern(httpd_t, domain)

This works great.  Note that the apache daemon runs all php scripts within its process space, to they run as httpd_t.

Another solution would be to use an interface that we have defined in policy to allow this, domain_read_all_domains_state.  

The /usr/share/selinux/devel/include/kernel/domain.if interface file defines several interfaces that can be used to interact with all domains.  An alternative policy module could have been written:

policy_module(mytest, 1.0.0)
gen_require(` 
  type httpd_t; 
')
domain_read_all_domains_state(httpd_t)

SELinux problems on Fedora 17.

dwalsh@redhat.com — Mon, 13 Feb 2012 20:35:38 GMT

Anyone that has tried Fedora 17 over the last couple of days, might have noticed SELinux going nuts and blocking logins.

systemd had a bug which was causing transitions to break.

The way the system is supposed to work is during boot systemd reads in the policy file on disk and then loads policy into the kernel.
This causes all processes at that are running to be labeled kernel_t.

systemd then reads the label on its image file /sbin/systemd (init_exec_t) and the label that it is currently running as (kernel_t), then it asks the kernel what label would the /sbin/systemd process get if kernel_t executed it. The answer would be init_t, and then systemd is supposed to set the current label to init_t. From that point on all processes started by systemd would transition to their proper domains.

Well just before systemd/Fedora 17 Alpha was about to be released. Systemd changed the location of its executable from /bin/systemd to /usr/lib/systemd/systemd. But they never changed the checking code. We fixed policy to look at the new location and labeled /usr/lib/systemd/systemd correctly, but when systemd checked for the label of /bin/systemd, there was no file and systemd just continued running as kernel_t. Since there are few rules for transitions of kernel_t to any other label, most of the system was labeled as kernel_t. Finally when a user logged in via gdm or login or sshd, they were running as kernel_t and the code transitioned them to abrt_t, one of the few domains kernel_t will transition to.

systemd-42-1.fc17 fixes this problem, so if you update to this systemd or later, you should be able to run your system in enforcing mode.

Needless to say, we have been flooded with bug reports...

secommunicate is a handy little tool to analyze policy communication

dwalsh@redhat.com — Tue, 07 Feb 2012 16:50:33 GMT

I wrote about setrans back in October.

setrans is a tool that you could use to analyze policy to see if how one process domain transitions to another process domain.

Today I got asked what type should a user assign to a file so that one process type "syslogd_t" could write and another process type "httpd_t" could read.

I answered the question that httpd_log_t would be a good candidate. Then he asked could figure this out?

My suggestion was he could use these commands.

# sesearch -A -s syslogd_t -c file -p write

Which will search for all types that syslogd_t can write.

# sesearch -A -s httpd_t -c file -p read

Which will search for types httpd_t can read, then he could look at the intersection of these commands.

Only that did not work...

# sesearch -A -s syslogd_t -c file -p write

Does not return my suggestion of httpd_log_t. It did however return an attribute "logfile" which includes httpd_log_t.
Attributes are the way to group lots of types together. And the sesearch command does not expand out the attributes.

I decided to go off an play with python and create secommunicate. The goal of this command is to print out a list of types that a source process type can write and a target process type can read.

This little python script takes a source process type and a target process type and an optional class, defaulting to "file". It uses the sesearch python bindings to search the selinux policy for:

What class types can the source type write?
What class types can the target type read?
It expands all attributes into the associated types
Then it generates the intersection of these types, and prints them out.

./secommunicate syslogd_t httpd_t
puppet_tmp_t
afs_cache_t
dirsrv_var_log_t
nagios_log_t
httpd_log_t
user_cron_spool_t
root_t

./secommunicate -c chr_file syslogd_t httpd_t
user_tty_device_t
devtty_t
initrc_devpts_t
null_device_t
zero_device_t

Seems like it could be a handy tool.

Not sure how we should package or ship setrans and secommunicate, or what the correct syntax would be, but for those struggling to understand policy these seem to be handy tools.

./secommunicate -h
usage: secommunicate [-h] [-c TCLASS] [-s SOURCEACCESS] [-t TARGETACCESS]
                     source target

SELinux Communication Analysys Tool

positional arguments:
source                Source type
target                Source type

optional arguments:
-h, --help            show this help message and exit
-c TCLASS, --class TCLASS
                        Class to use for communications, Default 'file'
-s SOURCEACCESS, --sourceaccess SOURCEACCESS
                        Comma separate list of permissions for the source type
                        to use, Default 'open,write'
-t TARGETACCESS, --targetaccess TARGETACCESS
                        Comma separated list of permissions for the target
                        type to use, Default 'open,read'

Note:
If you wanted to know if a one domain can communicate with another domain via signals, you could just use

sesearch -A -s syslogd_t -t httpd_t -c process
Found 1 semantic av rules:
   allow syslogd_t domain : process getattr ;

Dan Walsh on Twitter @rhatdan

dwalsh@redhat.com — Mon, 06 Feb 2012 22:03:25 GMT

I guess I never blogged this. But I have been tweeting for a while as rhatdan. (Not so creative name).

And as always I will almost never tweet something that does not have to do with SELinux or Security....

Follow me if you like.

Small change to semanage login record creation.

dwalsh@redhat.com — Mon, 06 Feb 2012 15:24:04 GMT

For those of you that use confined users, I have recently made a change to semanage that you may or may not notice. This change will be back ported to RHEl6 also.

In the previous version of semanage, when you created a login user mapping, if you did not specify the level or range of the user, semanage would default the level to s0.

OLD
# semanage login -a -s staff_u dwalsh
# semanage login -l | grep dwalsh
dwalsh                    staff_u                   s0

In the new version of the tool, the semanage command will take the range of the SELinux user, staff_u, and assign it to the login record.

NEW
# semanage user -l | grep staff_u
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
# semanage login -a -s staff_u dwalsh
# semanage login -l | grep dwalsh
dwalsh                    staff_u                   s0-s0:c0.c1023

I believe this is the correct behavior especially since if you specified a SELinux whose range did not include s0, the tool would blow up.

# semanage user -l | grep topsecret_u
topsecret_u         user       s15         s15-s15:c0.c1023                 staff_r sysadm_r system_r
# semanage login -a -s topsecret_u dwalsh
Would generate a error saying invalid range.

Of course if you specify the level/range it will override the SELinux user level.

Why I love Open Source... II

dwalsh@redhat.com — Fri, 03 Feb 2012 17:23:11 GMT

When SELinux does a full relabel, it prints a * for each 1000 files that it relabels.

Some users were complaining about a full relabel and not being able to estimate how much time was left.

I explained to them that I did not know how many files were on the file system, so I could not estimate how much time was left. They explained to me that there was ways to look at the file system and get then number of inodes, and then you could estimate how much time was left. I told them patches accepted, and within a couple of days, I got a patch from John Reiser.

As of policycoreutils-2.1.10-21.fc17

If you do a touch /.autorelabel; reboot or a fixfiles restore

You will see output like

# fixfiles restore
10%

With the counter slowly rising.

Open source opens the possibility for all of us to contribute and make the whole better.

Thanks John.