Planet SELinux

James Morris: Reminder: CFP for the 2012 Linux Security Summit closes in 1 week!

jamesm — Wed, 16 May 2012 21:45:17 +0000

A reminder for folks planning to submit proposals for the upcoming Linux Security Summit in San Diego — the CFP closes on the 23rd of May, a week from now.

LSS is one of eight co-located developer events at LinuxCon this year, including the Kernel Summit and Plumbers. It’s shaping up to be an epic event!

James Morris: Kernel Security Talk at LinuxCon Japan

jamesm — Wed, 02 May 2012 01:57:49 +0000

Just to let folk know — I’ll be giving a talk on the state of Linux kernel security development at LinuxCon Japan in Yokohama on June 8th. From the abstract:

In this talk, we’ll examine the current state of the Linux kernel security subsystem. Starting with a brief overview of existing features, we’ll discuss recent developments, current efforts and future directions. We’ll also discuss the evolving threat landscape, and the increasing need for mobile and cloud security. This will be a high-level technical discussion aimed at IT professionals. A good general knowledge of operating system and computer security concepts will be advantageous.

I’ll also likely be in Tokyo briefly — if any kernel security development folk there want to meet up, let me know.

Dan Walsh: Fedora 17 New Security Feature part X - Firewalld

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

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 };

Dan Walsh: Fedora 17 New Security Feature part IX - File Name Transitions

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

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!

Russell Coker (security): Neighborhood Watch

etbe — Sun, 22 Apr 2012 16:00:28 +0000

While writing my previous post I heard a huge noise at the front of my house. I found one man being restrained in a seated position on the ground at my front door, the man who was holding him down was accusing him of theft and asking me to call the police, and a woman was hanging around and crying.

When calling the police I discovered that Optus (the Telco that provides the virtual service which Virgin Mobile uses) doesn’t accept 112 as an emergency number! This combined with the fact that CyanogenMod 7 on my phone doesn’t accept 000 as an emergency number meant that I had to unlock my phone before calling the police. Unlocking your phone late at night when there’s a situation that needs police attention isn’t as easy as you would hope. As an aside there are usually no penalties for testing the emergency service on your phone, people who install PABX systems and other significant telephony devices test emergency services calls as a matter of routine, so testing emergency calls from your phone is a really good idea. If anyone knows how to configure CyanogenMod 7 to support 000 as an emergency call then please let me know!

Anyway the man who was held down claimed that a friend of his had given him a bag containing tools that he had lugged from some place not particularly near my house. The man who was holding him down said that he witnessed the other man stealing the tools from his neighbor – not far from my house. The woman was apparently the girlfriend of the man who was accused of burglary.

The end result was that the police arrested the man who was accused of burglary and his girlfriend. He didn’t have any obvious injuries and the police said that the man who detained him did them a favor, so it seems unlikely that there will be any assault charges filed. Presumably the man who detained the burglar is explaining it all at the police station now, I hope the police gave him a chance to put on pants and shoes first.

The man who made the burglary accusation said that his house was robbed last night which is why he was more observant than usual tonight.

This makes me glad of my policy of rejecting every job offer which involves moving to the US. In Australia hand guns are really hard to get so there’s no way that a house burglary will involve a gun and there’s also no way that someone who wants to help the police will have a gun. So while it was unpleasant to have this happen at my front door it didn’t involve any risk to me. It could have ended up with someone other than me getting a beating but the probability of serious injury or death for them was quite low. As everyone knew that no-one had a gun and no-one wanted to be charged with assault it made sense for everyone to avoid excessive force. From what I saw no excessive force was used.

The police arrived fairly quickly and EVERYONE was glad to see them. All up it took a bit more than 30 minutes from the first noise to the police departing after arresting both suspects and filling out a bunch of paperwork. I was impressed by that!

CyanogenMod and the Galaxy S Thanks to some advice from Philipp Kern I have now...

James Morris: 2012 Linux Security Summit (San Diego) – Call for Particpation

jamesm — Thu, 12 Apr 2012 14:00:09 +0000

The 2012 Linux Security Summit (LSS) has been announced. The CFP is open from now until the 23rd of May.

This year, the summit will be a two-day event, co-located with LinuxCon, Linux Plumbers, and the Kernel Summit. We’re planning on holding developer break-out sessions for much of the second day, and extending the length of the main talks to the more traditional 45 minute + 15 minute break format. There will still be shorter 30 minute talks, and roundtable discussions.

Check out the programs from previous years to see what kind of proposals have been previously accepted:

LSS 2011, Santa Rosa
LSS 2010, Boston

Send your proposals to the program committee per the announcement.

Russell Coker (security): The Security Benefits of Automation

etbe — Fri, 30 Mar 2012 12:42:29 +0000

Some Random WTFs

The Daily WTF is an educational and amusing site that recounts anecdotes about failed computer projects. One of their stories titled “Remotely Incompetent” concerns someone who breaks networking on a server and is then granted administrative access to someone else’s server by the Data Center staff [1]!

In one of the discussions about that I saw people make various claims about Data Center security, such as claiming that having their own locked room helps. My experience indicates that such things don’t do much good, I have often been granted access to server rooms without appropriate checks.

My experience is that security guards on site generally don’t directly do any good. I once had a guard hold a door for me when I was removing a server from a DC without even bothering to ask for ID! On another occasion in the Netherlands I had a security guard who didn’t speak English unlock the wrong server room for me, I used hand gestures to inform him that I needed access to the room with the big computers and he gave me the access I needed! It seems that the benefit of security guards is solely based on scaring people who don’t have the confidence needed to bluff their way in. Preventing children from thieving is a good thing,

On another occasion I showed ID and signed in for access to a DC owned by my employer and I used my security key to go through a locked door with a sign that promised many bad consequences if I failed to lock the door behind me. Then I discovered that the back door was wide open for the benefit of some electricians who were working in the building. Presumably the electricians who had no security training were expected to act as ad-hoc security guards if someone tried to enter through the back door – presumably they would not have been good at it.

When a company uses part of their own office for a server room then many of these problems disappear. But a common issue in such ad-hoc DCs is the lack of planning and procedures, I have lost count of the number of times I’ve seen doors (and even windows) propped open to allow ventilation because there were too many servers for the air-conditioning to cope. The most ironic example of this is the company that had a walk-in safe (think of a small bank vault with concrete walls and thick solid steel door) used for storing servers but with it’s door propped open to allow cooling. The advantage of a serious hosting company is that they will have procedures for cooling etc and will be very unlikely to do strange and silly things.

Having a locked room in a DC makes some sense, but if security guards have the master keys and are allowed to use them then it might not do much good. The one time I locked my keys in such a room I had a guard let me in without verifying my ID or the claim that there were actually keys locked in the room. Presumably anyone could just claim to have forgotten their keys and get the door unlocked – just like a cheap hotel.

Locking a rack sounds like a good idea, but the racks I’ve seen have had locks which are quite easy to pick. On the one occasion when I had to pick a lock on a rack (due to keys being too difficult to manage for the relevant people) the security guards didn’t investigate, so either the security cameras were not supervised or they just didn’t care about people picking locks in a shared server room. Also if you allow people to do things freely in a shared server room they could install devices to monitor network traffic.

A locked cage in a server room should work well. In the one case where I worked for a company that used such a cage I found it to mostly work well – apart from the few weeks when the lock was broken.

One company that I worked for had scales before the door between a server room and the car-park to prevent people from stealing heavy servers. Of course that wouldn’t stop people stealing hard drives full of data which is worth more than the servers! Also an over-weight colleague had to have the scales disabled for him (as they were based on absolute mass not unexpected changes in an individual’s mass) which presumably means that any skinny employee could steal a 2RU server and still be below the mass threshold.

How to Solve some of these Problems

Computers are subject to all manner of security problems. But they tend not to do arbitrary things for no apparent reason and they will never give in to someone who is charming, attractive, or aggressive – unlike humans.

I have servers running on Hetzner, Linode, and the Rackspace Cloud. I am always concerned about possible security compromises. But I am not worried about someone climbing in a window of a server room or convincing a security guard to let them in through the door. All three of those hosting companies have the vast majority of interactions automated. I can change many aspects of the servers without involving ANY human interaction. Out of the three of those companies I have had some human interaction with Hetzner (who provide managed servers) when a hard drive needed to be replaced – obviously replacing a disk in the wrong server would have been a significant system integrity issue even though everyone would be running RAID-1 and if Hetzner improperly disposed of the broken disk then there could be security issues – but this is an unlikely mistake in the face of a rare occurrence. With Linode and the Rackspace Cloud (and the previous Slicehost hosting that was purchased by Rackspace) the most common interactions I have with employees of those companies are when my clients don’t pay their bills on time – and that’s an administrative not a technical issue. When I do have to contact the support people about a technical issue it’s usually something that’s not immediately connected to the virtual server (EG a loss of routing to the DC).

It seems most likely that there are a fairly small number of people who are allowed in the DCs for companies like Hetzner, Linode, and Rackspace. Those people would probably be recognised by the security guards and their work would be restricted to replacing failing hardware and not involve granting access requests. There are some unusual requests that they can process (EG one of my clients recently transferred a virtual server between business units) but even in those cases the administrative software controls who gets access. This is much better than just handing hardware access to what seems to be the correct physical server to a client.

If you have software running a few computers and operating correctly then you can probably scale it up to run thousands of computers and have it still work correctly. But if you have a team of people controlling access requests and want to scale it up significantly then there are huge problems in hiring skilled people and training them correctly. There is a real risk of security flaws in such administrative software, if someone managed to exploit the automated management system for one of those three companies then they could probably gain access to the private data of any of their customers. But the risk of this seems a lot less than the risk of general incompetence among humans who perform routine and boring tasks which have the potential for great errors.

[1] http://thedailywtf.com/Articles/Remotely-Incompetent.aspx

The Security Benefits of Being Unimportant A recent news item is the “hacking” of the Yahoo...
Security Lessons from a Ferry On Saturday I traveled from Victoria to Tasmania via the...
Public Security Cameras There is ongoing debate about the issue of security cameras,...

Dan Walsh: runuser versus su

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

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)

Dan Walsh: Eating my own dogfood.

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

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.

Dan Walsh: Solution to /myapache labeling problem from yesterday...

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

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.

Dan Walsh: SELinux Types Revisited.

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

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.

Dan Walsh: Secure Boot versus Ksplice.

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

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?

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

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

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.

Dan Walsh: Fedora 17 New Security Feature part VII - thumbnail protection.

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

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.

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

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

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

Dan Walsh: Excuse me son, but your code is leaking !!!

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

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.

Dan Walsh: bash completion for setsebool/getsebool added for Fedora 17

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

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

Russell Coker (security): SE Linux Status in Debian 2012-03

etbe — Tue, 06 Mar 2012 06:44:33 +0000

I have just finished updating the user-space SE Linux code in Debian/Unstable to the version released on 2012-02-16. There were some changes to the build system from upstream which combined with the new Debian multi-arch support involved a fair bit of work for me. While I was at it I converted more of them to the new Quilt format to make it easier to send patches upstream. In the past I have been a bit slack about sending patches upstream, my aim for the next upstream release of user-space is to have at least half of my patches included upstream – this will make things easier for everyone.

Recently Mika Pflüger and Laurent Bigonville have started work on Debian SE Linux, they have done some good work converting the refpolicy source (which is used to build selinux-policy-default) to Quilt. Now it will be a lot easier to send policy patches upstream and porting them to newer versions of the upstream refpolicy.

Now the next significant thing that I want to do is to get systemd working correctly with SE Linux. But first I have to get it working correctly wit cryptsetup.

SE Linux Status in Debian 2011-10 Debian/Unstable Development deb http://www.coker.com.au wheezy selinux The above APT sources.list...
SE Linux Status in Debian 2012-01 Since my last SE Linux in Debian status report [1]...
Debian SE Linux Status At the moment I’ve got more time to work on...

Dan Walsh: senetwork: new tool for examining SELinux networking policy.

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

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.

Dan Walsh: VMWare wants you to turn SELinux off? Really?

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

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

Dan Walsh: Fedora 17 New Security Feature part VI - systemd-journal

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

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

Dan Walsh: 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 +0000

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 ...

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

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

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...

Dan Walsh: Fedora 17 New Security Feature part III - systemd starting daemons

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

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.

Dan Walsh: Fedora 17 New Security Feature part II - PrivateTmp

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

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...

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

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

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)

Dan Walsh: SELinux problems on Fedora 17.

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

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...

James Morris: End of an Era (for me)

jamesm — Fri, 10 Feb 2012 08:31:45 +0000

I just finished my last day at Red Hat, where I’ve worked as a kernel hacker since 2003. I’ve been fortunate to work with so many brilliant people there on challenging and rewarding projects—like SELinux. If someone had told me in 1999 that Linux would by now be fitted with a mandatory access control system from the NSA, which was enabled by default in major distributions, and certified and deployed in the field, I would have been skeptical. To play a direct role in that would have been a dream come true. It was.

I’ve also had the opportunity to work extensively within the community, during which time I’ve co-maintained or maintained kernel networking, crypto, SELinux and, currently, the security subsystem. This work has taken me around the world and allowed me to make many new friends.

It’s been a great adventure.

Recently, I decided to make some changes in my career path and seek out some new challenges. I’ll be starting in a new role the week after next. I can’t say much about that now, but I will be continuing with my current upstream commitments.

Dan Walsh: secommunicate is a handy little tool to analyze policy communication

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

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: Dan Walsh on Twitter @rhatdan

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

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.

Dan Walsh: Small change to semanage login record creation.

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

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.

Dan Walsh: Why I love Open Source... II

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

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.

Dan Walsh: 10 things you probably did not know about SELinux, #10 shipping policy versions

dwalsh@redhat.com — Thu, 02 Feb 2012 15:14:21 +0000

Can I install a policy module built on RHEL6 on a RHEL5 box?

First you need to understand policy is compiled statically. Even if you use interfaces, all the rules are compiled into the policy.pp file.
If you use policy_module(mypol, 1.0), this will generate a gen_require(` ') block for all of the permissions, classes defined in policy.
Meaning if you compile a policy on RHEL6 and install it on RHEL5 using policy_module(mypol,1.0) you are likely to fail with an error like:

# semodule -i mypol.pp
libsepol.permission_copy_callback: Module mypol depends on permission open in class file, not satisfied
libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed!

This is the compiler telling you that you tried to install a policy module that required the "open" permission and RHEL5 policy, and kernel for that matter, has no idea what the "open" permission is.

I guess the analogy would be compiling an executable on RHEL6 that uses a function call in a shared library that does not exists on a RHEL5 box, it won't work.

Usually we recommend that you compile policy on the oldest machines policy that you plan on supporting, then it should be installable on all future versions of that policy. We don't tend to remove accesses.

Can I install a policy module built on RHEL5 on a RHEL6 box?

Yes you can, but it probably will not work the way you expect!

In RHEL5 the access required to read a file was:

define(`read_file_perms',`{ getattr read ioctl lock }')

In RHEL6 the access required to read a file was:

define(`read_file_perms',`{ open getattr read ioctl lock }')

So if you compile in a line like:

allow httpd_t mysecret_t:file read_file_perms;

On RHEL5 this would allow the apache type to read files labeled mysecret_t, but if you compiled it on RHEL5 and installed it on RHEL6, apache would not be allowed to "open" the file so the access would fail.

Bottom Line:

If you want to ship policy for two MAJOR DIFFERENT VERSIONS of RHEL then you would need to compile a version for RHEL5 and for RHEL6.

Policy should work for all Minor versions, as long as you compile on the oldest, supported version, although it might work if you compile on a newer version and install on an older version.

Meaning a compiled version of policy on RHEL6.1 should work on RHEL6.2, RHEL6.3 ...

Dan Walsh: More on deny_ptrace ...

dwalsh@redhat.com — Wed, 01 Feb 2012 15:03:43 +0000

This boolean brings into conflict two of my top goals with SELinux.

1. Make the system secure by default.

The problem with most security systems is NO ONE turns them on. NO ONE increases the security of their system.
Now while these are exaggerations, I would bet you that 99 % of SELinux users never turn on confined users, or disable the unconfined module . There are large numbers of people who run SELinux in permissive mode or even disabled. If we shipped Fedora and RHEL with SELinux disabled, I would bet the number of people who would enable it would be infinitesimally small. So when I add a feature, I always think about how it would help the vast majority of people. Will this boolean make my Wife's computer more secure.

2. Keep the unconfined domain unconfined...

Read the blog for why uses expect things to just work, especially from their logged in accounts, especially if they are the admin.

Should deny_ptrace be on by default????

Well deny_ptrace actually confines the unconfined domain, so it conflicts with #2, but if I don't turn it on, for the most part people will not take advantage. Most users would not see the benefit. Right now I am going to turn it on by default (Of course I reserve the right to change my mind, or be beaten into submission.) Any person who wants to disable it permanently can execute.

# setsebool -P deny_ptrace 0

Programmers and system admins if you get a "permission denied" or "Operation not supported" error with ptrace, strace or gdb, it is SELinux causing the problem, and if you need to debug a problem, you can turn the boolean on temporarily.

# setsebool deny_ptrace 0

And do your thing.

Since sysadmins and programmers understand Linux best, it would be easier for them to toggle the security feature.

Now some questions about this feature.

What happened to allow_ptrace boolean in RHEL versions and older Fedora's?

I originally thought about extending allow_ptrace, but I thought I had better just create a new boolean and remove the old.

allow_ptrace only effected confined users. But since hardly anyone used confined users, I thought I needed a better way to describe the feature, and change its name. I have removed allow_ptrace and now deny_ptrace will remove all ptrace, sys_ptrace that I know about from the system.

Does deny_ptrace guarantee no domains on my system can ptrace another domain?

NO
If you load a custom policy with an "allow XYZ self:process ptrace", this boolean will not effect it. So it only effects actually policy shipped by Fedora or Red Hat.
deny_ptrace does not effect permissive domains, or permissive mode (obviously), so if you want to make sure no processes can execute ptrace, you need to disable permissive domains.

After you turn on the deny_ptrace boolean, you can check if any domains are still able to ptrace by executing

# sesearch -A -C -p ptrace,sys_ptrace | grep -v ^D

What about separation between root and users?

Well SELinux does not know anything about UID users, so root and non root mean nothing to SELinux. The only way to get this distinction is by setting up confined users and then say run as staff_t as non root and then transition to unconfined_t, or sysadm_t or a confined admin type. But since hardly anyone uses confined users, this is not an option, if I want to make most computers more secure.

Could you add a bunch of booleans that allows us to turn on and off ptrace per confined domain?

Well this is not really necessary, since most confined domains can not ptrace now, or only could ptrace because of some bugs in the kernel that generated ptrace avc's when running the ps command as root or if a process examined the /proc/PID files of another process. We have fixed these kernel issues and are removing most domains ability to ptrace permanently, Ie turning deny_ptrace off DOES not allow every domain the ability to ptrace, only a few select domains that we believe might need it. (Really just user domains.)

Dan Walsh: Fedora 17 New SELinux Feature part I - deny_ptrace

dwalsh@redhat.com — Tue, 31 Jan 2012 18:43:57 +0000

The deny_ptrace feature allows an administrator to toggle the ability of processes on the computer system from examining other processes on the system, including user processes. It can even block processes running as root.

Most people do not realize that any program they run can examine the memory of any other process run by them. Meaning the computer game you are running on your desktop can watch everything going on in Firefox or a programs like pwsafe or kinit or other program that attempts to hide passwords..

SELinux defines this access as ptrace and sys_ptrace. These accesses allow one process to read the memory of another process. ptrace allows developers and administrators to debug how a process is running using tools like strace, ptrace and gdb. You can even use gdb (GNU Debugger) to manipulate another process running memory and environment.

The problem is this is allowed by default.

My wife does not debug programs, why is she allowed to debug them? As a matter of fact most of the time, I am not debugging applications, so it would be more secure if we could disable it by default.

I created a feature for Fedora 17 called SELinuxDenyPtrace

Here is a youtube video demonstrating the SELinuxDenyPtrace feature.

Check it out.

Russell Coker (security): SE Linux Status in Debian 2012-01

etbe — Wed, 25 Jan 2012 11:36:31 +0000

Since my last SE Linux in Debian status report [1] there have been some significant changes.

Policy

Last year I reported that the policy wasn’t very usable, on the 18th of January I uploaded version 2:2.20110726-2 of the policy packages that fixes many bugs. The policy should now be usable by most people for desktop operations and as a server. Part of the delay was that I wanted to include support for systemd, but as my work on systemd proceeded slowly and others didn’t contribute policy I could use I gave up and just released it. Systemd is still a priority for me and I plan to use it on all my systems when Wheezy is released.

Kernel

Some time between Debian kernel 3.0.0-2 and 3.1.0-1 support for an upstream change to the security module configuration was incorporated. Instead of using selinux=1 on the kernel command line to enable SE Linux support the kernel option is security=selinux. This change allows people to boot with security=tomoyo or security=apparmor if they wish. No support for Smack though.

As the kernel silently ignores command line parameters that it doesn’t understand so there is no harm in having both selinux=1 and security=selinux on both older and newer kernels. So version 0.5.0 of selinux-basics now adds both kernel command-line options to GRUB configuration when selinux-activate is run. Also when the package is upgraded it will search for selinux=1 in the GRUB configuration and if it’s there it will add security=selinux. This will give users the functionality that they expect, systems which have SE Linux activated will keep running SE Linux after a kernel upgrade or downgrade! Prior to updating selinux-basics systems running Debian/Unstable won’t work with SE Linux.

As an aside the postinst file for selinux-basics was last changed in 2006 (thanks Erich Schubert). This package is part of the new design of SE Linux in Debian and some bits of it haven’t needed to be changed for 6 years! SE Linux isn’t a new thing, it’s been in production for a long time.

Audit

While the audit daemon isn’t strictly a part of SE Linux (each can be used without the other) it seems that most of the time they are used together (in Debian at least). I have prepared a NMU of the new upstream version of audit and uploaded it to delayed/7. I want to get everything related to SE Linux up to date or at least with comparable versions to Fedora. Also I sent some of the Debian patches for the auditd upstream which should reduce the maintenance effort in future.

Libraries

There have been some NMUs of libraries that are part of SE Linux. Due to a combination of having confidence in the people doing the NMUs and not having much spare time I have let them go through without review. I’m sure that I will notice soon enough if they don’t work, my test systems exercise enough SE Linux functionality that it would be difficult to break things without me noticing.

Play Machine

I am now preparing a new SE Linux “Play Machine” running Debian/Unstable. I wore my Play Machine shirt at LCA so I’ve got to get one going again soon. This is a good exercise of the strict features of SE Linux policy, I’ve found some bugs which need to be fixed. Running Play Machines really helps improve the overall quality of SE Linux.

[1] http://etbe.coker.com.au/2011/10/31/selinux-status-2011-10/

Status of SE Linux in Debian LCA 2009 This morning I gave a talk at the Security mini-conf...
SE Linux in Debian I have now got a Debian Xen domU running the...
Debian SE Linux Status At the moment I’ve got more time to work on...

KaiGai Kohei: [OSS/Linux] PG-Stromにプロファイラをつけてみた

kaigai — Thu, 19 Jan 2012 06:45:53 +0000

1月6日(金)に書いた『しゅとろ〜む、しゅとろ〜む』の記事は割と反響が大きかったようだ。

コメント欄に次のような質問を頂いたので、試してみることにする。

通りすがりさん wrote:

すばらしい成果ですね．

カラム指向的にデータを持っていること自体が性能向上に寄与しているということはないですか？

(通常 + CPU) vs (カラム指向+GPU)で比較をされていますが，

(通常 + CPU) vs (カラム指向+CPU) vs (カラム指向+GPU) の評価にも興味があります．

plan.c 内の is_device_executable_qual() 関数が常に false を返すようにすれば、条件句の処理をCPUだけで行うようになる。これは (カラム指向+CPU) と同等である。

1,000万件のレコードを持つ、通常のテーブル t1 と、PG-Strom管理下のテーブル t2 に対してそれぞれ以下のクエリを実行してみた。

■ １回目（バッファにデータが乗っていない状態）

(通常 + CPU)
Timing is on.
postgres=# SELECT COUNT(*) FROM t1 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 8041.237 ms

(カラム指向 + CPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 8660.486 ms

(カラム指向 + GPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 4667.643 ms

■ ２回目（バッファにデータが乗っている状態）

(通常 + CPU)
postgres=# SELECT COUNT(*) FROM t1 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 7016.732 ms

(カラム指向 + CPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 6733.771 ms

(カラム指向 + GPU)
postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
 count
-------
  6718
(1 row)

Time: 173.351 ms

(通常+CPU)と(カラム指向+CPU)の比較で、ディスクからの読み出しが発生する場合にカラム指向の方が8%程度遅いという結果になっている。

複雑な条件句を設定したために、I/OよりもCPUバウンドな処理になっている事、xとyにはランダムな値を入れているために、全く圧縮が効いていないのが一因かもしれない。

(カラム指向 + GPU)で２回目の方が早くなっているのは、主にGPUコードのJITコンパイルの処理時間の違いによるものだろう。JITコンパイルにここまで時間がかかることは稀だが、確実にI/Oを発生させるために Linux の Page Cache をクリアしてから測定を行ったため、nvccコマンドもOSのキャッシュから弾き出されたという事だろう。

ただ、psql の \timing ではトータルの実行時間を表示するだけで、何が要因で時間を食っているのかは分からない。PG-Stromは性能改善を目的とするモジュールなので、どの辺を改善したら良いのか探るには先ず、どの辺にボトルネックがあるのかを探る必要がある。

という訳で、PG-StromのGUCパラメータ pg_strom.exec_profile を追加してみた。

これに "on" をセットすると、各々コンポーネントで消費した時間を表示してくれる。

postgres=# SET pg_strom.exec_profile = ON;
SET

（カラム指向 + GPU; １回目）

postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
INFO:  PG-Strom Exec Profile on "t2"
INFO:  Total PG-Strom consumed time: 4367.067 ms
INFO:  Time to JIT Compile GPU code: 1741.505 ms
INFO:  Time to initialize devices:   345.353 ms
INFO:  Time to Load column-stores:   2119.669 ms
INFO:  Time to Scan column-stores:   3.566 ms
INFO:  Time to Fetch virtual tuples: 110.920 ms
INFO:  Time of GPU Synchronization:  31.244 ms
INFO:  Time of Async memcpy:         31.320 ms
INFO:  Time of Async kernel exec:    27.906 ms
INFO:  Num of registers/thread [0]:  25
INFO:  Constant memory usage [0]:    40 byte
INFO:  Max device memory usage[0]:   536 KB
 count
-------
  6718
(1 row)

Time: 4514.738 ms

\timing で計測した応答時間 4514.738ms のうち、PG-Strom モジュール内の処理時間は 4367.067 msで、そのうち、大部分を占めるのが、GPUコードのJITコンパイル（1741.505ms）と、カラムストアからのロード（2119.669ms）になる。これと比べると、GPUでの処理時間・メモリ転送は桁が違う。

（カラム指向 + GPU; ２回目）

postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
INFO:  PG-Strom Exec Profile on "t2"
INFO:  Total PG-Strom consumed time: 183.302 ms
INFO:  Time to JIT Compile GPU code: 0.043 ms
INFO:  Time to initialize devices:   1.134 ms
INFO:  Time to Load column-stores:   54.883 ms
INFO:  Time to Scan column-stores:   3.425 ms
INFO:  Time to Fetch virtual tuples: 96.384 ms
INFO:  Time of GPU Synchronization:  27.462 ms
INFO:  Time of Async memcpy:         30.737 ms
INFO:  Time of Async kernel exec:    27.906 ms
INFO:  Num of registers/thread [0]:  25
INFO:  Constant memory usage [0]:    40 byte
INFO:  Max device memory usage[0]:   536 KB
 count
-------
  6718
(1 row)

Time: 186.867 ms

１回目で時間を食っていた、GPUコードのJITコンパイル処理時間が消え、カラムストアからのロード時間も大幅に減っている。また、地味にデバイスの初期化にも345.353 ms要していたが、これがほぼ無くなっている。

この結果、トータルの処理時間が4514.738 ms⇒186.867msに減少。

カラムストアのロード/スキャンと、タプルをフェッチする処理（これはFDWの仕様なので減らすのが難しい）、それにGPUの処理の同期で合わせて 182.154 ms が消費されている。

1/6(金)の時点から少しアルゴリズムを変更しているが、メモリ使用量はほとんど問題になっていない。

これは、I/O周りで時間がかかっているために、２個、３個とチャンクを非同期に処理しようとしても、次のチャンクを読み込んでGPUに渡す頃には、前のチャンクの処理が既に終わっているからという事だろう。

この辺、もっと足回りの良いマシンなら変わってくるのだろうか。

なお、Time to scan... というのは、条件句を評価した結果に基づいてカラムストアをスキャンする処理で、条件句には使われていないものの、Target-listに含まれるカラムが存在する場合に発生する。今回のクエリは COUNT(*) を返すだけなので、追加のスキャンは発生していない。

おまけ。(カラム指向 + CPU)の実行結果だとこうなる。

postgres=# SELECT COUNT(*) FROM t2 WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 15;
INFO:  PG-Strom Exec Profile on "t2"
INFO:  Total PG-Strom consumed time: 2314.374 ms
INFO:  Time to JIT Compile GPU code: 0.000 ms
INFO:  Time to initialize devices:   0.000 ms
INFO:  Time to Load column-stores:   6.881 ms
INFO:  Time to Scan column-stores:   1435.570 ms
INFO:  Time to Fetch virtual tuples: 871.891 ms
INFO:  Time of GPU Synchronization:  0.000 ms
INFO:  Time of Async memcpy:         0.000 ms
INFO:  Time of Async kernel exec:    0.000 ms
 count
-------
  6718
(1 row)

Time: 8063.461 ms

トータル 8063ms のうち、PS-Strom内の処理は 2314 ms。つまり、必死こいてPG-Stromから本体側にメモリコピーの後、CPUで条件句を処理という流れが見える。PG-Strom内での結果の絞込みができないので、Fetch virtual tuplesの時間が大幅に増加しているのが分かる。

それと、Scan column-store の時間もやや気がかり。足回りとして、この辺は改善の余地があるやも。

James Morris: Save the date: 2012 Linux Security Summit, 30-31 August, San Diego

jamesm — Wed, 18 Jan 2012 00:43:18 +0000

This is a pre-announcement so people can start planning travel for the year.

The Linux Security Summit for 2012 will be held on the 30th and 31st of August in San Diego, CA, USA. It will be co-located with LinuxCon North America, plumbers and the kernel summit.

More details to follow.

James Morris: New git repository for the Linux kernel security subsystem

jamesm — Mon, 16 Jan 2012 05:02:20 +0000

I’ve set up a new git repository for the Linux kernel security subsystem on the new kernel.org server.

The URLs are:

git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
http://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git

Developers should work against the “next” branch.

A web-browsable interface via gitweb may be found at:

http://git.kernel.org/?p=linux/kernel/git/jmorris/linux-security.git;a=summary

The temporary repo on selinuxproject.org will go away soon, so please update your repositories.

KaiGai Kohei: [OSS/Linux]PG-Strom

kaigai — Mon, 09 Jan 2012 20:07:30 +0000

I've checked up an idea whether it is feasible to implement, or not, since I saw a presentation by Tim Child in Ottawa last year.

Is it possible to accelerate sequential-scan of PostgreSQL?

We often see sequential-scan instead of index-scan in case of queries with complex calculation. I thought GPU works fine in these cases.

I tried to implement a module that works as FDW (foreign data wrapper) of PostgreSQL, since I could have a time to develop during Christmas vacation.

The name of module is PG-Strom that is pronounced as shutt-row-me; being pronounced in German style.

Its name originates "Streaming Multiprocessor" that is a unit of process in GPU.

Of course, it assumes existing interface of FDW, so it is unavailable to update, and some more restrictions like sort or aggregate functions. However, it achieves good performance as a prototype.

Note that the following description is based on author's understanding (quite newbie for CUDA), so please point out if something incorrect.

Benchmark

Even though it is an arbitrary testcase, I tries to execute a query that scans a table with 20-million records in my development environment. NVidia's GTS450eco is installed.

-- A regular table
mytest=# SELECT count(*) FROM pgbench_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 29030.738 ms

-- with PG-Strom
mytest=# SELECT count(*) FROM pgstrom_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 2337.475 ms

It is a surprising result. PG-Strom returns the result with 10 times faster!

In addition, we may be able to expect more improvement because GPU is quite cheap one (about 100Euro).

Let's try again. I reduced the number of records (5-million records, with shared_buffer=960MB) to store whole of the table on the buffer; to eliminate affects from disk-I/O.

-- A regular table
mytest=# SELECT count(*) FROM t1
   WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 4106.045 ms

-- with PG-Strom
mytest=# SELECT count(*) FROM t2
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 393.346 ms

Wow!

Idea

PostgreSQL iterates (1) fetch a tuple from storage (or buffer), and (2) evaluation of qualifier of WHERE clause according to contents of the tuple during sequential-scan. Thus, it unavailable to handle (2) during execution of (1), and also unavailable to handle (1) during execution of (2). An idea is CPU multi-threading, however, it is hard to implement because PostgreSQL does not have thread-safe design including memory or I/O management.

PG-Strom entrusts GPU device the (2) portion (evaluation of WHERE clause), and make CPU focus on I/O stuff.

The calculation stuff shall be handled on GPU device side asynchronously, so it shall be finished during CPU handles more I/O stuff.

However, GPU is not a magic bullet for anything.

We need to transfer data to be calculated by GPU into device memory mounted on GPU. It requires to transfer via PCI-E that has narrow bandwidth compared to the one between CPU and Memory. (Max 2.5GB/s in x16 lane)

Thus, amount of data to be copied should be smaller as we can as possible.

In most cases, it is rare case that WHERE clause reference all the columns within the table, because the purpose of query is to fetch a record that satisfies the condition of XXXXX.

PG-Strom handles execution of WHERE clause on GPU device. At that time, all copied to GPU device are contents of referenced columns. I expect 10%-20% of table size needs to be copied to GPU device via PCI-E, because numeric data is smaller than text data.

Data structure and Asynchronous process

The internal data structure of PG-Strom is organized according to the above idea.

For example, when we create a foreign table with four-columns: a, b, c and d, PG-Strom creates tables corresponding to each columns within pg_strom schema. These tables have rowid (int64) to identify a particular row and an array-type to store multiple original data.

Even though it is a column-oriented data structure recently well used, it does not go out of transaction management of PostgreSQL, PG-Strom does not need to touch them.

This type of data structure allows PG-Strom to load data into GPU devices via PCI-E bus effectively.

The contents read from the databases are temporarily stored on fixed-length buffer called "chunk", then it shall be moved to GPU devices and calculated, and the results shall be written back at last. These steps are executed asynchronously, thus, CPU can scan the database concurrently to set up next chunk. This design enables to utilize both of CPU and GPU.

Just-in-time compile and native-code execution

CPU and GPU have its own advantage and disadvantage for each. GPU has much higher computing capability using large number of calculation units in parallel, however, one of its disadvantage is conditional branch.

NVidia's GPU synchronously run 32 of execution units (that is called as SM:Streaming-Multiprocessor) like as a SIMD operations. In the case when device code contains conditional-branch part, a particular thread has 'true' on the condition, and other thread has 'false' on the condition, then, all the threads execute both of true-block and false-block and result of the block to be skipped shall be ignored. Thus, we cannot ignore the cost to execute branch statement within GPU device, especially, if-block is big.

PostgreSQL has internal representation of WHERE clause as tree-structure, and we scan the tree-structure using switch statement on execute them. It shall be worst effectiveness.

Thus, PG-Strom adopts Just-in-time compile to generate native binary code of GPU to avoid execution control on GPU device.

When the supplied query tries to reference a foreign-table managed by PG-Strom, the query planner requires PG-Strom to generate execution plan. At that time, PG-Strom dynamically generate a source code towards GPU device, then kicks nvcc (compiler of NVidia's device) to build a native code of GPU device.

Of course, it shall be cached on shared memory to avoid execute compiler so frequently.

Next, when query-executor calls PG-Strom's executor, as I mentioned above, this native code shall be transferred to the device side with data read from pg_strom schema, and executed asynchronously.

The qualifiers of WHERE clause is already extracted on the planner stage, no need to handle a big switch statement.

We can confirm the automatically generated code of GPU device.

mytest=# EXPLAIN SELECT * FROM pgstrom_accounts
         WHERE (xval - 23.45) * (xval - 23.45) +
               (yval - 54.32) * (yval - 54.32) < 100;
                        QUERY PLAN
--------------------------------------------------------------
 Foreign Scan on pgstrom_accounts  (cost=2.00..0.00 rows=1000 width=368)
    Required Cols : aid, bid, abalance, filler, xval, yval
   Used in clause : xval, yval
      1: typedef unsigned long size_t;
      2: typedef long __clock_t;
      3: typedef __clock_t clock_t;
      4: #include "crt/device_runtime.h"
      5:
      6: typedef char  bool_t;
      7:
      8: __global__ void
      9: pgstrom_qual(unsigned char rowmap[],
     10:              double c5_values[],
     11:              unsigned char c5_nulls[],
     12:              double c6_values[],
     13:              unsigned char c6_nulls[])
     14: {
     15:     int offset_base = blockIdx.x * blockDim.x + threadIdx.x;
     16:     int offset = offset_base * 8;
     17:     unsigned char result = rowmap[offset_base];
     18:     unsigned char errors = 0;
     19:     unsigned char cn5 = c5_nulls[offset_base];
     20:     unsigned char cn6 = c6_nulls[offset_base];
     21:     int bitmask;
     22:
     23:     for (bitmask=1; bitmask < 256; bitmask <<= 1)
     24:     {
     25:         double cv5 = c5_values[offset];
     26:         double cv6 = c6_values[offset];
     27:
     28:         if ((result & bitmask) &&
                    !((((cv5 - 23.45) * (cv5 - 23.45)) +
                       ((cv6 - 54.32) * (cv6 - 54.32))) < 100))
     29:             result &= ~bitmask;
     30:         offset++;
     31:     }
     32:     rowmap[offset_base] = (result & ~errors);
     33: }
(36 rows)

Publication

Right now, it is in public at GitHub. GPLv3 is applied.

https://github.com/kaigai/pg_strom

Even though it is a prototype, thus, its specification depends on my feeling, and we cannot expect documentation for a while, if you'd like to use, please call me (@kkaigai) on twitter.

A short demonstration

This is a short demonstration. The 't1' table is a regular table with 5-million records, and the 't2' table is a foreign table managed by PG-Strom also with 5-million records.

In the case of sequential-scan with complex qualifier, scan on 't2' was finished x10 times faster than the case of 't1'.

KaiGai Kohei: [OSS/Linux] しゅとろ〜む、しゅとろ〜む

kaigai — Fri, 06 Jan 2012 12:15:00 +0000

昨年、オタワでTim Child氏の発表を聞いて以来、実装できないものかと思って暖めていたアイデアがある。GPUの処理能力を使って、PostgreSQLの検索処理を高速化できないか？というものである。

特に複雑な計算を含むクエリの場合、Index-Scanに落ちないで、全件スキャンが走ることが往々にしてあるが、こういったケースで有効に作用するのではなかろうか？という着想である。

クリスマス休暇の間、割とまとまった開発時間を取る事ができたので、PostgreSQLのFDW(Foreign Data Wrapper)として動作するモジュールを作成してみた。

モジュールの名前は PG-Strom で、ドイツ風に『しゅとろ〜む』と発音する。

これは GPU の処理単位である Streaming Multiprocessor に由来する。

もちろん、現状のFDWのI/F前提なので、更新は不可能でソートや集約関数もモジュール側に出せないという諸々制約はあるが、プロトタイプとしてはまずまずの性能である。

※ なお、下記のGPU関連の記述は著者（CUDAプログラミング歴１ヶ月）の理解によるものです。間違っていたらご指摘ください。むしろ教えてくださいｗ

ベンチマーク

かなり恣意的なテストケースではあるが、2,000万件のレコードからなるテーブルを全件スキャンするクエリを手元の環境で実施してみた。なお、搭載しているGPUはNvidia GTX450ecoである。

-- 従来のテーブル
mytest=# SELECT count(*) FROM pgbench_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 29030.738 ms

-- PG-Stromを利用
mytest=# SELECT count(*) FROM pgstrom_accounts
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 629291
(1 row)

Time: 2337.475 ms

驚いた事に、1/10以下の応答時間でクエリを実行してしまったではないか。

しかも利用しているGPUは100Euro程度のショボイものだけに、伸びしろもあるだろう。

もう一回、今度はディスクIOの影響を除くため、テーブル全体がバッファに乗るサイズ（shared_buffer=960MBで、件数を500万件に削減）で試してみた。

-- 従来のテーブル
mytest=# SELECT count(*) FROM t1
   WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 4106.045 ms

mytest=# SELECT count(*) FROM t2
    WHERE (xval - 23.45) * (xval - 23.45) + (yval - 54.32) * (yval - 54.32) < 100;
 count
--------
 157800
(1 row)

Time: 393.346 ms

わお！

アイデア

PostgreSQLの場合、基本的に全件スキャン時の処理は (1) ディスク(or バッファ)からの読み出し (2) タプルの内容に基づいて WHERE 条件句を評価の繰り返しとなる。

そのため、(1)の処理中は(2)を実行できず、(2)の処理中は(1)を実行できない。CPUマルチスレッド化はひとつのアイデアだが、PostgreSQLはメモリ管理やI/O周りを含めて Thread-Safe な構造にはなっていないため、これは非常に難しい。

PG-Stromでは、(2)のWHERE条件句の処理を GPU 側に任せる事で、CPUをI/Oに専念させる。

計算処理はGPU側で非同期に実施してくれるので、CPUから見た場合『ここにあるデータを評価しておいて頂戴』と頼んでおくと、しばらくI/O処理をしている間に計算結果が出来上がっている、という算段である。

ただ、GPUに処理をさせれば万事OKかというと、そうは問屋が卸さない。

GPUで計算させるには、GPU搭載のdevice memoryにデータを転送する必要があるが、これには PCI-Eを通して転送する必要があり、この箇所の帯域はCPU-Memory間に比べて非常に小さいのである。(x16のバスでもMAX片側2.5GB/s)

したがって、GPUデバイスに転送するデータの量はできるだけ少なくした方がよい。

通常、SQLのWHERE条件句がテーブルの全てのカラムを参照するという事は考えにくい。

『○○の条件を満たすレコードを取り出す』というのがクエリの目的だからだ。

PG-StromではWHERE条件句の処理をGPU側で実行するが、その際、GPUデバイス側に転送されるのは計算に必要なカラムだけである。普通は数値データの方が文字列よりも短いため、PCI-Eを介してGPUデバイスに転送の必要があるのは、テーブル全体の10%-20%程度ではなかろうか。

データ構造と非同期処理

PG-Stromの内部データ構造も、上記の方針に従って編成されている。

例えば、a、b、c、dの4つのカラムを持つFOREIGN TABLEを定義したとき、PG-Stromは各々のカラムに対応するテーブルを"pg_strom"スキーマ内に作成する。これらのテーブルは、行を一意に識別する rowid (int64) と、元々のデータを配列化したデータ型を持つ事になる。

最近流行のカラム指向DB的なデータ構造という訳だが、あくまでも PostgreSQL のトランザクション管理の枠内でデータ構造を規定しているので、その辺の厄介な処理は PG-Strom の側では一切ノータッチで済ませている。

この様なデータ構造を持つ事により、PG-StromではPCI-Eを介してGPUデバイスに送り込むデータを高速にDBから読み込めるようになっている。読み込んだデータはチャンクと呼ぶ固定長のバッファに蓄えられ、順次GPUデバイスに送出、GPUでの演算処理を行い、結果の書き戻しが行われる。

実際にはこれらの一連の処理は全て非同期に実施されるため、CPUはその間もDBからデータを読み込み、次のチャンクのセットアップが可能であるため、CPU/GPUを効率的に利用する事ができる。

Just-in-time compile と native code 実行

CPUとGPUにはそれぞれ得意不得意の分野があり、GPUは非常に多くの並列演算ユニットを協調して動作させる事により高い計算能力を発揮するが、不得意な分野もある。その一つが条件分岐である。

NVidiaのGPUでは32個の実行ユニットを含むStreaming Multiprocessorという単位で、SIMDライクな処理が行われる。GPU内の処理が条件分岐を含み、特定のスレッドでは IF 条件が真に、別のスレッドでは偽になるような場合、全てのスレッドがIF文の真ブロック/偽ブロックを処理し、IF条件に合致しないケースを破棄するという処理が行われる。そのため、特にIFブロックのサイズが大きくなるに従って、GPU内で条件句を処理する際のコストが無視できないものとなる。

PostgreSQL内部ではWHERE条件句をツリー状のデータ構造によって保持しているが、ツリーを順にスキャンして『次は '+' 演算子だから…』と switch() 文で分岐させるような処理は、最悪の効率、という事になる。

※ ただ、並列に実行する全てのスレッドでIF条件の評価結果が同じ場合にどうなるか？という点は、調べた限りではよく分からなかった。この場合にペナルティが避けられるのであれば、GPU側でコントロール処理を行うのも一つのアイデア。

そのため、PG-StromではJust-in-time compileの技術を使って動的にネイティブのGPUコードを生成して実行するという方針を採用している。

利用者のクエリがPG-Strom管理下の外部テーブルを参照する場合、Query PlannerはPG-Stromに対してクエリ実行プランを作成するよう要求する。その時、PG-Strom PlannerはWHERE条件句に従って動的にGPUデバイス用のコードを生成し、nvcc（NVidia の GPU向けコンパイラ）を実行してGPU向けのネイティブコードを生成する。もちろん、毎回コンパイラを起動していては時間の無駄なので、生成したバイナリは共有メモリ上にキャッシュされる。

次いで、Query-ExecutorがPG-Strom Executorを呼び出すと、前述の通り、pg_stromスキーマ内から読み出したデータと共に、GPU向けのネイティブコードがデバイス側に送出され、非同期に実行される。

WHERE条件句は既にPlanner段階で展開されているので、改めて巨大な switch 文を処理する必要は…ない。

ちなみに、EXPLAIN文でどのようなGPU向けのコードが生成されているかを見る事ができる。

mytest=# EXPLAIN SELECT * FROM pgstrom_accounts
         WHERE (xval - 23.45) * (xval - 23.45) +
               (yval - 54.32) * (yval - 54.32) < 100;
                        QUERY PLAN
--------------------------------------------------------------
 Foreign Scan on pgstrom_accounts  (cost=2.00..0.00 rows=1000 width=368)
    Required Cols : aid, bid, abalance, filler, xval, yval
   Used in clause : xval, yval
      1: typedef unsigned long size_t;
      2: typedef long __clock_t;
      3: typedef __clock_t clock_t;
      4: #include "crt/device_runtime.h"
      5:
      6: typedef char  bool_t;
      7:
      8: __global__ void
      9: pgstrom_qual(unsigned char rowmap[],
     10:              double c5_values[],
     11:              unsigned char c5_nulls[],
     12:              double c6_values[],
     13:              unsigned char c6_nulls[])
     14: {
     15:     int offset_base = blockIdx.x * blockDim.x + threadIdx.x;
     16:     int offset = offset_base * 8;
     17:     unsigned char result = rowmap[offset_base];
     18:     unsigned char errors = 0;
     19:     unsigned char cn5 = c5_nulls[offset_base];
     20:     unsigned char cn6 = c6_nulls[offset_base];
     21:     int bitmask;
     22:
     23:     for (bitmask=1; bitmask < 256; bitmask <<= 1)
     24:     {
     25:         double cv5 = c5_values[offset];
     26:         double cv6 = c6_values[offset];
     27:
     28:         if ((result & bitmask) &&
                    !((((cv5 - 23.45) * (cv5 - 23.45)) +
                       ((cv6 - 54.32) * (cv6 - 54.32))) < 100))
     29:             result &= ~bitmask;
     30:         offset++;
     31:     }
     32:     rowmap[offset_base] = (result & ~errors);
     33: }
(36 rows)

公開先

今のところGitHUBで公開中。ライセンスはGPLv3です。

https://github.com/kaigai/pg_strom

まだプロトタイプ段階なので、私の気分次第で仕様は変わりますし、当面はドキュメントも期待できません。それでも使ってみようという奇特な方がいらっしゃいましたら、Twitter (@kkaigai) などで呼びかけてもらえれば。

Russell Coker (security): My Blog Server was Cracked

etbe — Sat, 31 Dec 2011 00:01:06 +0000

On the 1st of August I noticed that the server which runs my blog among other things was having an occasional SEGV from a sshd process. Unfortunately I was busy and didn’t pay much attention to this, which turned out to be a big mistake.

On the 12th of September I started investigating this properly and noticed that when someone tried to connect to ssh with password authentication sshd would SEGV after it was denied access to a shared memory region or a semaphore which had a SE Linux type of unconfined_t. I added some SE Linux auditallow rules and discovered that the memory region in question was created by the ssh client. Shortly after that I came to the conclusion that this wasn’t some strange feature of ssh (or one of the many shared objects it uses) but hostile activity. The ssh client appeared to be storing passwords that it used in a shared memory region and sshd was also collecting passwords in the same region and presumably offering them to a ssh client which uses some extension to the ssh protocol.

The sshd process was crashing because it couldn’t handle EPERM on access to shared memory or semaphores. Presumably if the system in question wasn’t running SE Linux then the exploit would have remained undetected for a lot longer.

At this stage we don’t know how the attacker got in. Presumably one of the people with root access ran a ssh client on a compromised system and had their password sniffed. One such client system was mysteriously reinstalled at about that time, the sysadmin of the system in question claimed to have no backups which made it impossible to determine if that system had been compromised. I believe that the sysadmin of the client system knew that their system was compromised, kept that information secret, and allowed other systems to become and remain compromised.

The attacker made no good effort to conceal their presence, they replaced ssh, sshd, and ssh-add and didn’t bother changing the Debian checksums so the debsums program flagged the files as modified. Note that I have kept copies of the files in question and am willing to share them with anyone who wants to analyse them.

Steinar H. Gunderson has named this trojan Ebury [1].

Recovery

By the evening of the 13th of September I had the system mostly working again. Jabber still isn’t working because ejabberd is difficult to get working at the best of times, I am now investigating whether there is a better Jabber server to use, but as I don’t use Jabber often this hasn’t been a priority for me.

Some of the WordPress plugins I use and all of the WordPress themes that are installed were outside the Debian packaging system, as I couldn’t be sure that they hadn’t been altered (because the people who wrote WordPress plugins don’t keep old versions online) I had to upgrade to the newer versions. Of course the newer versions weren’t entirely compatible so I had to use a different theme and I couldn’t get all plugins working. Link Within no longer works, not that it ever worked properly [2], I wanted to try Outbrain again but their web site won’t let me login (and they haven’t responded to my support request). Does anyone know of a good WordPress plugin to provide links to related content? Either related content on my blog or on the Internet in general will be OK.

Some people have asked me about the change in appearance of my blog. It was simply impossible (for someone with my PHP skills) to get my blog looking the same way as it did before the server was cracked. I think that the new look is OK and don’t mind if people think it looks likw a VW advert – VW make great cars, I was very satisfied with the VW Passat I used to drive.

Future Plans

I had bought some Yubikeys (USB devices that generate one-time passwords) [3] to control access to that server, if I had configured the software to use them then this might not have happened. The use of one-time password devices can prevent passive password-sniffing attacks. It would still allow active attacks (such as using ControlPath/ControlMaster options on the ssh client to allow a hostile party to connect later (EG the -M, -S, and “-o ControlPersist” options for the ssh client). It’s a pity that there doesn’t seem to be a way to configure the ssh server to disable ControlMaster.

Conclusion

It would be good to have some changes to sshd to allow more restrictions on what a client can request, as ControlMaster functionality isn’t needed by most users it should be possible to disable it.

SE Linux doesn’t protect against a compromised client system or any other way of stealing passwords. It did do a good job of stopping Ebury from doing all the things it wanted to do and thus making me aware of the problem. So I count this as a win for SE Linux.

Yubikeys are the cheapest and easiest way of managine one-time passwords. I had already bought some for use on the system in question but hadn’t got around to configuring them. I have to make that a priority.

Email Passwords I was doing some routine sysadmin work for a client...
Case Sensitivity and Published Passwords When I first started running a SE Linux Play Machine...
what’s a good blog server for serious blogging? I’m getting sick of blogger. The main thing is that...

Russell Coker (security): Secure Boot and Protecting Against Root

etbe — Wed, 28 Dec 2011 04:16:22 +0000

There has been a lot of discussion recently about the recent Microsoft ideas regarding secure boot, in case you have missed it Michael Casadevall has written a good summary of the issue [1].

Recently I’ve seen a couple of people advocate the concept of secure boot with the stated idea that “root” should be unable to damage the system, as Microsoft Software is something that doesn’t matter to me I’ll restrict my comments to how this might work on Linux.

Restricting the “root” account is something that is technically possible, for much of the past 9 years I have been running SE Linux “Play Machines” which have UID 0 (root) restricted by SE Linux such that they can’t damage the system [2] – there are other ways of achieving similar goals. But having an account with UID 0 that can’t change anything on the system doesn’t really match what most people think of as “root”, I just do it as a way of demonstrating that SE Linux controls all access such that cracking a daemon which runs as root won’t result in immediately controlling the entire system.

As an aside my Play Machine is not online at the moment, I hope to have it running again soon.

Root Can’t Damage the System

One specific claim was that “root” should be unable to damage the system. While a secure boot system can theoretically result in a boot to single user mode without any compromise that doesn’t apply to fully operational systems. For a file owned by root to be replaced the system security has to be compromised in some way. The same compromise will usually work every time until the bug is fixed and the software is upgraded. So the process of cracking root that might be used to install hostile files can also be used at runtime to exploit running processes via ptrace and do other bad stuff.

Even if the attacker is forced to compromise the system at every boot this isn’t a great win for the case of servers with months of uptime or for the case of workstations that have confidential data that can be rapidly copied over the Internet. There are also many workstations that are live on the Internet for months nowadays.

Also the general claim doesn’t really make sense on it’s own. “root” usually means the account that is used for configuring the system. If a system can be configured then the account which is used to configure it will be able to do unwanted things. It is theoretically possible to run workstations without external root access (EG have them automatically update to the latest security fixes). Such a workstation configuration MIGHT be able to survive a compromise by having a reboot trigger an automatic update. But a workstation that is used in such a manner could be just re-imaged as it would probably be used in an environment where data-less operation makes sense.

An Android phone could be considered as an example of a Linux system for which the “root” user can’t damage the system if you consider “root” to mean “person accessing the GUI configuration system”. But then it wouldn’t be difficult to create a configuration program for a regular Linux system that allows the user to change some parts of the system configuration while making others unavailable. Besides there are many ways in which the Android configuration GUI permits the user to make the system mostly unusable (EG by disabling data access) or extremely expensive to operate (EG by forcing data roaming). So I don’t think that Android is a good example of “root” being prevented from doing damage.

Signing All Files

Another idea that I saw advocated was to have the “secure boot” concept extended to all files. So you have a boot loader that loads a signed kernel which then loads only signed executables and then every interpreter (Perl, Python, etc) will also check for signatures on files that they run. This would be tricky with interpreters that are designed to run from standard input (most notably /bin/sh but also many other interpreters).

Doing this would require changing many programs, I guess you would even have to change mount to check the signature on /etc/fstab etc. This would be an unreasonably large amount of work.

Another possibility would be to change the kernel such that it checks file signatures and has restrictions on system calls such as open() and the exec() family of calls. In concept it would be possible to extend SE Linux or any other access control system to include access checks on which files need to be signed (some types such as etc_t and bin_t would need to be signed but others such as var_t wouldn’t).

Of course this would mean that no sysadmin work could be performed locally as all file changes would have to come from the signing system. I can imagine all sorts of theoretically interesting but practically useless ways of implementing this such as having the signing system disconnected from the Internet with USB flash devices used for one-way file transfer – because you can’t have the signing system available to the same attacks as the host system.

The requirement to sign all files would reduce the use of such a system to a tiny fraction of the user-base. Which would then raise the question of why anyone would spend the effort on that task when there are so many other ways of improving security that involve less work and can be used by more people.

Encrypted Root Filesystem

One real benefit of a secure boot system is for systems using encrypted filesystems. It would be good to know that a hostile party hasn’t replaced the kernel and initrd when you are asked for the password to unlock the root filesystem. This would be good for the case where a laptop is left in a hotel room or other place where a hostile party could access it.

Another way of addressing the same problem is to boot from a USB device so that you can keep a small USB boot device with you when it’s inconvenient to carry a large laptop (which works for me). Of course it’s theoretically possible for the system BIOS to be replaced with something that trojans the boot process (EG runs the kernel in a virtual machine). But I expect that if someone who is capable of doing that gets access to my laptop then I’m going to lose anyway.

Conclusion

The secure boot concept does seem to have some useful potential when the aim is to reboot the system and have it automatically apply security fixes in the early stages of the boot process. This could be used for Netbooks and phones. Of course such a process would have to reset some configuration settings to safe defaults, this means replacing files in /etc and some configuration files in the user’s home directory. So such a reboot and upgrade procedure would either leave the possibility that files in /etc were still compromised or it would remove some configuration work and thus give the user an incentive to avoid applying the patch.

Any system that tries to extend signature checks all the way would either be vulnerable to valid but hostile changes to system configuration (such as authenticating to a server run by a hostile party) or have extreme ease of use issues due to signing everything.

Also a secure boot will only protect a vulnerable system between the time it is rebooted and the time it returns to full operation after the reboot. If the security flaw hasn’t been fixed (which could be due to a 0-day exploit or an exploit for which the patch hasn’t been applied) then the system could be cracked again.

I don’t think that a secure boot process offers real benefits to many users.

Question about a “Secure Filesystem” I have just been asked for advice about “secure filesystem”...
How SE Linux Prevents Local Root Exploits In a comment on my previous post about SE Linux...
Logging in as Root Martin Meredith wrote a blog post about logging in as...

Dan Walsh: 10 things you probably did not know about SELinux #9 Backing up and Restoring Labels.

dwalsh@redhat.com — Mon, 12 Dec 2011 19:38:21 +0000

It has been a few years since I discusses backing up and restoring labels with SELinux.

I was asked at the Lisa 11 conference by a backup utility developer, "How should he save and restore SELinux security contexts?" He also asked whether or not his tool should always maintain these context? Finally how should the tool react if the system would not allow the context to be restored?

Interesting topic. Lets first take a look at a few tools for backing up content with SELinux labels.

SELinux stores SELinux security labels (contexts) as extended attributes with the inode on the file system. If an administrate wants to backup/restore files with the SELinux labels, you need to use a utility that supports this.

When SELinux first shipped the only utility to do this was star (RHEL4) , GNU tar at that time did not support extended attributes. Later extended attribute support was added to GNU tar. ( tar --selinux -cvf /tmp/etc.tgz /etc ) Rsync also has support for maintaining extended attributes. Even Dump/Restore can now support maintaining the extended attributes.

I often question is whether this is a good idea to maintain the labels. In some cases your security goals require it. For example backing up sensitivity labelled data (MLS) requires this. If you have a file labelled TopSecret, you would definitely want to maintain this within the archive.

But most of us do not deal with sensitivity labelled data, and we would want to make sure the data on our system is labelled correctly based on the current security definition on our system. Trying to maintain the SELinux labels and restore them can be a mistake in several cases.

For example:

Target file system does not support extended attributes.

If you attempted to restore files to a file system that does not support extended attributes. Does the administrator have a way to allow this?

Updating a machine for one version of the OS to another.

If you backed up your /home directory before updating from Fedora 15 to Fedora 16 and then restored the content of the archive, certain directories in you home directory will be mislabeled and potentially tools like googlechrome or colord will fail. You would have been better off having the content restored the archive and then running restorecon -R - v /home.

Copying an archive from one machine to another machine with an older OS.

Attempting to maintain the labels would be wrong if you created an archive on a RHEL6 box and then attempting to restore the archive on a RHEL5 box. If the RHEL5 kernel does not understand a label from a RHEL6 box, then the label will not be allowed to be placed on the disk. In this case, again you would want to put the files down and then restore the labels.

In this case it would be nice if the tools used to restore the content had the ability to label the content "correctly" based on the file_contexts definitions on the target system. That way we would not have a race condition where the labels on the files are incorrect for a period of time.

In conclusion the backup/restore utility should:

allow the administrator to decide whether or not to save the SELinux labels and restore them.
Allow the administrator to specify the tool to restore the files using the default labels as specified on the target system (matchpathcon/setfscreatecon)
If the utility does not allow have the second option, in most cases the administrator should run restorecon on the restored files.

Dan Walsh: Why isn't setroubleshoot working in Fedora 16?

dwalsh@redhat.com — Thu, 08 Dec 2011 18:13:21 +0000

Well if you did a fresh install it does work. But if you did an upgrade install from an older Fedora you have a problem.

setroubleshootd is a dbus service launched by the audit daemon. In Fedora 16 all daemons that were running under as System V init scripts and were converted to systemd, no longer are started by default. Meaning the auditd daemon is probably no longer running on your machines. You might notice AVC messages showing up in /var/log/messages, rather then /var/log/audit/audit.log.

It is simple to fix this problem by executing

# systemctl enable auditd.service
# systemctl start auditd.service

This will re-enable the auditd daemon and your setroubleshoot daemon should start working again. If you get any AVC messages, they will start showing up in the /var/log/audit/audit.log.

KaiGai Kohei: [OSS/Linux]Leaky Views と Security Barrier : PostgreSQL Advent Calendar #4

kaigai — Sat, 03 Dec 2011 15:37:23 +0000

このエントリはPostgreSQL Advent Calendarに参加しています。12/4(日)担当也。ヨーロッパ中部時間ではまだ12/3(土)ですが。

RDBMSで行レベルのアクセス制御を実現する方法として、利用者に対して直接のアクセス権を付与せずに、特定のビューを通してだけアクセスを許可するのはしばしば使われるテクニックです。

ですが、場合によっては不可視な行の中身を参照できてしまうというのは、あまり広く認知されている訳ではないようです。

ので、問題のポイントと、現在開発中の PostgreSQL v9.2 に提案しているアイデアをご紹介します。

ユーザ定義関数のCOST値による問題

ここでは、以下の表を例に考えてみます。

customerテーブル

列名	型	制約
cid	int	primary key
cname	text	not null
cmail	text
cpasswd	text

customerテーブルには全顧客の情報が格納されているため、利用者は自分自身の情報しか見る事ができないよう設定しましょう。

（便宜上 PostgreSQL ユーザ名が cname に対応するものとします）

postgres=# CREATE VIEW my_account AS SELECT * FROM customer
                  WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_account TO public;
GRANT

本来、このテーブルには 3ユーザ分の情報が格納されているのですが、

postgres=# SELECT * FROM customer;
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+----------
 101 | alice | alice@example.com | abcdef
 102 | bob   | bob@example.com   | xyz123
 103 | eve   | eve@example.com   | deadbeaf
(3 rows)

確かに、自分自身の情報しか参照できないように見えます。

postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> SELECT * FROM customer;
ERROR:  permission denied for relation customer
postgres=> SELECT * FROM my_account;
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+---------
 101 | alice | alice@example.com | abcdef
(1 row)

しかし、利用者がSQL関数を定義できる場合、面白い事が起こります。

（publicスキーマはデフォルトでCREATE権限を全体に与えている事に注意！）

postgres=> CREATE FUNCTION f_leak(text) RETURNS bool LANGUAGE plpgsql
           COST 0.00000001
           AS 'BEGIN RAISE NOTICE ''f_leak => %'', $1; RETURN true; END';
CREATE FUNCTION

postgres=> SELECT * FROM my_account WHERE f_leak(cmail);
NOTICE:  f_leak => alice@example.com
NOTICE:  f_leak => bob@example.com
NOTICE:  f_leak => eve@example.com
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+---------
 101 | alice | alice@example.com | abcdef
(1 row)

おっと、何か見えてはならないモノが見えたようです。

どういう事なのでしょうか、ちょっと EXPLAIN で調べてみましょう。

postgres=> EXPLAIN SELECT * FROM my_account WHERE f_leak(cmail);
                           QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on customer  (cost=0.00..20.85 rows=1 width=100)
   Filter: (f_leak(cmail) AND (cname = (getpgusername())::text))
(2 rows)

この実行計画はVIEWの本体である customer テーブルをスキャンしていますが、利用者が付与した f_leak() とVIEWの条件を順にチェックしています。

問題は、副作用を持つ f_leak() の実行コストが非常に小さな値に設定されているため、オプティマイザは cname = getpgusername() より先にf_leak()を実行して不必要な条件の判断を省略した方が得策であると判断して、関数の実行順序を並べ替えている事です。その結果、不可視であるべき行の内容が引数としてf_leak()に渡され、それが利用者に漏えいしている訳です。

JOINと条件句の分配に伴う問題

同様に、VIEWによる行レベルアクセス制御を破るシナリオはもう一つ知られています。

先ほどの customer テーブルに加えて、もう一つテーブルを追加して考察を進めてみましょう。

creditテーブル

列名	型	制約
cid	int	references customer(cid)
number	text
expired	date

この credit テーブルは顧客のクレジットカード番号を保持しています。先ほどの my_account ビューと同様に、自分自身のレコードだけを参照できるようなVIEWを定義してみましょう。

postgres=# SELECT * FROM customer;
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+----------
 101 | alice | alice@example.com | abcdef
 102 | bob   | bob@example.com   | xyz123
 103 | eve   | eve@example.com   | deadbeaf
(3 rows)

postgres=# SELECT * FROM credit;
 cid |       number        |  expired
-----+---------------------+------------
 101 | 1111-2222-3333-4444 | 2014-02-28
 102 | 5555-6666-7777-8888 | 2013-10-30
 102 | 1234-5678-1234-5678 | 2015-06-30
 103 | 0987-6543-2109-8765 | 2014-08-31
(4 rows)

postgres=# CREATE VIEW my_credit AS SELECT cname, cmail, credit.*
           FROM customer NATURAL JOIN credit WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_credit TO public;
GRANT

おや、やっぱり何かおかしいようです。

postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> SELECT * FROM my_credit;
 cname |       cmail       | cid |       number        |  expired
-------+-------------------+-----+---------------------+------------
 alice | alice@example.com | 101 | 1111-2222-3333-4444 | 2014-02-28
(1 row)

postgres=> SELECT * FROM my_credit WHERE f_leak(number);
NOTICE:  f_leak => 1111-2222-3333-4444
NOTICE:  f_leak => 5555-6666-7777-8888
NOTICE:  f_leak => 1234-5678-1234-5678
NOTICE:  f_leak => 0987-6543-2109-8765
 cname |       cmail       | cid |       number        |  expired
-------+-------------------+-----+---------------------+------------
 alice | alice@example.com | 101 | 1111-2222-3333-4444 | 2014-02-28
(1 row)

もう一度 EXPLAIN で実行計画を眺めてみましょう。

postgres=> EXPLAIN SELECT * FROM my_credit WHERE f_leak(number);
                              QUERY PLAN
----------------------------------------------------------------------
 Hash Join  (cost=20.89..43.96 rows=2 width=104)
   Hash Cond: (credit.cid = customer.cid)
   ->  Seq Scan on credit  (cost=0.00..21.60 rows=387 width=40)
         Filter: f_leak(number)
   ->  Hash  (cost=20.85..20.85 rows=3 width=68)
         ->  Seq Scan on customer  (cost=0.00..20.85 rows=3 width=68)
               Filter: (cname = (getpgusername())::text)
(7 rows)

困ったことに、『creditテーブルをf_leak()条件でスキャンした結果』と『customerテーブルをcname = getpgusername()条件でスキャンした結果』がJOINされています。

オプティマイザはJOINすべき行を最小化するよう条件句を分配するのですが、f_leak()関数は credit テーブルの number 列のみ、cname = getpgusername() 条件は customer テーブルの cname 列のみに依存しています。そのため、JOINの完了を待つ事なく個々のテーブルをスキャンする時点で条件句を実行した方が、JOINすべき行数を減らす事ができます。

その結果、副作用を持つf_leak()がcreditテーブルのスキャン計画に push-down され、最初の例と同様に、不可視であるべき行の内容がf_leak()に渡され、それが利用者に漏えいしてしまっています。

この２つの問題は共に、オプティマイザがVIEWの境界を越えて関数の実行順序を入れ替えている事が原因です。これは性能観点からは優れた実装ですが、セキュリティを目的としたVIEW定義という観点では問題です。

一方で、VIEW内部で使われている関数を全て評価してから、その外部から与えられた関数を評価するという実装は、安全ですが、性能上無視できない性能劣化をもたらします。例えば、1万行 x 1万行のテーブルをJOINする場合、外部から与えられた関数をテーブルスキャンの時点で評価する事で片方の行数を1万行から100行に絞り込めるとしたら、9900万行分のJOIN処理を省略する事ができます。

次に、PostgreSQL v9.2に向けて提案されている Leaky View 問題への対策を紹介しましょう。

VIEW の security_barrier 属性と最適化の抑制

ここからは、私の提案している「Fix Leaky View Problemパッチ」の解説です。

前節で考察したように、VIEWを行レベルアクセス制御の目的で利用する場合には、パフォーマンスとセキュリティのトレードオフが存在します。安全側に倒せば許容できない程の性能劣化を招く可能性があり、一方、性能最適であれば情報漏えいの危険があります。

Fix Leaky Views Problem パッチは、CREATE VIEW構文でWITH(...)句を用いてオプション値を指定することを許容します。構文は以下の通りです。

CREATE VIEW view_name [WITH (options[,...])] AS select_statement;
options:
  security_barrier[= true|false]

security_barrier オプションは、VIEWが行レベルアクセス制御を目的として定義されていることを示す属性です。これを指定することで、一部のクエリ最適化を抑制する事が可能になります。

この設計に至るまでには長い議論があったのですが、結局、パフォーマンスとセキュリティのどちらが重要であるのかを判断できるのはVIEWを定義する人のみである、というシンプルな結論にたどり着いたのでした。

VIEWにsecurity_barrier属性が付与されている時、VIEWの内側で使用されている全ての関数・条件句は、VIEWの外側から与えられた関数・条件句よりも先に実行される事が保証されます。

では、実際に試してみましょう。以下で定義する my_account_secure と my_credit_secure は、先ほどの2つの例で使用したVIEWにsecurity_barrier属性を付加したものです。

postgres=# CREATE VIEW my_credit_secure WITH (security_barrier) AS
           SELECT cname, cmail, credit.* FROM customer NATURAL JOIN credit
           WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_account_secure TO public;
GRANT
postgres=# CREATE VIEW my_account_secure WITH (security_barrier) AS
           SELECT * FROM customer WHERE cname = getpgusername();
CREATE VIEW
postgres=# GRANT SELECT ON my_credit_secure TO public;
GRANT

動作結果は以下のようになりました。"f_leak => ..." と表示されている内容は、クエリによって本来参照可能なデータの範囲内に収まっている事が分かります。

postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> SELECT * FROM my_account_secure WHERE f_leak(cmail);
NOTICE:  f_leak => alice@example.com
 cid | cname |       cmail       | cpasswd
-----+-------+-------------------+---------
 101 | alice | alice@example.com | abcdef
(1 row)

postgres=> SELECT * FROM my_credit_secure WHERE f_leak(number);
NOTICE:  f_leak => 1111-2222-3333-4444
 cname |       cmail       | cid |       number        |  expired
-------+-------------------+-----+---------------------+------------
 alice | alice@example.com | 101 | 1111-2222-3333-4444 | 2014-02-28
(1 row)

では、VIEWにsecurity_barrier属性を付加することで、クエリ実行計画にどのように変化しているのでしょうか？先ほどと同じように、EXPLAIN構文で調べてみましょう。

postgres=> EXPLAIN SELECT * FROM my_account_secure WHERE f_leak(cmail);
                               QUERY PLAN
-------------------------------------------------------------------------
 Subquery Scan on my_account_secure  (cost=0.00..20.88 rows=1 width=100)
   Filter: f_leak(my_account_secure.cmail)
   ->  Seq Scan on customer  (cost=0.00..20.85 rows=3 width=100)
         Filter: (cname = (getpgusername())::text)
(4 rows)

f_leak()関数の評価は cname = getpgusername() 条件で customer テーブルをスキャンした後に行われる事が分かります。オプティマイザは security_viwe 属性を持ったVIEWの内側に条件句を push-down しなくなりました。

もう一つの例も同様です。

postgres=> EXPLAIN SELECT * FROM my_credit_secure WHERE f_leak(cmail);
                                 QUERY PLAN
----------------------------------------------------------------------------
 Subquery Scan on my_credit_secure  (cost=20.89..46.96 rows=2 width=104)
   Filter: f_leak(my_credit_secure.cmail)
   ->  Hash Join  (cost=20.89..46.90 rows=6 width=104)
         Hash Cond: (credit.cid = customer.cid)
         ->  Seq Scan on credit  (cost=0.00..21.60 rows=1160 width=40)
         ->  Hash  (cost=20.85..20.85 rows=3 width=68)
               ->  Seq Scan on customer  (cost=0.00..20.85 rows=3 width=68)
                     Filter: (cname = (getpgusername())::text)
(8 rows)

パッチ自体の動作原理は極めて単純です。

PostgreSQLは、一旦、VIEWに対するクエリを内部的にサブクエリに書き換えます。その後、オプティマイザがクエリ実行計画を作成する際に、"シンプル"なサブクエリ（OFFSET/LIMIT句を含まない…など）であれば、性能最適の観点からサブクエリをJOINを用いてフラット化(Pull-Up)します。

その後で、条件句はオプティマイザによって性能上最適な位置に振り分けられるため、VIEWの内側/外側といった区別はもはや意味を持たなくなります。

VIEWのsecurity_barrier属性は、この際の条件に作用します。RangeTblEntry構造体のsecurity_barrierは、関連するサブクエリがVIEWに由来し、かつ、VIEWのsecurity_barrier属性がtrueである場合にセットされます。

以下の処理では、security_barrier属性が false だとpull_up_simple_subquery()は呼ばれないため、サブクエリのフラット化は抑制されます。

--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -543,6 +543,7 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode,
         */
        if (rte->rtekind == RTE_SUBQUERY &&
            is_simple_subquery(rte->subquery) &&
+           !rte->security_barrier &&
            (containing_appendrel == NULL ||
             is_safe_append_member(rte->subquery)))
            return pull_up_simple_subquery(root, jtnode, rte,

さらにもう一ヶ所。条件句に与える引数が特定のサブクエリにだけ依存している場合、オプティマイザはこの条件句の実行をサブクエリ処理の中に移動(Push-Down)しようとしますが、同様にサブクエリが security_view 属性つきのVIEWに由来する時は、これをスキップします。

@@ -763,6 +769,7 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
      Node       *clause = (Node *) rinfo->clause;

      if (!rinfo->pseudoconstant &&
+         !rte->security_barrier &&
          qual_is_pushdown_safe(subquery, rti, clause, differentTypes))
      {
          /* Push it down */

この２ヶ所の処理を追加することによって、これまで見たような、VIEWを行レベルアクセス制御の目的に使用する場合の問題を回避する事ができます。

FUNCTION の leakproof 属性

Leaky View問題はVIEWのsecurity_barrier属性によって解決する事ができるのですが、これは一部のクエリ最適化を無効化するために、場合によっては、そのためのコストが看過できないほど大きい事もあります。

例えば、アプリケーションの設計上、以下のようなVIEWを定義し、VIEWの外側から条件句（主キーによる絞込みなど）を与えて使いたいというケースを考えてみましょう。

CREATE VIEW valid_credit WITH (security_barrier) AS
    SELECT * FROM credit WHERE card_is_valid(number, expired);

SELECT * FROM valid_credit WHERE cid = <customer-id>;

この場合、card_is_valid関数と、VIEWの外部から与えた cid = <customer-id> を用いて credit テーブルをスキャンした結果が利用者には返されます。ですが、VIEWにはsecurity_barrier属性が設定されているため、常にcard_is_valid関数が先に実行されます。

この制限は cid 列にインデックスが設定されていても同様です。したがってインデックス・スキャンが選択されるべき状況でも全件スキャンが選択されてしまいます。ああ困った、困った。

Fix Leaky View ProblemパッチはPart-1とPart-2から構成されており、Part-1は前述の security_barrier 属性の実装を、Part-2ではその例外を設定する機能を実装しています。

Part-2によって、先ほどのオプティマイザへの変更は一部修正されます。

--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -769,7 +769,8 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
        Node       *clause = (Node *) rinfo->clause;

        if (!rinfo->pseudoconstant &&
-           !rte->security_barrier &&
+           (!rte->security_barrier ||
+            !contain_leakable_functions(clause)) &&
            qual_is_pushdown_safe(subquery, rti, clause, differentTypes))
        {
            /* Push it down */

サブクエリがsecurity_barrier属性付きのVIEWに由来するとき、このif文は条件句のPush-Downを抑止しますが、Part-2パッチは条件句(clause)が leakable-functions （つまり情報を漏えいする可能性のある関数）を含んでいなければ、サブクエリへの条件句のPush-Downを許可するように修正します。

では、関数が情報を漏えいする可能性の有無をどのように設定するか。

それには、CREATE FUNCTION構文に新たに追加されるLEAKPROOF属性を使用します。

例えば、以下のように使用します。LEAKPROOFを指定することで、この関数に情報漏えいの恐れがないという事を明示的に指定できますが、これは同時に、潜在的に不可視の行の内容を参照することを可能にするため、関数のLEAKPROOF属性をセットするには特権ユーザの権限が必要です。

（SE-PostgreSQLでも db_procedure:{install}権限をチェックする予定です）

CREATE FUNCTION is_positive(int) RETURNS bool LANGUAGE plpgsql
    LEAKPROOF
    AS 'BEGIN RETURN $1 > 0; END';

一部のビルトイン関数の中でも、明らかに情報漏えいのリスクがない関数については、デフォルトでLEAKPROOF属性がセットされています。

（全部で2400個程あるため、網羅的なチェックはこれからですが…。）

例えば、32bit Integer同士の大小比較を行う int4gt 関数は、以下のように実装されています。

Datum
int4gt(PG_FUNCTION_ARGS)
{
    int32       arg1 = PG_GETARG_INT32(0);
    int32       arg2 = PG_GETARG_INT32(1);

    PG_RETURN_BOOL(arg1 > arg2);
}

この実装に情報漏えいの危険はありませんので、DB初期化時にLEAKPROOF属性はセットされています。

その他にも、現在のパッチでは各種ビルトインタイプの等価・大小比較演算子の実装として利用されている関数にLEAKPROOF属性がついています。実際に試してみましょう。

postgres=# SET SESSION AUTHORIZATION bob;
SET
postgres=> SELECT * FROM my_credit;
 cname |      cmail      | cid |       number        |  expired
-------+-----------------+-----+---------------------+------------
 bob   | bob@example.com | 102 | 5555-6666-7777-8888 | 2013-10-30
 bob   | bob@example.com | 102 | 1234-5678-1234-5678 | 2015-06-30
(2 rows)

ユーザ bob は2枚のクレジットカードを持っています。リッチメンですね。

では、２つの条件句を付加してみます。一つは先ほどのf_leak()関数、もう一つは expired < '2014-01-01' という Date 型の大小比較演算です。

postgres=> SELECT * FROM my_credit_secure WHERE f_leak(number) AND expired < '2014-01-01';
NOTICE:  f_leak => 5555-6666-7777-8888
 cname |      cmail      | cid |       number        |  expired
-------+-----------------+-----+---------------------+------------
 bob   | bob@example.com | 102 | 5555-6666-7777-8888 | 2013-10-30
(1 row)

NOTICEメッセージが一行だけ表示されているという事は、大小比較演算はf_leak()関数よりも先に実行されたようです。EXPLAINで実行計画を見てみましょう。

postgres=> EXPLAIN SELECT * FROM my_credit_secure WHERE f_leak(number) AND expired < '2014-01-01';
                                QUERY PLAN
---------------------------------------------------------------------------
 Subquery Scan on my_credit_secure  (cost=1.06..27.06 rows=1 width=104)
   Filter: f_leak(my_credit_secure.number)
   ->  Hash Join  (cost=1.06..27.04 rows=2 width=104)
         Hash Cond: (credit.cid = customer.cid)
         ->  Seq Scan on credit  (cost=0.00..24.50 rows=387 width=40)
               Filter: (expired < '2014-01-01'::date)
         ->  Hash  (cost=1.05..1.05 rows=1 width=68)
               ->  Seq Scan on customer  (cost=0.00..1.05 rows=1 width=68)
                     Filter: (cname = (getpgusername())::text)
(9 rows)

見ての通り、expired < '2014-01-01' 条件句が credit テーブルのスキャンに結びついているのと比較して、f_leak()関数はmy_credit_secureビューの内側にPush-Downされていません。これが LEAKPROOF 属性の有無による違いです。もし credit テーブルにインデックスが設定されていれば、Push-Downされた条件句により、全件スキャンの代わりにインデックス・スキャンが選択されるかもしれません。

まとめ

確かこの問題は、かれこれ2年以上議論を続けてきた息の長い問題です。

2009年9月4日のセキュアOS塾『SE-PostgreSQL vs Oracle Label Security』の資料の中で言及があります。（p.34）

http://sepgsql.googlecode.com/files/090904-jsosjk04-sepgsql-vs-ols.pdf

開発コミュニティとしての方向性は、概ね上で紹介した形で収束しつつありますが、まだ v9.2 の新機能として紹介できるかどうか、は分からない状況です。が、SE-PostgreSQLの行レベルアクセス制御機能を実現するためにもマージしておきたい機能ですので、なんとかcommitできるよう頑張りたいところです。

最後に『じゃあ、既存のシステムではどうやって対策したら良いのよ？』という質問に対して一つTIPSを紹介しておきたいと思います。

Q. PostgreSQL v9.1以前のバージョンでLeaky View問題を防ぐにはどうしたらよいか？

A. クエリに OFFSET 0 を付ける

オプティマイザがサブクエリをフラット化、または、条件句をPush-Downする時、サブクエリにOFFSET/LIMIT句が含まれている場合はそれを断念する、という事を思い出してください。

OFFSET 0は結果セットの先頭から値を読むという意味ですので、本来は何の意味もありません。ですが、ここまで説明した条件句の実行順序に起因する問題を防ぐには簡便な方法です。

ただし、関数のLEAKPROOF属性に相当する機能はありませんので、その点でトレードオフは必要になります。

PostgreSQL Advent Calendar向けに記事を書くにあたり、MySQL、MS SQL Server、Oracle Databaseなど他のRDBMSの挙動はどうなっているのか調べたかったのですが、時間がありませんでした。特に Oracle は勝手にWHERE句に条件をくっつけるVirtual Private Databaseという機能を持っていますので気になります。

これらは、追って調査したいと思います。きっと。いつの日か。アディオス、アミーゴ。

さて、翌 12/5(月) は笠原さんです。よろしく〜

Dan Walsh: SELinux versus pam_securid.so

dwalsh@redhat.com — Fri, 02 Dec 2011 12:55:03 +0000

Seems to be my month for fighting pam modules from third parties.   I have heard that RSA corporation is recommending SELinux be turned off to run their products. I just love it when a supposed security company recommends that customers turn on a key security component of the Operating System. Now did RSA ever contact me to work through the problems,? No.

Come on RSA you can do better then this.

I am trying to avoid underhanded security comment about using SELinux to protect key assets of the company...

I worked with Joe Lucchesi, to get this pam module to work with SELinux. Joe was having problems with sshd working with the pam module. He was getting execstack errors. Turns out the pam_securid.so file was shipped with the execstack flag turned on. Execstack is a dangerous protection to allow a domain, since it turns off protection against buffer overflow attacks. Most app never need this access.

Executing

execstack -c /lib64/security/pam_securid.so

Cleared the flag. And allowed sshd to get past this AVC. Whatever is causing this flag to be set, the build procedure or installation needs to be fixed.

The next problems we hit was pam_securid seems to be running netstat under the covers. I recall we had this problem with the Netscape Certificate libraries. They used to execute netstat in order to generate entropy when using certificates, so I figure this is what is going on here. I also see the sshd executing ps? Probably for the same reason.

RSA guys please use /dev/urandom and /dev/random.

We turned off the use of netstat in our libraries years ago. Using netstat and ps causes me to have to allow login programs to search /sys/net and because of bugs in our kernel add a dontaudit for sys_ptrace.

Finally secureid uses /var/ace to store its authorization content. This should probably be under /var/lib/ace, I have added a label for this directory

/var/ace(/.*)?                 gen_context(system_u:object_r:var_auth_t,s0)

This should allow the pam_securid module to use the content in this directory.

Now Joe can run his pam_securid.so on his machine in enforcing mode with a small custom module until we push updates to fix the problem.

Bottom line. If you are a third party and you are having problems running your tools with SELinux, please, please contact me or Red Hat and lets work through the problems, and give our users a better experience.

Dan Walsh: SELinux versus pam_google_authenticator...

dwalsh@redhat.com — Fri, 18 Nov 2011 15:45:17 +0000

I just became aware of a new PAM, pam_google_authenticator.

It is some kind of One TIme Password tool to allow you to add One Time Passwords to you Linux Login and I guess use your Android phone.

pam_google_authenticator causes login programs to try and write to ~/.google_authenticator by default. SELinux does not like this. SELinux prevents login programs from writing to random locations in the home directory. It is usually not a good idea to rely on stuff in the home dir for authorization because the homedir may require authorization to be able to be mounted or decrypted. (kNFS for example).

I got a bugzilla on sshd not being able to write to ~/.google_authenticator. One option would be to set the label on the .google_authenticator as ssh_home_t. I also did some "googling" and found the following entry:
http://code.google.com/p/google-authenticator/wiki/PamModuleInstructions

Comment by phil.may <snip>, Jul 7, 2011

If you are using Fedora and SELinux, you will need to use the right config. The default SELinux policy does not allow the SSH daemon to update the ~/.google_authenticator file.

In Fedora 14 (and possibly other versions) sshd runs under "sshd_t" and can only writelocations with certain SELinux labels. One such label is "var_auth_t" and the default policy sets this label on "/var/run/user/" Therefore, the following config works:

# If the user is NOT in group "otp_users", skip next module
auth [success=1 default=ignore] pam_succeed_if.so user notingroup otp_users
auth       required     pam_google_authenticator.so secret=/var/run/user/${USER}/.google_authenticator
auth       include      password-auth

BTW I have not tried this out on Fedora 16, and am curious if this will work, or does pam_google_authenticator expect the contents of .google_authenticator to survive a reboot.

Dan Walsh: Customizing the Kiosk OS.

dwalsh@redhat.com — Thu, 17 Nov 2011 20:54:01 +0000

I receve a decent amount of interest about the kiosk spin, but I have never formalized it as a fedora spin. The reason for this is almost everyone who looks at it, likes the idea but they need to customize it, in one way or another.

My vision of the Kiosk Operating system was that it was readonly and periodically an admin would recut/rebuild a newer version and then redestribute it to his machines. It is fairly easy to build your own image. Just download the kiosk kickstart file (kiosk.ks), make some customization and rebuild your ISO file using the livecd-tools. The last step would be to install it to your favorite medium, USB Sticks or DVD.

I recently received an email that requested:

"I have downloaded kiosk just this afternoon and tried on my laptop: as I have been requested for such a spin in our city library for eight computers, how can I build a spin with language/keyboard set as Italian??? (the standard procedure to change settings/Logout/login seems not to be working..) "

Here is how I would go about building the Italian version of the Kiosk Operating System.

On the currently released version of Fedora. As I write this blog, we are at Fedora 16. Login as root and and follow this procedure.

You are going to build the Kiosk Operating System using the spin-kickstarts, so we need to install the sortware.

# yum install spin-kickstarts livecd-tools
# cd /usr/share/spin-kickstarts

Make sure you have the latest kiosk.ks file from my people page. http://people.fedoraproject.org/~dwalsh/SELinux/kiosk/kiosk.ks

# rm -f kiosk.ks*
# wget http://people.fedoraproject.org/~dwalsh/SELinux/kiosk/kiosk.ks

Change the default language within the kickstart file. You can use your favorite editor to do this, and modify "lang" line. I will just use a sed command.

# sed -i 's/en_US.UTF8/it_IT.UTF-8/g' kiosk.ks

Now you can build a new kiosk image. Replacing the name of the livecd with your own content.

# livecd-creator -t MYLIBRARY -f MYLIBRARY -c kiosk.ks --cache=/var/cache/kiosk

Now go get a cup of coffee since this will take a long while, maybe a half hour.
When it finishes, you will have an ISO image named MYLIBRARY.iso. You need to install the iso ont a dvd or to a usb stick using livecd-iso-to-disk.

# livecd-iso-to-disk --totaltimeout 1 ./MYLIBRARY.iso /dev/sdb1

Remove your USB stick and attempt a boot a machine using it.

Of course if you want to add some less then free packages to your kiosk operating system, you would edit the kickstart file and add your alternative repositories.

For additional information on building livecd please use:

http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB

And on using kickstart files.

http://fedoraproject.org/wiki/Anaconda/Kickstart

Russell Coker (security): SE Linux Status in Debian 2011-10

etbe — Mon, 31 Oct 2011 12:22:43 +0000

Debian/Unstable Development

deb http://www.coker.com.au wheezy selinux

The above APT sources.list line has my repository for SE Linux packages that have been uploaded to Unstable and which will eventually go to testing and then the Wheezy release (if they aren’t obsoleted first). I have created that repository for people who want to track SE Linux development without waiting for an Unstable mirror to update.

In that repository I’ve included a new version of policycoreutils that now includes mcstrans and also has support for newer policy such that the latest selinux-policy-default package can be installed. The version that is currently in Testing supports upgrading policy on a running system but doesn’t support installing the policy on a system that previously didn’t run SE Linux.

I have also uploaded SE Linux Policy packages from upstream release 20110726 compared to the previous packages which were from upstream release 20100524. As the numbers imply there is 14 months of upstream policy development which changes many things. Many of the patches from my Squeeze policy packages are not yet incorporated in the policy I have uploaded to Unstable. I won’t guarantee that an Unstable system in Enforcing mode will do anything other than boot up and allow you to login via ssh. It’s definitely not ready for production but it’s also very suitable for development (10 years ago I did a lot of development on SE Linux systems that often denied login access, it wasn’t fun).

Kyle Moffett submitted a patch for libselinux which dramatically changed the build process. As Manoj (who wrote the previous build scripts) was not contactable I accepted Kyle’s patch as provided. Thanks for the patch Kyle, and thanks for all your work over the years Manoj. Anyway the result of these changes should mean that it’s easier to bootstrap Debian on a new architecture and easier to support multi-arch – but I haven’t tested either of these.

Squeeze

The policy packages from Squeeze can’t be compiled on Unstable. The newer policy compilation tool chain is more strict about how some things can be declared and used, thus some policy which was fairly dubious but usable is now invalid. While it wouldn’t be difficult to fix those problems I don’t plan to do so. There is no good reason for compiling Squeeze policy on Unstable now that I’ve uploaded a new upstream release.

deb http://www.coker.com.au squeeze selinux

I am still developing Squeeze policy and releasing it in the above APT repository. I will also get another policy release in a Squeeze update if possible to smooth the transition to Wheezy – the goal is that Squeeze policy will be usable on Wheezy even if it can’t be compiled. Also note that the compilation failures only affect the Debian package, it should still be possible to make modules for local use on a Wheezy system with Squeeze policy.

MLS

On Wednesday I’m giving a lecture at my local LUG about MLS on SE Linux. I hope to have a MLS demonstration system available to LUG members by then. Ideally I will have a MLS system running on a virtual server somewhere that’s accessible as well as a Xen/KVM image on a USB stick that can be copied by anyone at the meeting.

I don’t expect to spend much time on any aspect of SE Linux unrelated to MLS for the rest of the week.

Version Control

I need to change the way that I develop SE Linux packages, particularly the refpolicy source package (source of selinux-policy-default among others). A 20,000 line single patch is difficult to work with! I will have to switch to using quilt, once I get it working well it should save me time on my own development as well as making it easier to send patches upstream. Also I need to setup a public version control system so I can access the source from my workstation, laptop, and netbook. While doing that I might as well make it public so any interested people can help out. Suggestions on what type of VCS to use are welcome.

How You Can Help

Sorting out the mess that is the refpolicy package, sending patches upstream and migrating to a VCS is a fair bit of work. But there are lots of small parts. Sending patches upstream is a job that could be done in small pieces.

Writing new policy is not something to do yet. There’s not much point in doing that while I still haven’t merged all the patches from Squeeze – maybe next week. However I can provide the missing patches to anyone who wants to review them and assist with the merging.

I have a virtual server that has some spare capacity. One thing I would like to do is to have some virtual machines running Unstable with various configurations of server software. Then we could track Unstable on those images and use automated testing to ensure that nothing breaks. If anyone wants root access on a virtual server to install their favorite software then let me know. But such software needs to be maintained and tested!

Debian SSH and SE Linux I have just filed Debian bug report #556644 against the...
/run and SE Linux Policy Currently Debian/Unstable is going through a transition to using /run...
SE Linux status in Debian/Squeeze ffmpeg I’ve updated my SE Linux repository for Squeeze to...

Russell Coker (security): Capabilities vs SE Linux

etbe — Fri, 28 Oct 2011 02:47:57 +0000

In December 2010 a paper was published by Robert N.M. Watson and Jonathan Anderson from the Cambridge University and Ben Laurie and Kris Kennaway of Google about the Capsicum capabilities system [1]. It seems that the aim of the project is to allow systems that need privileges briefly when they start (such as tcpdump) a safe method of dropping privs. The main project page is here [2].

The focus of the paper is on the Chromium web browser and six different ways of constraining the Chromium sandbox are compared. For the SE Linux comparison they claim 200 lines of code changes as of Fedora 15, in Fedora 16 I couldn’t find a Chromium package, so I presume that they mean 200 lines of SE Linux policy (I am not aware of anyone modifying the Chromium source for SE Linux). They note that SE Linux doesn’t support separating different sandboxes, while it would be possible to have each sandbox be assigned a different MCS sensitivity label to separate them that option would be unwieldy enough that they are essentially correct in this regard. For SE Linux systems running the MLS policy the correct thing to do would be to run multiple copies of Chromium at different levels to access different sensitivity levels of data, this would normally be done by polyinstantiating the home directory.

One thing to note however is that there is no requirement that only one security method be implemented. I can’t think of any technical reason why it would be impossible to run SE Linux and Capsicum on the same system. SE Linux could constrain daemons and restrict the access to Capsicum services while Capsicum could be used to give minimum privileges to parts of Chromium. I’m not sure that such a combination would offer anything that the MLS users would desire, but it seems that everyone else (the vast majority of computer users) would be served well by a combination of SE Linux and Capsicum.

It’s disappointing that the paper didn’t mention Posix 1003.1e capabilities, but given the lack of use that Posix capabilities get that’s understandable.

It’s also disappointing when someone develops something new and different nowadays and doesn’t provide a virtual machine image for it. Installing and configuring something that requires application and kernel changes is a lot of work and most people who are idly curious about the technology won’t go to the effort. By today’s standards it’s not that difficult to share a 1GB filesystem image via Bittorrent.

SE Linux vs chroot A question that is often asked is whether to use...
Creating a SE Linux Chroot environment Why use a Chroot environment? A large part of the...
Context of /dev/xvc0 I have just converted a Fedora Core 5 server to...

Dan Walsh: Open Source how do I love thee, let me count the ways.

dwalsh@redhat.com — Tue, 25 Oct 2011 12:37:05 +0000

Yesterday I got contacted by Red Hat Support about a problem we had in libselinux. If you are setting up confined users you can use the semanage login command to setup a group of linux users to be assigned to a confined user type.

# semanage login -a -s staff_u -r s0-s0:c0.c1023 %wheel

This command would cause all linux users in the wheel group to login as the staff_u SELinux user. Well we had a bug in getseuserbyname function in libseliunux. When you login to a system the pam_selinux module uses this function to figure out which SELinux user should be used for your UID. There was a bug where we were not allocating enough memory for reading the entire group file contents. Basically if the number of users within a group was too large, the library would stop reading.

A customer of ours found the problem and reported it.

Now the reason I love Open Source...

The customer did not stop there. They downloaded our source, found the problem, built a patch and attached it to the bug report. So all I had to do was apply the patch and start the errata process.   This is the type of stuff that can't happen in a closed source system, and is why Open Source is better...

Open source is like The Elves and the Shoemaker, just don't tell my boss. :^)

James Morris: New GPG Key

jamesm — Sun, 23 Oct 2011 13:02:34 +0000

In support of the new kernel.org security scheme, I’ve created a new 4096 bit RSA key:

pub   4096R/FA118320 2011-10-23
      Key fingerprint = 4ED7 50E6 F7F9 ACED 29DD  B750 EB75 1458 FA11 8320
uid   James Morris <jmorris@namei.org>

I’ve published the key via the MIT key server.

I’ll continue to host the security subsystem tree on selinuxproject.org until things are fully set up on kernel.org.

Dan Walsh: 10 things you probably did not know about SELinux.. #8 How to remove a port from a port type?

dwalsh@redhat.com — Fri, 21 Oct 2011 15:01:11 +0000

How do you remove a network port from a network port type?

First a little explanation. Linux contains 65536 network ports for both UDP and TCP.
SELinux uses types to group network ports together. If you want to see a listing of the port types on the system you can execute:

semanage port -l
SELinux Port Type              Proto    Port Number

afs_bos_port_t                 udp      7007
afs_client_port_t              udp      7001
afs_fs_port_t                  tcp      2040
afs_fs_port_t                  udp      7000, 7005
...

Then we write rules in SELinux like

allow httpd_t http_port_t : tcp_socket name_bind ;

This rules says the apache process can execute the bind command using any port that is currently labeled http_port_t.

# semanage port -l | grep http_port_t
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443

Now a fairly common question that gets asked is, can I remove these ports.   IE I do not want to allow apache to bind to port 8008.

How would I do this?

The simplest thing to do is to redefine port 8008 as a different port type that httpd can not bind to.

The default port type for all unassigned ports > 1024 is unreserved_port_t or ephemeral_port_t (Fedora 16)

# semanage port -l | grep ^unreserved_port_t
unreserved_port_t              tcp      1024-32767, 61001-65535
unreserved_port_t              udp      1024-32767, 61001-65535
# semanage port -l | grep ^ephemeral_port_t
ephemeral_port_t               tcp      32768-61000
ephemeral_port_t               udp      32768-61000

Note SELinux will use a more specific port type if the port has been defined, for example when the kernel sees tcp port 8008, it will use http_port_t rather then unreserved_port_t.

But the admin can override this by adding his own port definition.

# semanage port -m -t unreserved_port_t -p tcp 8008

To prove this worked, I tested using apache.

# sed -i 's/Listen 80/Listen 8008/g' /etc/httpd/conf/httpd.conf
# semanage port -m -t unreserved_port_t -p tcp 8008
# service httpd restart
Restarting httpd (via systemctl): Job failed. See system logs and 'systemctl status' for details. [FAILED]
# semanage port -d -p tcp 8008
# service httpd restart
Restarting httpd (via systemctl):                          [ OK ]

NOTE:

Be careful doing this, because you have just changed the definition of http_port_t for ALL domains, not just the httpd_t domain.   Meaning if you were running firefox with a sandbox_web_t sandbox on the same machine, the firefox would no longer be able to connect to port 8008, because sandbox_web_t is only allowed to connect to http_port_t and 8008 is no longer defined as 8008.

Dan Walsh: How should you disable IPV6?

dwalsh@redhat.com — Wed, 19 Oct 2011 13:34:07 +0000

Blogging twice in the same day, a new record...

Lots of people are out there disabling IPV6, and when you do invariably you get a flood of AVC messages about different confined domains asking the kernel to load the kernel module net-pf-10.

type=AVC msg=audit(10/18/11 23:40:10.233:978087) : avc: denied { module_request } for pid=32265 comm=pickup kmod="net-pf-10" scontext=system_u:system_r:postfix_pickup_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system

Now I am not recommending that you enable or disable IPV6, but if you do want to disable it and run with SELinux turned on, please read the following:

Eric Paris reports

"I believe the networking kernel community recommends (and it will shut up these AVCs) that IPv6 be disabled by:

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

It still loads the module but unhooks almost all of the calls into the module. (apparently the IPv6 module has become so ingrained in the kernel that a number of other things, like certain firewall modules, require it. I didn't design it, I'm just telling it how it is) "

We recommend that you do not disable the ipv6 module but add

net.ipv6.conf.all.disable_ipv6 = 1

to /etc/sysctl.conf

And the AVC messages should go away.

The setroubleshoot plugin in Fedora reflects this info.

Dan Walsh: Making a domain "unconfined"

dwalsh@redhat.com — Wed, 19 Oct 2011 13:01:03 +0000

In a couple of previous blogs I talked about permissive and unconfined domains.

http://danwalsh.livejournal.com/24537.html?thread=176857
http://danwalsh.livejournal.com/42394.html

Today we had a question about how to I disable_trans on pam_console_t in Red Hat Enterprise Linux 6.
If you have used RHEL5 or have read one of the blogs above you will realize in RHEL5 we had a lot of booleans DOMAIN_disable_trans. The idea was to run these domains without SELinux protection. We quickly figured out that this was a bad idea. Other confined domains would start failing because the process they were supposed to communicate with would be running with a different label. Or files created by the disabled_trans DOMAIN would now get created with the wrong labels.

In RHEL6 we introduced permissive domains, so that you could run the entire system locked down but pick a few process domains to run in permissive mode. The nice thing about this is we can figure out what the domain wants to do and improve the policy.

Miroslav Grepl came up with a third solution to the problem today. Basically if a administrator wants to just allow a domain to do what it wants, he can add a policy module that turns the domain into an unconfined domain. This will work on all Fedora releases and RHEL5 as well as RHEL6. And is a much better solution then the disable_trans boolean.

If you wanted to run pam_console_t as an unconfined domain, you would first create a file call mypam.te.

# cat mypam.te
policy_module(mypam, 1.0)
gen_requires(`
type pam_console_t;
')
unconfined_domain(pam_console_t)
# make -f /usr/share/selinux/devel/Makefile
# semodule -i mypam.pp

Now pam_console_t will be an unconfined domain, but any confined domain that needs to interact with it will still work. All of the file transition rules will still happen, so the system should stay labelled properly. And no AVC messages will be generated about this domain.

Dan Walsh: setrans is a handy little tool to analyze policy transitions

dwalsh@redhat.com — Wed, 12 Oct 2011 16:09:47 +0000

For several years we have had a SELinux tool set called setools that allows you to analyse policy. I use sesearch and seinfo all the time for looking at policy. setools includes a tcl/tk interface, called apol, that allows you to ask really complicated questions in policy about whether one process and read/write a file, even through process transitions. The problem is the GUI is a little clunky, and I don't like GUIs.

A few years ago I added python bindings for sesearch and seinfo to the setools/apol libraries. These python interfaces are used within some of the semanage tool chain.

I often see an AVC about one domain not being able to write to another domains files. Usually these types of avc's are caused by passing an open file descriptor, like stdout, from one process to another process. Sometimes I am puzzled by the relationship between the two domains. I recently got an AVC about ldconfig_t not being able to write to a chr_file labeled mock_var_lib_t. How does the ldconfig program even know about a chr_file labeled mock_var_lib_t? How did did mock transition to the ldconfig domain?

Well I wrote a tool, setrans, that helps answer these question. The tool takes two domain/process types and attempts to see if the first
type can transition to the second type, and then print all of the intermediary types that it used to get from one domain to the other.

./setrans init_t httpd_t
init_t --> httpd_t

./setrans mock_t ldconfig_t
mock_t --> mount_t --> insmod_t --> initrc_t --> ldconfig_t

./setrans mock_t user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> stunnel_t --> rlogind_t --> remote_login_t --> unpriv_userdomain --> user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> crond_t --> user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> getty_t --> local_login_t --> userdomain --> user_t
mock_t --> mount_t --> insmod_t --> initrc_t --> xdm_t --> gkeyringd_domain --> user_t

I know that it is not complete and will not show all paths, but it is pretty useful for quick analyses of the policy.

Dan Walsh: Fedora 16 New SELinux Feature part IV - Shrinking policy

dwalsh@redhat.com — Fri, 30 Sep 2011 18:30:05 +0000

Back in July the systemd team was trying to decrease the boot time on early versions of Fedora 16. They found that with a Solid State disk, SELinux policy load and relabel was quickly becoming the biggest pig as far as boot time. So they added some log messages that showed how long it was taking to just read the selinux policy off of disk and load it into the kernel.

Lennart Poettering announced systemd 32 with the following message.

Primarily bugfixes, and one really cool improvement: we can now load the SELinux policy without having to reexecute ourselves. This is much
prettier and saves up to 70ms or so. I also added some basic profiling output for SELinux which unfortunately shows that SELinux costs around
5s on every boot on f16 (and that on my really fast machine!). Sad. 

Look for output like this:

[   10.727004] systemd[1]: Successfully loaded SELinux policy in 3s 270ms 896us.
[   10.769204] systemd[1]: Successfully loaded SELinux database in 41ms 700us, size on heap is 460K.
[   11.943903] systemd[1]: Relabelled /dev and /run in 1s 125ms 738us.

He even added these lines to every boot, so everyone would know how much time SELinux was costing them on boot.

Nothing like public embarrassment to make you take action.

Shame is a great motivator. :^(

I decided to take a look at the policy using the sesearch tools. I wanted to figure out where all the rules were coming from, and whether we had some duplicates we could remove. The first thing I noticed was there were thousands of rules related to network ports. To me there seemed to be way to many. I began to investigate and found that M4 macro expansion was the problem.

SELinux policy is written using m4. Over the years we have written lots of macros which policy writers take advantage. We call these macros interfaces. Another feature of SELinux policy is the use of attributes. Attrinbutes are a way of grouping lots of types (init_t, httpd_t) together. You can create a new user type say staff_t and add an attribute say usertype. Now you write rules regarding the usertype that affect all users.

allow usertype etc_t:file read;

SELinux also defines network port attributes like port_type and reserved_port_type. All network ports get the attribute port_type and all ports < 1024 get the attribute reserved port type. Well M4 has a cool feature "negation".   SELinux policy was using negation in many places including defineing unreserved_ports. For example in Fedora 15 we have an interface that says.

interface(`corenet_tcp_bind_all_unreserved_ports',`
    gen_require(`
        attribute port_type, reserved_port_type;
    ')

    allow $1 { port_type -reserved_port_type }:tcp_socket name_bind;
')

All types that need to bind to ports > 1023 would then using this interface.

/usr/bin/ssh (ssh_t) needs to be able to setup alternate ports to allow a tunnel connection between a remote sshd service and the local machine, so we allow it to bind to any port > 1023 using the following line:

corenet_tcp_bind_all_unreserved_ports(ssh_t)

Seems like a simple rule to add, until you understand how m4 works with negation. M4 expands out all the attributes into their types and then writes a rule for each type that matches. A rule like this could end up adding 100s of allow rules. For every type that is a port_type and not a reserved_port_type, a rule would be written allowing ssh_t to bind to the port.

allow ssh_t amqp_port_t:tcp_socket name_bind;
allow ssh_t asterisk_port_t:tcp_socket name_bind;
...

I found that if I defined a new attribute "unreserved_port_type", and rewrote the interface to something like.

interface(`corenet_tcp_bind_all_unreserved_ports',`
    gen_require(`
        attribute port_type, reserved_port_type;
    ')

    allow $1 unreserved_port_type:tcp_socket name_bind;
')

I ended up with only one rule generated by

corenet_tcp_bind_all_unreserved_ports(ssh_t)

allow ssh_t unreserved_port_type:tcp_socket name_bind;

Turns out we had lots and lots of interfaces where we used the negation.

    dontaudit $1 { port_type -port_t }:dccp_socket name_bind;
    files_read_all_dirs_except($1, $2 -shadow_t)

I went through the entire policy and switched to using only attributes like unreserved_port_type attributes and shrunk the size of policy by about 80 %.

What is really nice, you can check the size of policy using seinfo.
----------------------------
As time went on F15 machine:
$ seinfo
Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)
Allow:          282444
Dontaudit:      184516

and on F16 machine:

$ seinfo
Statistics for policy file: /etc/selinux/targeted/policy/policy.26
Policy Version & Type: v.26 (binary, mls)
Allow:           88242
Dontaudit:       11302

Tools used to load the policy run about 3 times as fast.

Conclusion:

Tom London looked at the change on his machine and found

And comparing 'old vs. new' boot times, first the old:

Jul 28 06:39:29 tlondon systemd[1]: Startup finished in 3s 336ms 755us (kernel) + 11s 625ms 240us (initrd) + 28s 189ms 914us (userspace) = 43s 151ms 909us.

And now the 'new':

Jul 29 06:00:41 tlondon systemd[1]: Startup finished in 1s 844ms 542us (kernel) + 4s 999ms 977us (initrd) + 29s 239ms 766us (userspace) = 36s 84ms 285us.

6.5 seconds less in initrd.

A second feature of this change is we are now taking up probably 80% less kernel memory...

RHEL 6
# du -s /etc/selinux/targeted/policy/policy.24
6004 /etc/selinux/targeted/policy/policy.24

Fedora 16:

# du -s /etc/selinux/targeted/policy/policy.26
2156 /etc/selinux/targeted/policy/policy.26

And Fedora 16 has more domains, types and rules...

At some point I should probably back port these changes to RHEL6.

Dan Walsh: Fedora 16 New SELinux Feature part III - permissivedomains module

dwalsh@redhat.com — Thu, 29 Sep 2011 13:17:50 +0000

As has been stated in previous blogs we have three types of unconfined processes on Fedora.

We have unconfined_domain() system processes. initrc_t, init_t, kernel_t, ...
We have unconfined_domain() user processes. unconfined_t,
We have permissivedomains

Up until now you can remove unoconfined system processes by disabling the unconfined.pp module.

semodule -d unconfined

You can disable the unconfined users by removing unconfined user mappings and then disabling unconfineduser.pp

# semanage login -m -a staff_u __default__
# semanage login -m -a staff_u root
You might need to log out and back in now as sysadm_t and make sure there are no unconfined_u/unconfined_t processes running. Also make sure that you do not have any entries in /etc/sudoers for unconfined_t or files left over in /tmp or /var/db/sudo.
# semanage user -d unconfined_u
# semode -d unconfineduser

But you could not get rid of permissive domains, since the permissive flag was in individual policy modules. In F16 we re-factored all of the permissive domain declarations into a new module called permissivedomains.pp. If you want to remove all permissive domains from your system
you can execute

semodule -d permissivedomains

# semanage permissive -l
Builtin Permissive Types

Customized Permissive Types

This will give you a fully locked down machine.

Thomas Biege (Security): 4th German OWASP Security Day

Thomas (noreply@blogger.com) — Thu, 22 Sep 2011 01:09:14 +0000

My submission to the 4th German OWASP Security Day was accepted. Now let's see if we can accept their OWASP license that needs to be signed...

kostenloser Counter

Thomas Biege (Security): I am leaving the SUSE Security Team...

Thomas (noreply@blogger.com) — Wed, 21 Sep 2011 03:25:20 +0000

After 12 years I am leaving the SUSE Security-Team... just to support them! :-)

Like a satellite I was spun-off from mother earth. Flying around the SUSE Security Team as project-manager to take care of our products before they get released working hand-in-hand with Marcus and his team that (mostly but not exclusively) takes care of the security of already released products.

kostenloser Counter

James Morris: Linux Security Summit 2011 – Presentation Slides

jamesm — Tue, 20 Sep 2011 05:41:52 +0000

Just over a week ago, the 2011 Linux Security Summit was held in Santa Rosa CA, co-located with Linux Plumbers. It ran for a day, starting with refereed presentations, and then round-table discussions.

The home page for the summit is on the kernel.org wiki, and is currently unavailable, so I’m posting links to the slides here:

* Smack is Alive and Well
Casey Schaufler, Intel

* An Overview of the Linux Integrity Subsystem: Use Cases and Demonstration
David Safford and Mimi Zohar, IBM

* Digital Signature support for IMA/EVM
Dmitry Kasatkin and Ryan Ware, Intel (presented by Casey)

* Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM
Peter Kruus, The Johns Hopkins University Applied Physics Laboratory

* Efficient, TPM-free system integrity checking with device mapper: dm-verity
Will Drewry and Mandeep Baines, Google

* The Case for SE Android
Stephen Smalley, NSA

Roundtable discussions:

* Kernel Hardening [no slides]
Lead by Kees Cook, Canonical and Will Drewry, Google

* LSM Architecture
Lead by Kees Cook, Canonical and Casey Schaufler

The SE Android talk was a last minute replacement for Ryan Ware’s talk on MeeGo (Ryan was unfortunately not able to make it).

See the write-ups by by Paul Moore and LWN.

Feedback so far has been positive. I think it’s valuable for the security developers to get together like this, after spending the rest of the year working remotely with each other. Next year, we’ll likely be looking at co-locating with LPC/KS/LinuxCon in San Diego. It may be worth thinking about expanding to a two-day event, with the first day following the same format, but then splitting into project groups on day two for BoFs/hack sessions.

Contact the program committee if you have any suggestions.

I’d like to thank the LPC folk, and especially Jesse Barnes, for allowing us to co-locate and taking care of all of the logistics — all we had to do was organize the talks and turn up. Also thanks to the speakers, discussion leaders and attendees. See you next year!

Paul Moore: Wrapping Up The 2011 Linux Security Summit

Fri, 09 Sep 2011 06:55:34 +0000

We just closed the doors on the 2011 Linux Security Summit a few hours ago and I wanted to jot down a few notes while everything was still fresh in my mind. Once again, a big thanks to all of our presenters, James Morris and the rest of the organizing committee; my personal opinion is that the summit was a success this year and I look forward to doing this again in 2012.

Just as in the past, presentations will be posted at the wiki below once kernel.org comes back online.

http://security.wiki.kernel.org/index.php/LinuxSecuritySummit2011

Smack is Alive and Well, Casey Schaufler

This presentation started with a brief introduction to Smack and then moved on to presenting the recent users, motivations and focus. While Smack has been incorporated into at least one general purpose Linux Distribution, Ubuntu, over the past year or two Smack has grown increasingly focused on small and embedded devices. Functionality wise, Smack has gained several new additions including process labels and transmutable directories. Process labels allow an executable file to be started with a label specified in the file's xattrs and not the parent process's attributes. Transmutable directories allow two differently labeled processes to write into each other's directories without requiring full write access to the other label; this should make it much easier to share files and data between labels. Beyond the new functionality, performance improvements, increased Linux Test Project coverage and improved consistency between AF_UNIX and AF_INET sockets have seen their way, or will soon see their way into Smack.

MeeGo platform security, including Smack userspace: http://meego.gitorious.org/meego-platform-security

The Case for SE Android, Stephen Smalley

This presentation discussed a recent effort to prototype a SELinux implementation for Android. While SELinux is well known in desktop and server Linux environments, it is still rare in mobile and embedded systems due to concerns around resource usage and differences in both the kernels and userspace. This talk explained the basic Linux/Android differences and what was needed to enable SELinux on the Android platform. Resource issues around policy size were addressed through a greatly simplified SELinux policy which avoided per-application policy and relied on a relatively simple rule set. Finally, the effectiveness of the prototype was evaluated by examining a recent Android vulnerability with a known exploit and determining the effectiveness of the SELinux Android port in preventing the exploit. In the end, this remains a prototype at present, designed to investigate Android's security capabilities, but it shows quite a bit of promise and has a lot to offer beyond the current Android security functionality.

Overview of the Linux Integrity Architecture, David Safford and Mimi Zohar

The Linux Integrity Architecture project has seen a lot of activity over the past few years and the presentation started off with an overview of project, including a status update on where each piece of functionality stood with respect to upstream and established distributions. The good news is that almost all of the IMA project is either currently upstream or patches have been submitted and are being discussed on the related mailing lists. One of the presentation highlights was a demo tying together the IMA principals and virtualization to demonstrate a "Trusted Cloud". While there is work to be done, the IMA project has made great strides and already offers some impressive functionality.

IMA project website: http://linux-ima.sf.net

Digital Signature Support for IMA/EVM, Dmitry Kasatkin and Casey Schaufler

This presentation addressed a problem common to system and device manufacturers who install a single "golden image" on each system they ship: how do you reconcile the business need of a single install image with a TPM based EVM HMAC which uses a per-device key stored in the TPM? One potential answer is to expand on the EVM mechanism to support public key digital signatures in addition to the TPM based HMAC. When the devices are initially installed, a public key certificate is installed into the Linux Kernel keyring via an initrd with the filesystem using digital signatures for the EVM xattr in place of the traditional HMAC. As the files are accessed, the EVM digital signature is verified, and if correct, it is replaced by a TPM generated HMAC. If the EVM digital signature verification fails, access is denied in the same way as if the EVM HMAC verification had failed.

Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM, Peter Kruus

This presentation covered some work being done to better secure Fedora 15 guests running on VMWare ESXi while the guests were both running and offline. All systems are vulnerable to offline attacks, but in the case of virtual systems, offline vulnerabilities can sometimes be much easier to exploit due to the availability of the host system and guest storage volumes. In order to help mitigate this problem, the presenter leveraged the existing IMA/EVM support in Fedora 15 to verify the integrity of critical system files, but unfortunately due to missing vTPM support in VMWare ESXi the presenter was unable to leverage TPM based HMACs in the EVM attributes. The solution was to use a passphrase protected key which was loaded at boot through a combination of the system's initrd and dracut. While this solution does provide an increased level of protection against attack, for this approach to be truly successful, full vTPM support is needed in the hypervisor to allow the guest to utilize the TPM. While vTPM patches have been submitted for QEMU/KVM, the state of the vTPM in VMWare ESXi is unknown.

Integrity-checked Block Devices with Device Mapper, Will Drewry and Mandeep Baines

This presentation dealt with an enhancement to the Linux Kernel Device Mapper to perform block level integrity verification. This solution was designed primarily for the Linux based Chromium OS running on modest netbook class hardware where boot performance was a significant requirement. Helping to simplify the solution was the fact that the system is very well defined and operates in a read-only mode such that the integrity verification mechanism does not need to worry about online updates to the storage volume. The solution, dm-verity, uses a slightly modified hash tree, with the root hash specified on the kernel command line to quickly verify the integrity of the entire block device. Optimization is ongoing, but already the developers are able to boot a ~800MB Chromium OS root partition in ~1.2s on an Atom CPU using a SSD storage volume. While this integrity verification solution may not lend itself quite as well to general purpose systems as the TPM/IMA based solutions, it presents a novel solution that helps solve Chromium OS's needs in a a high performance, low cost manner.

Kernel Hardening Roundtable, Kees Cook and Will Drewry

This roundtable started with a discussion on the different kernel interfaces where the kernel is exposed to user input, malicious or otherwise. From here the focus shifted to how the existing security mechanisms, such as DAC, LSM and capabilities, impact the kernel's exposed interfaces - for better or worse. At this point it was clear, if it wasn't already, that the Linux Kernel remains far too exposed to malicious users/applications and some additional hardening techniques are needed.

While many hardening ideas were discussed, the two main points of discussion revolved around system call filtering/reduction and the hardening techniques found in grsecurity. With respect to system call filtering, work has been ongoing this year to expand the mainline seccomp functionality to be more flexible and useful for a wider range of applications. Plenty of discussion has already occurred on the mailing lists and more is expected as the enhanced seccomp developer has promised a new round of patches soon. Similarly, work has recently been ongoing to decompose the rejected grsecurity patch and repackage it in a series of patches which will hopefully be acceptable to the upstream kernel maintainers.

Sandbox powered by the current mainline seccomp: http://code.google.com/p/seccompsandbox
Ubuntu Linux Kernel hardening tasks: http://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream_Hardening
Linux Kernel hardening mailing lists: http://www.openwall.com/lists (see the kernel-hardening list)

LSM Architecture Roundtable, Kees Cook and Casey Schaufler

This roundtable dealt primarily with the issues related to multiple LSMs, from APIs and determining which LSM was enabled in the kernel to architectural issues blocking multiple concurrent LSMs. With respect to determining the active LSM and LSM APIs, the discussion was largely a group brainstorming session with developers discussing the pros and cons of various solutions; while most agreed the a general LSM userspace API was more problem than it was worth, there was some general agreement on LSM conventions that should help unify some of the most basic LSM API functionality in the future.

This discussion around running multiple concurrent LSMs was much more focused, with patches being proposed as recently as February, although everyone did agree that the patches had serious limitations due to shortcomings with the LSM hooks/blobs in the kernel. In the end, several inherent blockers to concurrent LSM operation remained, but the "religious" arguments against the idea seemed to be less than in past years.

Dan Walsh: Fedora 16 Alpha available part II, New SELinux Feature/File Name Transitions

dwalsh@redhat.com — Tue, 30 Aug 2011 13:41:01 +0000

Fedora 16 Alpha was just released: The announcement include the following:

SELinux Enhancements. SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, SELinux file name transition allows better policy management. For instance, policy writers can take advantage of this and write a policy rule that states, if a SELinux unconfined process creates a file named resolv.conf in a directory labelled etc_t, the file should get labeled appropriately. This results is less chances of mislabeled files. Also, from this release onwards, selinuxfs is mounted at /sys/fs/selinux instead of in /selinux. All the affected components including anaconda, dracut, livecd-tools and policycoreutils have been modified to work with this change.

Named File Transitions Feature

This feature was added to F16 to make labelling files easier for users and administrators. The goal is to prevent accidental mislabelling of file objects.

Accidental mislabelling

Users or administrators often create files or directories that do not have the same label as the parent directory, and then forget to fix the label. An example of this would be the administrator going into the /root directory and creating the .ssh directory. In previous versions of Fedora, the directory would get created admin_home_t, even though the policy requires it to be labelled ssh_home_t. Later when he tries to use the content of the .ssh directory to login without a password, sshd (sshd_t) fails to read the directories contents because sshd is not allowed to read files labelled admin_home_t.

Another example would be a user creating the public_html directory in his home directory. The default label for content in the home directory is user_home_t, but SELinux requires the public_html directory to be labelled http_user_content_t or the apache process (httpd_t) will not be allowed to read it.

File Transitions Policy

Policy writers have always be able to write a file transition rule that includes the type of the processes creating the file object (NetworkManger_t), the type of the directory that will contain the file object (etc_t) and the class of the file object (file). Then specify the type of the created object (net_conf_t).

filetrans_pattern(NetworkManager_t, etc_t, file, net_conf_t)

This policy line says that a process running as NetworkManager_t creating any file in a directory labelled etc_t will create it with the label net_conf_t.

Named File Transitions Policy

Eric Paris added a cool feature to the kernel that allows the kernel to label a file based on 4 characteristics instead of just three. He added the base file name. (Not the path).

Now we can write policy rules that state:

If the unconfined_t user process creates the ".ssh" directory in a directory labelled admin_home_t, then it will get created with the label ssh_home_t.

filetrans_pattern(unconfined_t, admin_home_t, dir, ssh_home_t, ".ssh")
If the staff_t user process creates a directory named public_html in a directory labeled user_home_dir_t it will get labeled

http_user_content_t. filetrans_pattern(staff_t, user_home_dir_t, dir, http_user_content_t, "public_html")

Additionally we have added rules to make sure if the kernel creates content in /dev it will label it correctly rather then waiting for udev to fix the label.

filetrans_pattern(kernel_t, device_t, chr_file, wireless_device_t, "rfkill")

Bottom line.

There should be less occurrences of accidental mislabels by users and hopefully a more secure and better running SELinux system.

Dan Walsh: Fedora 16 Alpha available, New SELinux Feature/Prebuilt Policy.

dwalsh@redhat.com — Tue, 30 Aug 2011 13:37:13 +0000

Fedora 16 Alpha was just released: The announcement include the following:

SELinux Enhancements.
SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, SELinux file name transition allows better policy management. For instance, policy writers can take advantage of this and write a policy rule that states, if a SELinux unconfined process creates a file named resolv.conf in a directory labelled etc_t, the file should get labeled appropriately. This results is less chances of mislabeled files. Also, from this release onwards, selinuxfs is mounted at /sys/fs/selinux instead of in /selinux. All the affected components including anaconda, dracut, livecd-tools and policycoreutils have been modified to work with this change.

Pre-Built Policy

We made major changes to the selinux-policy-TYPE rpm. (selinux-policy-targeted-3.10.0-21.fc16)

The rpm now includes a pre-built /etc/selinux/targeted/policy/policy.26. This policy file can be loaded right away in a fresh install. In all previous versions of SELinux for RHEL and Fedora, we rebuilt this file in the post install. The reason for this is we need to recompile in local customizations that the user/administrator might have made on your system. Additionally if any package shipped with a policy we would need to recompile in those policy packages. But as the size of policy grew we were seeing Anaconda installation times grow and memory requirements grow because of selinux-policy package. We were even seeing virtual machine installations blow up on selinux-policy package installs because of limited memory. When we looked at the problem, we realized that on initial install of policy, no user would have made local customizations and very few packages are shipping with their own policy.

I reworked the tools to include the policy packages within the payload and now the package will check in the pre-install if there was any local customizations, if yes, the post install will recompile the policy, but if not the policy will just install.

We also used to have to ship all of the policy modules, over 300, in the directory /usr/share/selinux/targeted and these would be copied into /etc/selinux/targeted/modules/active/, were we would never touch the files in /usr/share/selinux/targeted again. Now we install directly into /etc/selinux/targeted/modules/active/.

What you should see is faster initial installs and faster selinux-package updates. In Fedora 15 a policy-package update would take around 45-50 seconds, in Fedora 16 on an unmodified selinux-policy system it should take < 15 seconds. If you are updating from Fedora 15 the first time, it will still take a long time, but the next update should go quick. If you have modified the SELinux system by adding pp
files you will still see the recompile times that you always have. :^(

Dan Walsh: Fedora 16 Alpha available part II, New SELinux Feature/File Name Transitions

dwalsh@redhat.com — Fri, 26 Aug 2011 13:28:51 +0000

Fedora 16 Alpha was just released:

The announcement include the following:

SELinux Enhancements. SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, SELinux file name transition allows better policy management. For instance, policy writers can take advantage of this and write a policy rule that states, if a SELinux unconfined process creates a file named resolv.conf in a directory labelled etc_t, the file should get labeled appropriately. This results is less chances of mislabeled files. Also, from this release onwards, selinuxfs is mounted at /sys/fs/selinux instead of in /selinux. All the affected components including anaconda, dracut, livecd-tools and policycoreutils have been modified to work with this change.

Named File Transitions Feature

This feature was added to F16 to make labelling files easier for users and administrators.

The goal is to prevent accidental mislabelling of file objects.

Accidental mislabelling

Users or administrators often create files or directories that do not have the same label as the parent directory, and then forget to fix the label. An example of this would be the administrator going into the /root directory and creating the .ssh directory.

In previous versions of Fedora, the directory would get created admin_home_t, even though the policy requires it to be labelled ssh_home_t. Later when he tries to use the content of the .ssh directory to login without a password, sshd (sshd_t) fails to read the directories contents because sshd is not allowed to read files labelled admin_home_t.

Another example would be a user creating the public_html directory in his home directory. The default label for content in the home directory is user_home_t, but SELinux requires the public_html directory to be labelled http_user_content_t or the apache process (httpd_t) will not be allowed to read it.

File Transitions Policy

Policy writers have always be able to write a file transition rule that includes the type of the processes creating the file object (NetworkManger_t), the type of the directory that will contain the file object (etc_t) and the class of the file object (file). Then specify the type of the created object (net_conf_t).

filetrans_pattern(NetworkManager_t, etc_t, file, net_conf_t)

This policy line says that a process running as NetworkManager_t creating any file in a directory labelled etc_t will create it with the label net_conf_t.

Named File Transitions Policy

Eric Paris added a cool feature to the kernel that allows the kernel to label a file based on 4 characteristics instead of just three. He added the base file name. (Not the path).

Now we can write policy rules that state:

If the unconfined_t user process creates the ".ssh" directory in a directory labelled admin_home_t, then it will get created with the label ssh_home_t.

filetrans_pattern(unconfined_t, admin_home_t, dir, ssh_home_t, ".ssh")
If the staff_t user process creates a directory named public_html in a directory labeled user_home_dir_t it will get labeled http_user_content_t.

filetrans_pattern(staff_t, user_home_dir_t, dir, http_user_content_t, "public_html")

Additionally we have added rules to make sure if the kernel creates content in /dev it will label it correctly rather then waiting for udev to fix the label.
filetrans_pattern(kernel_t, device_t, chr_file, wireless_device_t, "rfkill")

Bottom line.

There should be less occurrences of accidental mislabels by users and hopefully a more secure and better running SELinux system.

Dan Walsh: sVirt to the Rescue

dwalsh@redhat.com — Thu, 25 Aug 2011 18:07:17 +0000

At the recent Black Hat conference Nelson Elhage presented:

Virtualization Under Attack: Breaking out of KVM

The exploit, CVE-2011-1751, would allow a cracker to execute code in qemu-kvm process on the host.

Note: Red Hat fixed this problem back in May 2011 prior to the publication of the paper and exploit. Customers who applied our security updates are not affected by this issue. So 0 days of exposure.

In the presentation there is this bullet point:

qemu-kvm is often sandboxed using SELinux or similar, meaning that
successful exploitation will often require a second privesc within the
host.
(Fortunately, Linux never has any of those)

This means that SELinux/sVirt on Red Hat Enterprise Linux and Fedora confines this outbreak!

In a previous blog, Fun with sVirt., I showed how you can simulate this vulnerability to see what access was available. Not much...

Nelson mentioned SELinux sandboxing could be bypassed by a theoretical second "privesc" vulnerability, meaning a bug in the kernel. SELinux or any kind of Mandatory Access Control is enforced by the Kernel. Bugs in that Kernel, that a process is allowed to access, can subvirt SELinux. But SELinux is putting up a significant second barrier to the cracker.

Security is all about Layers, making each layer as secure as possible and then fixing vulnerabilities as quickly as you know about them.

This presentation exposes the risk associated with virtualization, but also shows the secondary security controls Linux KVM is using to minimize the risk and giving us time to fix problems as soon as we know about them.

Bottom line, this is why you leave SELinux enabled in enforcing mode. :^)

Dominick Grift: Git daemon and SELinux with RHEL6

Dominick "domg472" Grift (noreply@blogger.com) — Tue, 23 Aug 2011 12:17:12 +0000

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

Paul Moore: Twitter Too

Mon, 15 Aug 2011 22:39:18 +0000

To add to the recent email updates, I thought I would mention that I'm now on twitter too at @paul_via_tweet. Not much there right now, but since all the "cool kids" are on the twitter these days, how could I resist?

Dan Walsh: Fedora 16 is about to go to Alpha release, some SELinux changes.

dwalsh@redhat.com — Thu, 11 Aug 2011 13:24:44 +0000

First with the move to systemd, we were asked to move the /selinux file system to a more standard location.

From this point forward the selinuxfs will be mounted under /sys/fs/selinux.

This seems to be the new location for kernel interface file systems, like cgroup

# ls /sys/fs/
cgroup ext4 fuse selinux

libselinux has been modified to mount the selinuxfs file system on the /sys/fs/selinux directory if it exists, otherwise libselinux will fall back to mounting on the /selinux directory if it exists.

One problem I foresee and we are beginning to fix is any application that hard coded "/selinux" in to the application. So far we have had to fix anaconda, livecd-tools, policycoreutils, and dracut. In most cases you should use the command line tools like setenforce or selinuxenabeled, or use the python bindings

python
>>> import selinux
>>> print (selinux.is_selinux_enabled())
1

And not hard code the path.

Another option is to grep /proc/self/mountinfo

# grep selinuxfs /proc/self/mountinfo | head -1 | awk '{ print $5 }'
/sys/fs/selinux

If you know of any applications that hard code /selinux into them, please let me know and I can work with the maintainer or developer to fix the code.

Paul Moore: New Email Address Part Two

Wed, 10 Aug 2011 18:08:11 +0000

Hello again, last week I made a quick post to say that my @hp.com email address was going away; the reason for that, as many had guessed, was that I was leaving HP for a new employer. As of this past Monday, August 8th, 2011, I'm happy to say that I am now working for Red Hat. This should be good news for anyone interested in the Linux labeled networking bits and the assorted LSM network access controls as my new employer should allow me to spend more time maintaining and working on these things than I have over the past few years.

So, with a new job comes a new email address; you can continue to send me email at paul@paul-moore.com, but now you can also reach me at pmoore@redhat.com.

Paul Moore: New Email Address

Mon, 01 Aug 2011 21:16:45 +0000

Just a quick update to let everyone know that my @hp.com email address is going to stop working on Friday, August 5, 2011. If you need to get in touch with me please send me email at paul@paul-moore.com.

Thomas Biege (Security): Scanny will replace the ror-sec-scanner

Thomas (noreply@blogger.com) — Tue, 26 Jul 2011 05:08:50 +0000

David and Flavio created a new github project to replace my ror-sec-scanner. "Scanny" doesn't uses regex but the AST and emits fewer false positives. So lets start adding rules/checks to it to become more powerful.

kostenloser Counter

Russell Coker (security): SE Linux File Context Precedence

etbe — Sun, 24 Jul 2011 05:54:20 +0000

In my previous post I expressed a desire to use regular expressions for files that may appear in multiple places in the tree due to bind mounts for /run and /var/run etc [1]. However there is a problem with this idea.

The SE Linux file labeling program restorecon reads the file /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts which contains a set of regular expressions to assign labels to files. That file is ordered and the last entry which matches is the one that counts. When the file_contexts file is created the order is based on how many characters at the start of the file specification aren’t regular expression meta-characters. For example the entry “/.*” is at the top of the file (and therefore has the lowest precedence), which makes it the catch-all entry for files that have no other match. So an entry for “/var/run/REGEX” will have a higher precedence than one for “/var/REGEX”, this means however that when I replaced the “/var/run” part with a regular expression then it had a lower precedence and it didn’t work properly.

I should have remembered this as I did a lot of work on setfiles (which became restorecon) in the early days. I have now developed a new way of solving this and this time I’m testing it before blogging about it.

I have written the following PERL program to fix the file contexts, this adds multiple lines and uses a distro_debian conditional on them so that they don’t slip into upstream use – and so that if I lose track of where each patch came from I’ll know that I can delete them in future because it only matters to Debian.

#!/usr/bin/perl
use warnings;
use strict;

open(LIST, "find . -name \"*.fc\"|xargs egrep \"^/(var.*run)|(var/lock)|(dev/shm)\"|cut -f1 -d:|uniq|") or die "Can't get file list\n";
while(<LIST>)
{
my $filename = $_;
chomp $filename;
open(my $infile, "<", $filename) or die "Can't open file $filename";
open(my $outfile, ">", $filename . ".new") or die "Can't open file ". $filename . ".new";
while(<$infile>)
{
print $outfile $_;
my $newline;
if($_ =~ /^\/var\/run/)
{
print $outfile "ifdef(`distro_debian', `\n";
$newline = $_;
$newline =~ s/^\/var//;
print $outfile $newline;
print $outfile "')\n";
}
if($_ =~ /^\/var\/lock/)
{
print $outfile "ifdef(`distro_debian', `\n";
$newline = $_;
$newline =~ s/^\/var/\/var\/run/;
print $outfile $newline;
$newline =~ s/^\/var//;
print $outfile $newline;
print $outfile "')\n";
}
if($_ =~ /^\/dev\/shm/)
{
print $outfile "ifdef(`distro_debian', `\n";
$newline = $_;
$newline =~ s/^\/dev/\/run/;
print $outfile $newline;
print $outfile "/var" . $newline;
print $outfile "')\n";
}
}
close($infile);
close($outfile);
rename $filename . ".new", $filename or die "Can't rename " . $filename . ".new to " . $filename;
}

The next policy thing that I have to work on is systemd. From a quick test it seems that systemd policy changes will be more invasive than is suitable for Squeeze. This means that someone who wants to upgrade from Squeeze to Wheezy+systemd will have to upgrade to Wheeze policy before installing systemd. I think that I will make 0.2.20100524-10 the last version in Unstable based on the 2010 release, I will now start work on packaging the latest upstream policy for Unstable.

PS I’m not much of a PERL programmer, so if anyone has suggestions for how to improve the above PERL code then please let me know. Please note however that I’m not interested in making my code look like line-noise.

[1] http://etbe.coker.com.au/2011/07/22/run-se-linux-policy/

SE Linux on /. The book SE Linux by Example has been reviewed on...
/run and SE Linux Policy Currently Debian/Unstable is going through a transition to using /run...
Context of /dev/xvc0 I have just converted a Fedora Core 5 server to...

Russell Coker (security): /run and SE Linux Policy

etbe — Fri, 22 Jul 2011 13:50:22 +0000

Currently Debian/Unstable is going through a transition to using /run instead of /var/run. Naturally any significant change to the filesystem layout requires matching changes to SE Linux policy. We currently have Debian bug #626720 open about this. Currently the initscripts package breaks selinux-policy-default in Debian/Unstable so that you can’t have initscripts using /run if the SE Linux policy doesn’t support it.

A patch has been suggested to the policy which uses a subst file, basically that causes the SE Linux labeling programs to treat one directory tree the same way as another. The problem with this is that it depends on a libselinux patch that is not in any yet released version of libselinux (and certainly won’t be in a Squeeze update). The upside of such a fix is that it would work for policy that I package as well as custom policy, so if someone wrote custom policy referring to /var/run it would automatically work with /run without any extra effort.

I think that the only way to do this is to just have regular expressions that deal with this in the file contexts. It’s a bit ugly and slows the relabel process down a little (probably no more than about 10%) but it will work – and work on Squeeze as well. One thing I really like to do is to have the SE Linux policy for version X of Debian work with version X+1. This makes upgrades a lot easier for the users. Ideally upgrading a server could be a process that involves separate upgrades of the kernel, the SE Linux policy, and user-space in any particular order – because upgrading everything at once almost guarantees that something will break and it may be difficult to determine the cause.

At this time I’m not sure whether I’ll add a new policy using the subs file before the release of Wheezy (the next stable release of Debian) or just keep using regular expressions. I can have the Wheezy policy depend on a new enough libselinux so it won’t be a problem in that regard (a new upstream version of libselinux with the subst feature should be released soon). In any case I need a back-port to Squeeze to use regular expressions to make an upgrade to Wheezy easier.

I used the above fragment of shell code to change “/var/run” to “/(var/)?run”, “/var/lock” to “/((var/run)|(run)|(var))/lock”, and change “/dev/shm” to “/(var/run)|(run)|(dev))/shm”. It involves a reasonable number of changes to policy (mostly for /var/run), but hopefully this will be acceptable to the release team for inclusion in the next Squeeze update as the changes are relatively simple and obvious and the size of the patch is due to it being generated code.

There is one final complication, Squeeze currently has selinux-policy-default version 2:0.2.20100524-7+squeeze1, but initscripts in Unstable breaks versions <= 2:0.2.20100524-9. So I guess I could submit a proposed version 2:0.2.20100524-9+squeeze1 to the release team to fix this. I would really like to have the Squeeze policy work with initscripts from Unstable or Wheezy.

Any suggestions for how to deal with this?

Update:

I wrote the above before testing the code, and it turned out to not work. I’ve written another post describing a better solution that I have now uploaded to Unstable. I still have to sort something out with an update for Squeeze.

New SE Linux Policy for Squeeze I have just uploaded refpolicy version 0.2.20100524-1 to Unstable. This...
An Update on DKIM Signing and SE Linux Policy In my previous post about DKIM [1] I forgot to...
Debian SSH and SE Linux I have just filed Debian bug report #556644 against the...

Dan Walsh: A new short video starring yours truly available to RHEL subscribers.

dwalsh@redhat.com — Wed, 13 Jul 2011 21:15:44 +0000

New SELinux Features in Red Hat Enterprise Linux 6

The Red Hat Video Team did a great job in attempting to make this old guy look good. :^)

Check it out...

Dan Walsh: New Kiosk OS posted for Fedora 15

dwalsh@redhat.com — Tue, 12 Jul 2011 20:24:55 +0000

Thanks to Miroslav Grepl, he has put together a working Kiosk OS for Fedora 15.

http://people.fedoraproject.org/~dwalsh/SELinux/kiosk/

Name                    Last modified      Size  
Parent Directory                             -   
kiosk.iso               12-Jul-2011 19:51  1.2G  
kiosk.ks                12-Jul-2011 19:46   11K

As you can see the ISO is quite large since we added LibreOffice.

The Kiosk OS was originally written for Fedora 13 and explained in my Blog

http://danwalsh.livejournal.com/35761.html?thread=231345

If you want to make this into a uninterruptable boot you should create the USB or DVD with the

livecd-iso-to-disk --totaltimeout 1 myiso /dev/sdb

man livecd-iso-to-disk

       --totaltimeout
           Adds a bootloader totaltimeout, which indicates how long to wait
           before booting automatically. This is used to force an automatic
           boot. This timeout cannot be canceled by the user. Units are 1/10s.

Meaning the livedvd or liveusb will boot automatically in .1 seconds and can not be stopped.

Russell Coker (security): Multiple Filesystems for Security

etbe — Fri, 08 Jul 2011 13:27:49 +0000

There is always been an ongoing debate about how to assign disk space into multiple partitions. I think that nowadays the best thing to do is to assign about 10G for the root filesystem for every desktop and server system because 10G is a small fraction of the disk space available (even the smallest laptops seem to all have disks larger than 100G nowadays). Even if 10G turns out not to be enough using separate filesystems for /var or /usr provides little benefit now that it’s easy to resize the root filesystem with LVM – and a separate /usr is known to be broken [1].

In a discussion on a private mailing list there was a suggestion that multiple filesystems should be used for security.

DoS Attacks

There are some minor security benefits in having multiple filesystems. If a critical program will fail when there is no free disk space then allowing an unprivileged process to use up all the space on that filesystem is a minor security issue, so having unprivileged processes not being permitted to write to important filesystems is a benefit. But most failures of this type are merely DoS attacks which usually aren’t a big deal – if you can control a local process there are usually lots of other ways of DoSing a system.

Links

Links have been the cause of many security issues in Unix over the years. Using different filesystems for different tasks can prevent the use of hard links in attacks aimed at exploiting race conditions. But even if you prevent hard links there are similar issues with symbolic links. SE Linux is one of many security improvements for Linux which allow restrictions on the creation of hard links. SE Linux also allows restricting the ability of processes to follow symbolic links, so a privileged process can be denied access to follow a sym-link that was created by an unprivileged process.

NFS

The subtree_check option in /etc/exports causes the NFS server to verify that file access is in the correct subtree. So if you export only one subdirectory of a filesystem to a given server then hostile code on that server (or on a network device which impersonates that server) can’t access other subdirectories. This option is documented as having performance implications and working best for filesystems that are mostly read-only, for this reason it’s turned off by default in recent versions of the NFS utilities.

So if you want to NFS export /home then it’s probably a good idea to have /home be on a separate filesystem to prevent attacks on the root filesystem. But of the systems with significant use of /home (IE anything other than accounts used solely for “su -“) most of them have a separate filesystem for /home anyway so this shouldn’t be an issue.

SE Linux

When mounting filesystems with SE Linux there is a “context=” mount option that allows specifying the context for all files on the filesystem. This can save a small amount of storage space for XATTRs and theoretically improve performance (although the difference is unlikely to show up on benchmarks for anything other than fsck). Generally the context mount option is only used for a filesystem that has a huge number of files with the same context, such as a mail spool that uses Maildir, Cyrus, or any of the other formats that involve one file per message. But again such data is generally stored on a separate filesystem for other reasons anyway.

I found one interesting corner case in regard to SE Linux systems mounting files from an NFS server. When an NFS server exports multiple subdirectories of a filesystem mounted on /foo then if one NFS client running SE Linux is to mount two subdirectories of /foo with different contexts then the second mount attempt will give the error “an incorrect mount option was specified”. This is because as of kernel 2.6.18 by default it’s not permitted to mount parts of the same filesystem with different mount options. The option “nosharecache” allows you to use different mount options, but does apparently permit some undesirable behavior in the case of hard links that cross between the subtrees. Thanks to Eric Paris for the tip about nosharecache.

The best example I can think of for which you might want context mount options that differ among files that are used for the same purpose on an NFS mount is a web server which has data files and CGI-BIN scripts. So it seems that a SE Linux web server that mounts it’s data over NFS and is at risk of having hard links between the CGI-BIN directory and the data directory is a corner case in which multiple filesystems is required for security. This seems to be a very unlikely case.

Conclusion

Servers that are deployed in the real world are complex enough that there are always systems with some unusual corner cases demanding configuration choices that aren’t expected. There are some real corner cases for SE Linux where multiple filesystems are compelled for security or for a combination of security and best performance.

But I wouldn’t make a generic recommendation of using lots of filesystems for security. I think that the people who encounter the strange corner cases can usually work out that they need to do something different. So a small number of filesystems seems like a good general aim that doesn’t conflict with security.

[1] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Dan Walsh: Fun with sVirt.

dwalsh@redhat.com — Thu, 07 Jul 2011 22:14:35 +0000

I have been in Washington DC for the last few days talking about SELinux and sVirt, Secure Virtualization.

sVirt is the combining of SELinux with kvm/qemu virtualization. The libvirt daemon launches virtual guests in Red Hat operating systems. Before an virtual machine is started libvirt picks a random MCS label with two categories, like s0:c1,c2 and then labels all of the virtual machines content as svirt_image_t:s0:c1,c2. Then it executes qemu with the label svirt_t:c0:c1,c2.

One of the questions on sVirt I have been asked is how can I test out the sVirt policy, to make sure it works?

I thought about it and I came up with an easy way that someone can play with it.

One of the major goals of a hacker is to get a root shell on the host, lets see what you can do with the root shell running as svirt_t.

Note: the unconfined_t user type is allowed to transition to svirt_t in Fedora 14-16 and RHEL6 I believe.

In order to test the svirt_t, we need a program to run, I copied /bin/sh to /bin/svirt.

# cp /bin/sh /bin/svirt

The policy requires that the entry point for svirt_t must be labeled qemu_exec_t.

# chcon -t qemu_exec_t /bin/svirt

Now I use the runcon command to force a transition from unconfined_t to svirt and pick out an MCS label s0:c1,c2 to run with the svirt shell.

# runcon -t svirt_t -l s0:c1,c2 /bin/svirt
svirt: /root/.bashrc: Permission denied
# id
svirt: child setpgid (6962 to 6962): Permission denied
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:svirt_t:s0:c1,c2
First the shell tried to read /root/.bashrc and was denied. because svirt_t is not allowed to read the admin_home_t label. The shell attempts to setpgid for every command that is executed which SELinux denies svirt_t and prints an error to the screen. I have removed these errors from the blog just for clarity.
# ping 4.2.2.2
svirt: ping: command not found
# cat /etc/shadow
cat: /etc/shadow: Permission denied
# touch /tmp/svirt
# ls -lZ /tmp/svirt
-rw-r--r--. root root unconfined_u:object_r:svirt_tmp_t:s0:c1,c2 /tmp/svirt
Note Notice the touch succeeded, allowing me to create a file in the /tmp directory labeled svirt_tmp_t:s0:c0,c2
# ^D

Now I exit this shell and start another svirt shell with a slightly different MCS label s0:c1,c3

# runcon -t svirt_t -l s0:c1,c3 /bin/svirt
svirt: /root/.bashrc: Permission denied
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:svirt_t:s0:c1,c3
# touch /tmp/svirt
touch: cannot touch `/tmp/svirt': Permission denied

Note: This svirt shell is denied the ability to use the previously created /tmp/svirt file since this file has a label s0:c1,c2 but this svirt shell is running as s0:c1,c3. This would simulate one svirt guest process attacking another svirt_t process.

Have fun with this and see what svirt can do. If you find what you believe to be a vulnerability please report it in bugzilla. If you build a test script with this, we would love to use it.

You will fill your /var/log/audit/audit.log file with audit messages and setroubleshoot will not be happy, but it is pretty good test.

Dan Walsh: Follow up to #7 Does an SELinux Audit Log message always mean something was blocked?

dwalsh@redhat.com — Tue, 28 Jun 2011 11:43:39 +0000

In my previous blog

10 things you probably did not know about SELinux.. #7

I stated that one of the times you can get a syscall to succeed even though AVC's were generated was:

3. An AVC was generated but the syscall still succeeded by going down a different code path within the kernel. This is not that common.

Eric Paris pointed out to me in an email and example of this:

(People have a) " fundemental misconception is the belief that there is a 1-1 mapping between a syscall and an selinux permissions check. SELinux is NOT a syscall filter. We check the security state between objects (aka between a task and a file, or a task and a socket, or a task and task) and the result of that check may or may not cause the intended purpose of the request syscall which triggered this check to fail.

A great example of a syscall which is likely to generate AVCs but still give success=yes is execve(). On execve SELinux will check the permissions between the new task and any file descriptors passed from the parent to the child. Notice the check is not about the syscall, execve(), but between the new task and the file descriptors. If the new task is not allowed to access one of the passed file descriptors we will generate an AVC, and will close the fd and open /dev/null in it's place. This is an example of an alternate code path. The syscall is still going to succeed since we will have resolved the security violation that caused the AVC. It's not common, but other such places exist in the kernel, place where we are able to resolve the security issue by doing some other operation and thus the syscall does not need to fail."

Dan Walsh: 10 things you probably did not know about SELinux.. #7

dwalsh@redhat.com — Fri, 24 Jun 2011 13:42:36 +0000

#7 Does an SELinux Audit Log message always mean something was blocked? NO

First off lets get rid of a misconception. An SELinux AVC message consist of a single message in the audit log.

This is false.

SELinux messages in the Audit log usually consist of more then one record, and they don't even need to contain an AVC record.

SELinux is all about preventing syscalls, so if something gets denied you will usually see an SELinux message describing the AVC, as well as the SYSCALL. If you have full auditing turned on, or the kernel has gathered path information, you could also get a PATH record as part of the overall audit record.

The way to view all the records within an AVC message is to use the ausearch -m avc command.

If you look at the SYSCALL record you will see a Name/Value pair with the name "success". This field indicates whether they SYSCALL record actually succeeded or failed. "success=yes" indicates the syscall was successful.

I can think of 4 different situations where a SELinux message is generated and the SYSCALL record returns success=yes.

The system is in permissive, meaning AVC's are recorded but not enforced.

> getenforce
Permissive

The process that caused the domain is a permissive domain (Latest Fedoras/RHEL6 only). The AVC for this process type is not enforced.

> seinfo --permissive |grep SOURCETYPE

An AVC was generated but the syscall still succeeded by going down a different code path within the kernel. This is not that common.
An auditallow record was added to the policy. auditallow says to the kernel, generate an audit SYSCALL message any time this access is granted. Currently we do this with load_policy and setting booleans, setenforce.

type=SYSCALL msg=audit(06/23/2011 13:33:58.044:280) : arch=x86_64 syscall=write success=yes exit=1 a0=3 a1=7fff406c5ce0 a2=1 a3=0 items=0 ppid=4408 pid=4546 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=4 comm=setenforce exe=/usr/sbin/setenforce subj=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 key=(null) type=MAC_STATUS msg=audit(06/23/2011 13:33:58.044:280) : enforcing=1 old_enforcing=0 auid=dwalsh ses=4

Thomas Biege (Security): SUSE Manager Security Update

Thomas (noreply@blogger.com) — Tue, 21 Jun 2011 01:38:04 +0000

Last Friday we released a security update for SUSE Manager. It eliminates four vulnerabilities which I will describe in detail here:

CSRF (CVE-2009-4139): This is the most dangerous issue fixed by this update. It was found during a penetration-test executed by me before we released the SUSE Manager. You may wonder why we released the fix after the "gold master" (GM) and why it has a CVE-ID from 2009. Red Hat was informed about this issue in 2009 already (by another person) and after some back and forth we decided to release it together with Red Hat and not earlier. But not only the release date was coordinated, we also coordinate fixing and testing.
The default SSL ciphersuite configuration that comes with our apache2 package (this also affects the SM proxy) was made up to support as much and as old client as possible. This results in a config that is insecure because it support "export ciphers", SSLv2, short keys, etc. If you install this update before you configured your SM you will have a up-to-date and secure config. Use sslscan to verify your setup. If it is still insecure go to /etc/apache2/ssl-global.conf and change it to something like:
ssl_protocols TLSv1
ssl_ciphers ALL:!aNULL:!eNULL:!SSLv2:!LOW:!EXP:!MD5:@STRENGTH
Open Redirect (CVE-2011-1594): A hidden field named "url_bounce" allows HTTP redirects and therefore phishing attacks. Found during penetration-test, released after GM because it was too minor to hold release.
XML remote denial of service (CVE-2011-1755): jabber2 server can be dos'ed ("billion laughs attack"), not found by us.

kostenloser Counter

Dan Walsh: SELinux Policy RPM in Rawhide/F16 includes prebuilt policy file.

dwalsh@redhat.com — Thu, 16 Jun 2011 17:27:16 +0000

The selinux-policy-TYPE packages has always rebuilt the policy in their post install. We do this in order to merge any customizations to the policy that an administrator might have made. The selinux policy rpm package also needs to rebuild the policy if any policies were installed by other rpms or by the administrator.

Over time as the size of policy has grown and gotten more complex, the installation procedure has required more memory and more time. We have seen stats stating during installations, one of the biggest memory hogs was the selinux-policy-targeted package.

Over the last couple of weeks, I decided to re-examine the situation.

The selinux-policy-TYPE packages will now ship with a pre-built policy package and will only rebuild the policy iff the existing policy has been customized.

The following test shows a 4 times speedup on installing the package 48 Seconds -> 12 Seconds. And max Memory Usage from 38 M to 6 Meg.

Modified:
# time -v rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force
Preparing...                ########################################### [100%]
   1:selinux-policy-targeted########################################### [100%]
    Command being timed: "rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force"
<snip>
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:48.11
<snip>
    Maximum resident set size (kbytes): 377608
<snip>

Unmodified:
# time -v rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force
Preparing...                ########################################### [100%]
   1:selinux-policy-targeted########################################### [100%]
    Command being timed: "rpm -Uhv /home/devel/dwalsh/sources/RPMS/noarch/selinux-policy-targeted-3.9.16-29.1.fc16.noarch.rpm --force"
<snip>
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:12.32
<snip>
    Maximum resident set size (kbytes): 60112
<snip>

You will only see this improvement on a fresh install. And should continue to see it on all updates, although updates can still do a partial relabel after install.

If you are doing an update and would like to see the improvement, you can do the following.

# setenforce 0
# rm -rf /etc/selinux/targeted
# yum -y reinstall selinux-policy selinux-policy-targeted
# restorecon -R -v /etc/selinux/targeted
# setenforce 1

Then you would be seen as a fresh install.

Try it out.

James Morris: Linux Security Summit 2011 – Schedule Published

jamesm — Wed, 15 Jun 2011 15:33:02 +0000

For those that didn’t catch the email announcement, the schedule for the 2011 Linux Security Summit is now published.

The format of the conference is refereed talk sessions, followed by in-depth roundtable discussions.

Here’s a summary of the programme:

Refereed talks:

“Smack is Alive and Well”
Casey Schaufler

“MeeGo Security Update”
Ryan Ware, Intel

“An Overview of the Linux Integrity Subsystem: Use Cases and Demonstration”
David Safford and Mimi Zohar, IBM

“Digital Signature support for IMA/EVM”
Dmitry Kasatkin and Ryan Ware, Intel

“Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM”
Peter Kruus, The Johns Hopkins University Applied Physics Laboratory

“Efficient, TPM-free system integrity checking with device mapper: dm-verity”
Will Drewry and Mandeep Baines, Google

Roundtable discussions:

Kernel Hardening
Lead by Kees Cook, Canonical and Will Drewry, Google

LSM Architecture
Lead by Kees Cook, Canonical and Casey Schaufler

See the full schedule for more detail.

Attendance is open to all registered attendees of the Linux Plumbers Conference. Early-bird registration is available for LPC until the end of today (US time).

Dan Walsh: 10 things you probably did not know about SELinux.. #6

dwalsh@redhat.com — Fri, 10 Jun 2011 18:52:19 +0000

#6 How did those SELinux labels get there?

SELinux labels are placed on disk during the installation by a combination of Anaconda and rpm. Anaconda actually includes the latest /etc/selinux/targeted/files/file_context and /etc/selinux/targeted/policy/policy.26 in its initrd. When anaconda starts rpm, rpm reads this file and proceeds to place the labels on disk. RPM has SELinux awareness built into it and asks the kernel to place the default label on the disk for every object that it creates from its payload. If an rpm post install script runs during the install, the labels are created using the standard process labelling described below. Any file system objects created by Anaconda before loading the policy into the kernel will be relabelled by Anaconda using restorecon.

Any file system objects created by the post install scripts, or during boot, or by any process from then moving forward will create the file via one of the following three rules.

The object will get the label of the parent directory.
- Files/Directories created in /etc, which is labelled etc_t, will get labelled etc_t by default.
File transition rules can be written into policy. File transition rules take into account the label of the process creating the file as well as the parent directory. For example I can write a rule that says if NetworkManager_t creates a file in a directory labelled etc_t then this file will be labelled net_conf_t
- filetrans_pattern(NetworkManager_t, etc_t, net_conf_t, file)
- When NetworkManager creates the /etc/resolv.conf file it gets labelled net_conf_f rather then etc_t.
- Since you can only have one combination of ProcessLabel/DirectoryLabel/ObjectClass, you can not currently write a rule for a process to create two different labels within the same directory.
The last way is to build SELinux awareness within an application.
- Applications can be programmed to ask the kernel to create a file system object with a particular label.
  - rpm, udev, passwd are examples of applications that request the kernel to label the object at creation time.
- Applications can attempt to change a label from one label to another.
  - restorecon, udev, restorecond, chcon are examples of applications that modify labels.

In Fedora 16 we are introducing a new concept which we are calling File Name Transitions. These will allow policy writers to take into account the actual file name (Not path) at file creation time, giving us the ability to clear up some common bugs users have seen with SELinux.

Read about it here and if you are running Fedora 16/Rawhide try it out...

https://fedoraproject.org/wiki/Features/SELinuxFileNameTransition

Thomas Biege (Security): SAD 4: Security Day

Thomas (noreply@blogger.com) — Tue, 24 May 2011 12:14:00 +0000

Three weeks ago the SUSE Studio team had its first "Security Day" to fix the possible security vulnerabilities found by ror-sec-scanner. (a Rails static code analyzer)
The team eliminated:

161 false positives
28 real bugs

Thank you folks! :-)

Note: Earlier this year another team consolidated its forces to fix potential security problems in their code and reduced the number of bugs per KLOC to 0.

I hope we can have a "Security Day" prior every new release.

kostenloser Counter

James Morris: Linux Security Summit 2011 – CFP closes in one week.

jamesm — Fri, 20 May 2011 22:48:01 +0000

We’ve had a couple of queries about what to submit for the Linux Security Summit CFP.

Proposals should be plain text abstracts up to 150 words in length, and emailed to the program committee: lss-pc (_at_) ext.namei.org

Also see the CFP section on the wiki.

KaiGai Kohei: [OSS/Linux] Leaky VIEW まとめ

kaigai — Sun, 15 May 2011 13:40:03 +0000

SELinuxとは関係のない、RDBMSでのセキュリティのお話。

利用者に対して、テーブルに対する直接のアクセス権を与えず、特定のビューを通してだけアクセスを許可するのは、行レベルのアクセス制御でよく使われるテクニックである。

つまり、ビューは不可視であるタプルをフィルタリングする役割を持つ。

しかし、これで万全かというと、そうではない。

クエリ最適化を上手く利用することで、利用者が見えないはずのタプルを参照する事は可能である。

以下の例を見て頂きたい。

postgres=# CREATE TABLE T1 (id int, name text);
CREATE TABLE
postgres=# CREATE TABLE T2 (id int, cred text);
CREATE TABLE
postgres=# INSERT INTO t1 VALUES (1, 'coke'), (2, 'soda'),
                                 (3, 'juice'), (4, 'fanta');
INSERT 0 4
postgres=# INSERT INTO t2 VALUES (1, 'public'), (2, 'hidden'),
                                 (3, 'hidden'), (4, 'public');
INSERT 0 4
postgres=# CREATE VIEW v1 AS SELECT * FROM t1 NATURAL JOIN t2
                                      WHERE t2.cred = 'public';
CREATE VIEW
postgres=# SELECT * FROM v1;
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

postgres=# GRANT SELECT ON v1 TO alice;
GRANT

ビュー v1 は、テーブル t1 と t2 を JOINし、ここでは t2.cred = 'public' が行レベルのセキュリティポリシー、すなわち、フィルタリング対象の行を定めるものとする。

ユーザ alice は t1 と t2 へのアクセス権を持っていないため、ビュー v1 を通してしか、これらの情報にアクセスできないはずである。

だがしかし、以下のクエリの実行結果を見てもらいたい。

postgres=> SELECT getpgusername();
 getpgusername
---------------
 alice
(1 row)

postgres=> SELECT * FROM t1;
ERROR:  permission denied for relation t1
postgres=> SELECT * FROM t2;
ERROR:  permission denied for relation t2
postgres=> SELECT * FROM v1;
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

上記の結果は想定通りだろう。

では、続いて、WHERE句にユーザ定義関数を付加する。

この関数は、常に true を返すが、引数を利用者のコンソールに出力する。

postgres=> CREATE OR REPLACE FUNCTION f_leak(text)
               RETURNS bool LANGUAGE 'plpgsql'
               AS 'BEGIN
                       raise notice ''f_lead: (%)'', $1;
                       RETURN true;
                   END';
CREATE FUNCTION
postgres=> SELECT * FROM v1 WHERE f_leak(name);
NOTICE:  f_lead: (coke)
NOTICE:  f_lead: (soda)
NOTICE:  f_lead: (juice)
NOTICE:  f_lead: (fanta)
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

結果セットは２行だが、利用者コンソールには見えてはならないはずのタプルの内容が出力されている。

その理由はEXPLAIN分の出力を見ると明らかである。

postgres=> EXPLAIN SELECT * FROM v1 WHERE f_leak(name);
                           QUERY PLAN
----------------------------------------------------------------
 Hash Join  (cost=25.45..356.91 rows=12 width=68)
   Hash Cond: (t1.id = t2.id)
   ->  Seq Scan on t1  (cost=0.00..329.80 rows=410 width=36)
         Filter: f_leak(name)
   ->  Hash  (cost=25.38..25.38 rows=6 width=36)
         ->  Seq Scan on t2  (cost=0.00..25.38 rows=6 width=36)
               Filter: (cred = 'public'::text)
(7 rows)

f_leak()関数を探してみると、Join-Loopの内側で t1 テーブルを読み出す際のフィルタリング条件として実行されている事がわかる。

これは、f_leak()の引数が t1 由来のデータだけを参照しているため、Joinすべき行数を減らすために、本来実行されるべき位置（t1.id = t2.id を評価した後）からオプティマイザによって移動させられた事による。

とは言え、この手の最適化を行わなければビューを介したアクセスは極端に性能が悪くなるはずなので、問題は PostgreSQL に限った話ではないと思われる。

例えば、100万件のタプルを持つテーブルでID列にインデックスが張られており、処理コストの比較的高い f_policy() 関数によってフィルタリングを行うビューを介してアクセスするとする。その場合、ビューの外から ID = 1234 という条件が来た場合に常に全件スキャンが走るようなら、泣ける。

手元にOracleの環境がある友人に試してもらったところ、同様に、見えないはずのタプルの内容を出力できるそうな。

なお、PostgreSQLには、セキュリティポリシーの適用されている t2 の内容を見る方法もある。*1

以下のような関数を定義する。ポイントは COST=0.0001 の部分。

postgres=> CREATE OR REPLACE FUNCTION f_leak(text)
               RETURNS bool LANGUAGE 'plpgsql'
               COST 0.0001
               AS 'BEGIN
                       raise notice ''f_lead: (%)'', $1;
                       RETURN true;
                   END';
CREATE FUNCTION

今度は f_leak() 関数で t2 の情報を参照するようにすると、同様にフィルタリングされているはずの行の内容が出力される。

postgres=> SELECT * FROM v1 WHERE f_leak(cred);
NOTICE:  f_lead: (public)
NOTICE:  f_lead: (hidden)
NOTICE:  f_lead: (hidden)
NOTICE:  f_lead: (public)
 id | name  |  cred
----+-------+--------
  1 | coke  | public
  4 | fanta | public
(2 rows)

EXPLAIN文の結果

postgres=> EXPLAIN SELECT * FROM v1 WHERE f_leak(cred);
                            QUERY PLAN
------------------------------------------------------------------
 Hash Join  (cost=25.40..52.43 rows=12 width=68)
   Hash Cond: (t1.id = t2.id)
   ->  Seq Scan on t1  (cost=0.00..22.30 rows=1230 width=36)
   ->  Hash  (cost=25.38..25.38 rows=2 width=36)
         ->  Seq Scan on t2  (cost=0.00..25.38 rows=2 width=36)
               Filter: (f_leak(cred) AND (cred = 'public'::text))
(6 rows)

今度は、f_leak()がt2のScan-Loopに結合されているが、注目すべきはその順序。

f_leak()のコスト値を低く設定したために、複数のフィルタリング条件がScan-Loopに結合している場合、f_leak()が cred = 'public' よりも優先されている。

後者のシナリオは、何もJoinを伴わない場合でも実行可能である。

この問題は、既に開発者の中では既知の問題で、利用者から特定のタプルを不可視にする目的でビューを使うべきでない事が明記されている。

http://www.postgresql.jp/document/current/html/rules-privileges.html

5/18にオタワで開催される PostgreSQL Developer Meeting では、この問題を議論するつもりである。

一応、解決策の腹案は持っているが、そこまで踏み込まないにしても、先ずはこの辺のシナリオが『解決すべき課題である』というコンセンサス形成あたりを目標としたい。

*1：PostgreSQL固有というのは、他のRDBMSでユーザ定義関数のコストを指定する手段があるかどうか不明のため。

James Morris: Linux Security Summit 2011 – CFP reminder: 2 weeks!

jamesm — Fri, 13 May 2011 02:29:13 +0000

Calling all Linux security folk!

Just a reminder that the CFP for the 2011 Linux Security Summit closes on the 27th of May — two weeks away. Please get your submissions in soon.

Note again that we are co-located with the Linux Plumbers Conference in Santa Rosa, and that all Security Summit attendees, including speakers, will need to register for Plumbers. Earlybird registration is available until 31st May.

Trivia question: which Alfred Hitchcock film was shot on location in Santa Rosa in 1943?

(Hint: click on the image)

Thomas Biege (Security): SAD 3: At the Beginning there was a Thought

Thomas (noreply@blogger.com) — Wed, 04 May 2011 02:43:04 +0000

Last night I stumbled over some old docs of the Security Review Board. More than 5 years ago T.G. puts much effort in enhancing the development processes to create more secure products. I never saw numbers about that project to compare pre and past states of the products. Unfortunately she left a few years later but AFAIK some of her work is still in use today.

Today I browsed Google Docs and found a 2 year old presentation I wrote during a train journey from Nuremberg to my home town. I never want to show the slides to other people I just brainstormed about how we could integrate security into our products. Let me show you some slides here because they describe where we were 2-3 years ago. As I said I forgot the slides but funnily various things from them are real now or are on my TODO list.

Slide 1: Where we are.
- We have four different sources of code
-- 1.) Mainly FLOSS
-- 2.) In-house development
-- 3.) 3rd-party commercial free binary code (like RealPlayer, acroread, etc.)
-- 4.) 3rd-party code developed by contractors
- We review FLOSS code but there is too much and we have not much
influence on the developers beside sending patches upstream
- We have much influence on our own developers but we have to develop
a better security awareness as well as technical knowledge
- We have no influence on the 3rd-party free binary code and just need
to trust it.
- Code developed by contractors can be reviewed by us

Today source 1. is still the main source for code contributions, the in-house development (2.) increases a lot over the past years, we try to reduce (openSUSE is completely free of them, see the NonFree repo) the number of binary-only packages (3.), I am not aware of current contributions from source 4.
In the past we provided workshops for secure programming (C, C++, Shell, Perl, Ruby on Rails, Web-security in general).

Slide 2: Where others are.
- Microsoft
-- founder of the Secure Software development Life Cycle (SDL)
-- Separate, specialized teams
-- Own and optimized tools for stress-testing (fuzzing) as well as code analysis
-- See BSIMM study [1], [2]
- Cisco
-- CMSDL
- Adobe
-- See BSIMM study [1], [2]
- Google
-- specialists/teams working on research topics and develop tools as well as guidelines
-- See BSIMM study [1], [2]
- Red Hat
-- Specialized teams/persons
-- Much more people working on security
-- Better contact to developers?
-- Only re-active not pro-active AFAIK

Currently we are introducing secure SDLC techniques and testing tools for our in-house products. Teams are planned to grow.

Slide 3: We need to catch up because...
- Releasing patches for avoidable bugs is a big waste of money and time
- Customers critically watch software vendor's product quality and security vulnerabilities
- These observations play a big role in buying new products or continuing support contracts because installing patches costs the customer money (see study "The Total Cost of Security Patch Management") and therefore increases the cost of the product.

Slide 4: What we can do now!
- Increase awareness by:
-- Showing consequences by providing examples of security problems in our code
- Increase code quality by:
-- Online teaching of security best practice rules for common programming languages like C, C++, C# and Java (see CERT's SDI)
-- Adopt secure SDLC processes for our in-house development
-- Provide a standard development environment that includes easy-to-use code analysis tools for our programmers
-- Teach how to use this tools.
-- Do more sophisticated code analysis

We are on the right track.

Slide 5: What we need to do in the future.
- Develop/acquire better tools for code analysis, fuzzing, etc.
- Incrementally refine our coding standards
- Have separate teams for handling bugs (response team), create new tools and keep track of current software security development (research team), a team for shepherding code development (mentor team) and a pen-testing team to verify in-house, FLOSS code
- Being part of secure development initiatives/groups/workshops

Well different teams is a dream that will never become true, but we will try to reach our goals using another way.

Slide 6: Where we should be.

kostenloser Counter

Russell Coker (security): What is Valid SE Linux Policy?

etbe — Thu, 28 Apr 2011 21:00:18 +0000

Guido Trentalancia started an interesting discussion on the SE Linux policy development list about how to manage the evolution of the policy [1].

The Problem

The SE Linux policy is the set of rules that determine what access is granted. It assigns types to files and domains to processes and has a set of rules that specify all the permitted interactions between processes and files (among many other things). The policy evolves over time to match the requirements of programs (applications and daemons). As a program evolves the things that it does will change and the SE Linux policy will tend to evolve to permit the set of all operations that were requested by all versions because people only complain when things stop working not when excessive privilege is granted. So we need to periodically remove old allow rules from the policy.

One difficulty in this regard is the fact that multiple versions of programs are often available for use at the same time. Debian in particular has a good history of providing separate packages for the old and new versions of programs such as Apache to meet the needs of users who want the tried and tested version and of users who want the newer version with better performance, more features, better documentation, or something else good. There is also a demand to have the same policy work with multiple versions of a distribution without excessive effort. Finally all the distributions that have SE Linux support have different people deciding when the new version of a daemon is ready for inclusion and therefore there is a need to support multiple versions for multiple distributions. So support for older versions of daemons can’t be removed easily.

One of the things I do to make these things a little easier to manage is to put ifdef(`distro_debian', ` before any Debian specific bits of policy. When policy is conditional and only used in Debian I can freely remove it at any future time if Debian works well without it. Also it doesn’t matter if such Debian specific policy allows access that is not needed or desired in other distributions, the only down-side to this is that sometimes other distributions need to repeat work that I did, they determine what access is needed for their configuration and discover that it was already enabled for Debian.

What is Valid Policy?

We went to only have “Valid Policy” (as described by Christopher J. PeBenito), so the challenge is determining what is Valid Policy.

It seems to me that there are three type of access granted by valid policy (it is debatable whether type #3 is valid):

Access that is needed for an application to perform it’s minimal designed task.
Access that is needed for the application to perform all the optional configurations, EG an ftpd running from inetd or as a daemon, and daemons like http server being granted access to ssl keys or not.
Access that is needed to perform all the operations the application requests, but which the application doesn’t require or shouldn’t require if it worked correctly.

Some common operations that aren’t required include opening utmp for write, searching /root, and many other relatively innocuous access attempts which don’t affect the program operation if they are denied. There are also many things such as writing temporary files to /root that don’t seem unusual if the application developer is not considering SE Linux (but which are often considered bad practice anyway). Some of these things (like using /root for stuff that belongs in /var/lib) have the potential to break things (for the daemon or for other system processes) even if you don’t consider SE Linux.

How to deal with those types:

In most cases this can be determined without too much effort. For example a web server needs to listen on port 80 and read files and directories that relate to data. When writing policy I can write a lot of the allow rules without even testing the application because I know from the design what it will do. A large part of the other access is obvious in a “I can’t believe I didn’t realise it would need this” sense.
The main question here is whether we have booleans (settings which can be tuned at run-time by the sysadmin which determine how the policy works) to specify which optional tasks or whether we allow all access for optional configurations by default. The secondary question is when certain unusual corner cases should be not supported at all such that the people who do such unusual corner cases need to use audit2allow to generate local policy to allow their operations.
Sometimes we have to allow things that we really don’t like. Even when we write policy to allow a daemon to do unusual things (such as using /root instead of /var/lib) it’s still a lot better than running without SE Linux. Also SE Linux policy to allow such obviously broken things stands out and is a constant reminder that the daemon needs fixing, this is better than allowing symptoms of broken design to be forgotten.

How to Improve the Situation

We could have comments in the policy source for everything that is in category 3. If the comments had a fixed format so that a recursive grep could find them all then it would allow us to more easily remove the gross things from the policy at a later date.

But it seems to me that the main problem is a lack of people working on this. I am not aware of any people actively testing Debian policy for excessive privilege in regard to such issues.

[1] http://oss.tresys.com/pipermail/refpolicy/2011-March/004115.html

Dan Walsh: 10 things you probably did not know about SELinux.. #5

dwalsh@redhat.com — Thu, 14 Apr 2011 15:10:55 +0000

#5 How do I add new file systems/disks to an SELinux machine?

Lets examine three use cases:

1: You just got back from Best Buy with a brand new 100 Gig Disk that you want to mount on /home and store your homedirs. You add the disk mount to /etc/fstab, mount it untar your entire backed up directory to the disk. Now you attempt to login with a confined user. Login fails, and the audit logs fill up with AVC messages concerning file_t. Even without confined logins, applications like sshd can't read the ~/.ssh directory and Apache can no longer read the ~/public_html directory.

SELinux reporting errors with the type file_t indicates that the file/dir has no label. SELinux has no idea what content is stored in a file without a label, therfore the kernel denies confined applications access to these files. Ordinarily when I have seen random files all over the disk labelled file_t, I have told the user to relabel the entire machine. touch /.autorelabel; reboot In this case we know the user just added a disk, so all he needs to do is run restorecon on the disk. restorecon -R -v /home. The restorecon command will put the default labels on the entire disk. This also works on disks that you moved from one machine to another, especially important if the machine had SELinux disabled.

2. You add a new lvm mount that you want to store all of your postgresql database directory on. You create a new directory tree /data/postgresqldb and mount the disk here and mount the directory on /data/pgsql.    You are an advanced SELinux user so you know you need to put labels down, you run "restorecon -R -v /data/pgsql". Now you service postgresql start, and POW it blows up. The setroubleshoot star shows up and you read the analysys. The analysys tells you that postgresql is trying to access a file in a directory labeled default_t. Newly created directories in / are labelled default_t. Just like file_t, the SELinux kernel does not know what content is stored in a file/directory labeled default_t, so all confined applications are blocked from reading default_t files/directories. The setroubleshoot analysis also tells you you need to put a label on the directory, and choose from a list of labels including postgresql_db_t. You figure that looks good and you follow the instructions,

# semanage fcontext -a -t postgresql_db_t '/data/pgsql(/.*)?'
# restorecon -R -v /data/pgsql

The semanage command tells the SELinux system what the default label for this directory will be going forward. The restorecon command actually puts the labels on the disk.

Now you service postgresql start, and POW it blows up again. At this point you are real unhappy with SELinux. This time the AVC's indicate that postgresql_t is not able to search through the /data directory which is labelled default_t. Your labelling was added at a directory a level below what you needed.

# semanage fcontext -d '/data/pgsql(/.*)?'
# semanage fcontext -a -t postgresql_db_t '/data(/.*)?'
# restorecon -R -v /data

I am sorry we blew it on this, but hopefully this example will help you understand a little of what SELinux is doing.

# service postgresql start

It works!!!

Now you can take the pins out of the voodoo doll of me.

NOTE: If you were to store the postgresql database in a subdirectory of a normal file system directory, DO NOT change the label of that directory.
For example /home/postgesql.

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

Would thoroughly screw up your machine. In this case it is better to do

# semanage fcontext -a -t postgresql_db_t '/home/pgsql(/.*)?'
# restorecon -R -v /home/pgsql
Then add allow rules for posqgresql_t to search through home_root_t using

#grep postgresql_t /var/log/audit/audit.log | audit2allow -M mypostgresql
# semodule -i mypostgresql.pp
3. You want to share Apache data on an NFS share using multiple httpd hosts.   You mount the remove nfs directory at /var/www/.

# service httpd start
It blows up permission denied. This time setroubleshoot is complaining about httpd_t trying to read nfs_t. The analysis tells you that you can allow httpd_t to read all nfs_t by setting a couple of different booleans.

httpd_use_nfs or use_nfs_home_dirs

Since you are not using nfs for your home directories, it would be a bad idea from a security point of view to turn this boolean on.  The use_nfs_home_dirs boolean allows any confined domains that need access to home directory content to get access to all files labeled nfs_t.

Turning on httpd_use_nfs will solve your problem.
But what if you had other nfs shares mounted which you did not want to grant access to Apache?

The third option would be to use a mount option.

# mount -o context="system_u:object_r:httpd_sys_content_t:s0" REMOTEHOST:/var/www /var/www

This command tells the SELinux kernel to treat all content in this file system as httpd_sys_content_t. httpd_t will be allowed to access the content mounted as httpd_sys_content_t, but the kernel will still deny httpd_t access to other NFS file systems mounted on the system.

James Morris: Linux Security Summit 2011 (Santa Rosa) – CFP Open

jamesm — Mon, 04 Apr 2011 09:07:19 +0000

The 2011 Linux Security Summit has been announced, and the CFP is open until the 27th of May.

Following last year’s successful event in Boston, the 2011 Linux Security Summit (LSS2011) will be held on the 8th of September this year in conjunction with the Linux Plumbers Conference.

The program committee is looking for submissions from developers, researchers, and implementors.

If you’ve done anything interesting in Linux security over the last year, it’s time to get a proposal ready and send it in!

Dan Walsh: I will be presenting SELinux at Boston Securty Meetup Tonight.

dwalsh@redhat.com — Thu, 31 Mar 2011 11:57:14 +0000

http://www.meetup.com/boston-security-meetup/events/16738054/

Dan Walsh: 10 things you probably did not know about SELinux.. #4

dwalsh@redhat.com — Fri, 25 Mar 2011 12:59:24 +0000

#4 How do I tell whether a domain is confined on an SELinux System?

On SELinux targeted systems, we have confined domains and unconfined domains, and as of RHEL6 and all supported Fedoras we also have permissive domains. SELinux does not block access on processes running in these domains, for the most part.

Unconfined Domains

An unconfined domain is supposed to be a process that has the same rights as it would if SELinux was disabled. There are a few caveats to this though.

Process Transitions

A process transition says when process running as label a_t executes a file labeled b_exec_t it should execute the process as b_t An example of this would be service httpd start. In this case we have unconfined_t running an init script labeled initrc_exec_t and SELinux starts the process as initrc_t.

# sesearch -T -s unconfined_t -t initrc_exec_t
Found 1 semantic te rules:
type_transition unconfined_t initrc_exec_t : process initrc_t;

Then the init script has a rule that says initrc_t executing httpd_exec_t will transition to httpd_t

# sesearch -T -s initrc_t -t httpd_exec_t
Found 1 semantic te rules:
type_transition initrc_t httpd_exec_t : process httpd_t;

This means that even though the process that started another process was unconfined, the new process can be confined. We tend to discourage transitions from the unconfined_t user domain, since this can surprise the user. "I thought I was unconfined, why when I start XYZ does SELinux block it?"

Other then transitioning to initrc_t there are currently 55 executables that transition out of the unconfined_t domain.

# sesearch -T -s unconfined_t -c process -C| grep -v initrc_t| grep -v ^D | wc -l
55

A lot of these domains are also unconfined. unconfined_java_t for example is the same as unconfined_t except it has execstack and execmem privilege always.

Minor Denials

In some cases I have been convinced to add minor confinement to even unconfined domains. The most seen one of these was the executable memory checks. execmem, execmod, execheap and execstack. There are booleans to turn on and off the checks for the unconfined domains.

Listing unconfined domains

You can use seinfo to list the unconfined domains.

# seinfo -aunconfined_domain_type -x | wc -l
54

Disabling unconfined domains

You can easily disable lots of domains unconfined domains to make your machine more locked down. In RHEL6 and Fedora their are two policy modules unconfined and unconfineduser. If you disable unconfined it will lock down most of system space.

# semodule -d unconfined
# seinfo -aunconfined_domain_type -x | wc -l
14

This is how I usually run. In this mode, it will require you to have policy for all apps launched out of init system or xinetd.

You can also disable the unconfined user, by executing the following commands.

# semanage login -m -s staff_u root
# semanage login -m -s staff_u __default__
# semanage user -d unconfined_u
# semanage user -m -R "staff_r system_r sysadm_r" staff_u
# semodule -d unconfineduser

As long as unconfined is not defined in either the semanage user or semanage login database this should work and you pretty much get back to what used to be strict policy.

I tend to leave unconfineduser enabled, but setup all my users as confined, and allow staff_t to transition to unconfined_t through sudo.

Adding unconfined domains to when building policy modules

If you were building your own policy module and you wanted to build an unconfined domain, you would write code like:

type mydomian_t;
domain_type(mydomain_t)

optional_policy(`
          unconfined_domain(mydomain_t)
')

Permissive Domains

The other type of domain that SELinux does not block is the permissive domain.    These are usually domains under construction. SELinux allows these domains to do any thing but reports AVC;s on them when they do something not allowed in policy. When we develop policy for Fedora, we define all new domains as permissive and allow them to run permissive through an entire run of a release. Then in the next release we turn them to enforcing. One difference between F15 and F16 policy is we just removed the permissive flag from all domains in F15.

Listing Permissive Domains

You can see the permissive domains in two ways.

# seinfo --permissive | wc -l
18

Or you can use the semanage command to list them

# semanage permissive -l

Builtin Permissive Types

staff_gkeyringd_t
staff_gkeyringd_t
mock_t
keyboardd_t
matahari_serviced_t
firewalld_t
colord_t
systemd_notify_t
systemd_passwd_agent_t
mozilla_plugin_t
matahari_hostd_t
matahari_netd_t
passenger_t
systemd_tmpfiles_t
foghorn_t
namespace_init_t

Customized Permissive Types

qpidd_t

Adding Permissive Domains

Notice that the semanage command differentiates between customized permissive domains and built-ins. With the semanage command, the administrator can choose to make a domain permissive, by executing

# semanage permissive -a httpd_t
# seinfo --permissive |grep http
   httpd_t

Removing Permissive Domains

You can remove a customized permissive domain by executing:

# semanage permissive -d httpd_t

You can not currently remove permissive domains if they are the built-in into policy.

Adding permissive domains to when building policy modules

If you were building your own policy module and you wanted to build a permissive domain, you would write code like:

type mydomian_t;
domain_type(mydomain_t)

permissive mydomain_t;

Thomas Biege (Security): SAD 2: Security Awareness or melting Realities together

Thomas (noreply@blogger.com) — Fri, 25 Mar 2011 06:36:23 +0000

Most people know that smoking causes cancer, that eating too much and not doing sports increases the probability of a cardiovascular disease, that drinking too much is bad for your psyche and lever and so on.

But does just knowing about it change their behavior? No, it does not!

The reason is that these "invisible" negative effects do not influence their living, the integrity of their reality is intact until it is too late and the disease dramatically decrease the quality of their life.

Only a few people are clever and strong enough to reflect about their bad behaviors and change them. I assume more people change their bad habits as soon as they see what happens to their body. Seeing means measuring the cardiovascular levels, taking x-ray pictures of organs, making chemical analysis of body liquids and tissue and so on.

I see a strong analogy here to software development and security.

Developers and project-managers often do not have security in mind, or do not have the technical background and daily practice to make the resulting product a nightmare for penetration-testers and hackers. (How often do you read this already?)

Let's not stress this doctor vs. patient analogy too far. This blog entry is not about good vs. bad or dumb vs. clever... it's about the experience I made and psychology.

First of all, measurement (of the right things) is the key to success! You do not have to create a bulletproof plan, just some goals, continue measurement, and adapt your plan (Hello agile development/management!).

I hold three talks/workshops in 2010, every talk has the same topic: "secure design and development" and I got the same result: Code quality did not increase! The number of potential security bugs per 1000 "physical" LOC (Hits/KSLOC) stayed the same or even increased.
Based on the responses from my audience I experimented with the content and with the methodology. The first workshop was very long and mostly theoretical with threat models, potential problems in Rails, risk assessment, showing some tools (which gets the most attention, because it potentially helped solving their problems).
The second one was much more practical, I had shown real examples from the in-house software projects, real attacks and presenting some tools. The session was much shorter and caused more attention by the developers and a bit more attention by the technical managers (Still, tools caused the the most attention). And the last one... the last one was a wake-up call, less technical, analogies and examples, cost of security updates (Attention!) and I hit the target.

Result: The first talk was a waste of time, my statistics had shown no decrease in the potential vulnerabilities, the second one also had no affect on quality but the awareness and communication (developers) increased, and the third talk... well the code quality did not increase but awareness and maybe acceptance in the upper food chain increased.

Retrospectively I can say I should have done the talks/workshops in reverse order but when I started is was a "fire-fighter job" and I had no time for a real plan.

Code quality is still a critical issue and therefore I took the next, more aggressive step by sending the (cleaned-up) results of my code scanner to the developers mailing list. And at least one team responded to it and we reduced the number of potential security problems and false positives to a minimum within just two weeks. In the meanwhile all teams responded in some way and I hope code fixing will start soon.

On balance:

If you want to increase awareness, invite the right people and omit technical details, speak the language of the audience, use numbers (costs) and statistics, use analogies instead of theoretical information. Melt realities by creating feelings and concernment! (The last point is not easy to do of course.)
If you want to increase code quality, use tools that directly show the problematic code with a description and help fixing it! Don't create too much confusion and don't steal the developer's time.

BTW, the increase of awareness or the expertise of the developers resulted in adding security features and fixing existing security features...

kostenloser Counter

Dan Walsh: 10 things you probably did not know about SELinux.. #3

dwalsh@redhat.com — Thu, 24 Mar 2011 16:04:06 +0000

SELInux versus nsswitch.conf

Many confined domains call getpwnam, getpwuid, getpwent functions. Traditionally these function calls just read the the /etc/passwd file. In a modern Linux system the glibc has added nsswitch.

man nssswitch.conf
...
NAME
       nsswitch.conf - System Databases and Name Service Switch configuration file

DESCRIPTION
       Various functions in the C Library need to be configured to work correctly in the local environment. Tra‐
       ditionally, this was done by using files (e.g., /etc/passwd), but other nameservices (like the Network
       Information Service (NIS) and the Domain Name Service (DNS)) became popular, and were hacked
       into the C library, usually with a fixed search order.
...

nsswitch functionality allows multiple back-ends for the getpw*. These back-ends can change the access required by a process, and SELinux has to allow for these different back-ends.

If you have setup your system with your passwd data in ldap, SELinux is forced to allow all confined domains that call getpw* to connect to the ldap_port_t ports in order to get passwd data.

# semanage port -l | grep ldap
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636

Also since the confined application needs to resolve the hostname of the ldap server, the confined application needs to be able to connect to dns_port_t.

# semanage port -l | grep dns
dns_port_t                     tcp      53
dns_port_t                     udp      53

Even worse if you are using NIS all of these applications have to be able to connect all ports and bind to all ports.

We have had a boolean allow_ypbind since RHEL5, luckily this is turned off by default and eliminates a lot of access. You only need to turn it on if you are using NIS.

sssd (System Security Services Daemon) to the rescue.

sssd provides a new back end for nsswitch. This backend causes all callers of getpw* functions to used a named socket, /var/lib/sss/nss. The beauty of the sssd backend is the sssd daemon does all of the ldap communications for the confined applications, rather then the confined applications needing to connect directly to the ldap server/port.

In Fedora 15 we added a new boolean authlogin_nsswitch_use_ldap that allows you to turn off this access.

NOTE: You can turn off this boolean even if you are using ldap for passwd entry resolution if you are using sssd.

How many rules does this eliminate?

Using sesearch to look for rules tat allow a domain to connect to the ldap_port_t.

# sesearch -A -t ldap_port_t -p name_connect -C | wc -l
717

If we eliminate the allow_ypbind boolean

# sesearch -A -t ldap_port_t -p name_connect -C | grep -v allow_ypbind | wc -l
386

Now if we further eliminate authlogin_nsswitch_use_ldap

# sesearch -A -t ldap_port_t -p name_connect -C | grep -v allow_ypbind | grep -v authlogin_nsswitch_use_ldap | wc -l
112

Meaning we have eliminate over 600 rules that allow confined domains to connect to the ldap_port_t.

You can turn off both booleans by executing.

# setsebool -P allow_ypbind=0 authlogin_nsswitch_use_ldap=0

I plan on turning both booleans off by default in Fedora 16.

Dan Walsh: 10 things you probably did not know about SELinux.. #2

dwalsh@redhat.com — Wed, 23 Mar 2011 12:13:28 +0000

#2 Outputting your semanage configuration

You set up a machine with a bunch of SELinux customizations. You want to take those customizations and make 5 other machines look the same.

How would I do this?

semanage -o /tmp/selinux.customizations

man semanage
...
       Output local customizations
       semanage [ -S store ] -o [ output_file | - ]

SYNOPSIS
       Output local customizations
       semanage [ -S store ] -o [ output_file | - ]

The semanage -o command will output all semanage customizations into a file that the semanage -i command can read.

# semanage -i /tmp/selinux.customizations
# scp /tmp/selinux.customizations root@otherhost.mycompany.com
# ssh otherhost.mycompany.com root@otherhost.mycompany.com semanage -i selinux.customizations

Here is the output of this command on my laptop.

# semanage output -o -
boolean -D
boolean -1 allow_polyinstantiation
boolean -0 authlogin_nsswitch_use_ldap
boolean -1 httpd_can_sendmail
boolean -1 xguest_connect_network
boolean -1 xguest_mount_media
boolean -1 xguest_use_bluetooth
login -D
login -a -s guest_u -r 's0' __default__
login -a -s unconfined_u -r 's0-s0:c0.c1023' root
login -a -s system_u -r 's0-s0:c0.c1023' system_u
login -a -s xguest_u -r 's0' xguest
user -D
user -a -r s0-s0:c0.c1023 -R 'staff_r system_r webadm_r' webadm_u
user -a -r s0 -R 'xguest_r' xguest_u
port -D
port -a -t http_port_t -p tcp 81
interface -D
interface -a -t netif_t eth*
node -D
node -a -M 0.0.0.0 -p ipv4 -t defaultif_t 0.0.0.0
node -a -M 255.255.255.255 -p ipv4 -t internalif_t 127.0.0.1
fcontext -D
fcontext -a -f 'all files' -t httpd_sys_content_t '/myweb(/.*)?'
fcontext -a -f 'all files' -t public_content_t '/shared(/.*)?'
fcontext -a -f 'all files' -t samba_share_t '/shared/samba(/.*)?'

Notice the -D commands, these are used to delete all local customizations. If you were to install this selinux configuration on your machine, you would have the same configuration as my laptop.

Note:  You would also need to make sure the policy modules were the same on each machine.

Dan Walsh: 10 things you probably did not know about SELinux..

dwalsh@redhat.com — Tue, 22 Mar 2011 18:33:58 +0000

Over the next few days, I am going to blog about things you probably did not know about SELinux

1: Multiple semanage commands:

The semanage command is pretty slow. It can take 10-20 seconds for a semanage command to complete. semanage recompiles a huge amount of policy. In Fedora 15 we have almost 500,000 allow and dontaudit rules. The compiler checking each type, user, role, etc to make sure they are valid.   I have seen people executing multiple semanage commands in post install of rpm spec files as well as people customizing lots of machines by executing setsebool, semodule and semanage commands. Not too many people realize you can run them all within the same transaction.

man semanage
...
       Input local customizations
       semanage [ -S store ] -i [ input_file | - ]
...
    -i, --input
              Take a set of commands from a specified file and load them in a
              single transaction.

The xguest uses this in its post install.

semanage -S targeted -i - << _EOF
boolean -m --on allow_polyinstantiation
boolean -m --on xguest_connect_network
boolean -m --on xguest_mount_media
boolean -m --on xguest_use_bluetooth
_EOF

It sets a bunch of boolean values. You can also manage different semanage commands within the same transaction.

semanage -i - << _EOF
port -a -t http_port_t -p tcp 81
fcontext -a -t httpd_sys_content_t "/myweb(/.*)?"
boolean -m --on httpd_can_sendmail
user -a -R "staff_r system_r webadm_r" -r s0-s0:c0.c1023 webadm_u
login -m -s guest_u -r s0 __default__
_EOF

Thomas Biege (Security): Forgotten Password and Birthday Attacks

Thomas (noreply@blogger.com) — Fri, 18 Mar 2011 08:42:28 +0000

I just stumbled over a piece of code that might be interesting for you as well. A web-app let's click you on a "forgotten password" link and will send a token to the (valid/known) email address you specified. When you return to the web-app and provide the token that was mailed to you, and the token was found by looking it up for ANY user, you are allowed to set a new password. So, theoretically (I didn't test it) this code is vulnerable to a birthday attack (random pair collision), the impact depends on the number of users and the length of the token.

For example, and I hope I get the math correct here, if the token is 8 bit long (8 bit of entropy, equally distributed) an attacker only needs to call the "forgotten password" functionality for 16 (birthday bound, 2^{n/2}) users and try 16 different tokens to have a probability of success close to 50%.

The solution is to look-up the user by email address or another unique identifier and verify if the token for this user matches or not.

Here is an example diagram for a 16 bit token (DNS TRXID) to compare brute force vs. birthday attack.

kostenloser Counter