Planet SELinux

Dan Walsh: New Security Feature in Fedora 19 Part 3: Hard Link/Soft Link Protection

dwalsh@redhat.com — 2013-05-22T17:42:52+00:00

It is surprising to most people who understand Linux and Unix that you are allowed to Hard Link to any file on the OS as long as it is on the same file system.
Hard linking means that you can put the same Inode number into two different directories. Prior to Fedora 19, a normal user would be allowed to do something like:

> ln /etc/shadow ~/shadow

Even though the /etc/shadow is owned by root. Then if the user tricked an administrator into doing something like

# chown -R dwalsh:dwalsh ~

This would cause the /etc/shadow file to be owned by dwalsh.

Similarly in the past hackers have tricked privileged applications to follow hard and soft links, created in a user account to compromise the system.

Kees Cook wrote some patches for the linux kernel that allows distributions to disable this behaviour.

Here is Kees Description of the benefits of the patch:

This patch adds symlink and hardlink restrictions to the Linux VFS.

Symlinks:

A long-standing class of security issues is the symlink-based time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp

The solution is to permit symlinks to only be followed when outside a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.

<snip>

Hardlinks:

On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the
hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation
of this flaw is to cross privilege boundaries when following a given hardlink (i.e. a root process follows a hardlink created by another
user). Additionally, an issue exists where users can "pin" a potentially vulnerable setuid/setgid file so that an administrator will not actually
upgrade a system fully.

The solution is to permit hardlinks to only be created when the user is already the existing file's owner, or if they already have read/write
access to the existing file.

Many Linux users are surprised when they learn they can link to files they have no access to, so this change appears to follow the doctrine
of "least surprise". Additionally, this change does not violate POSIX, which states "the implementation may require that the calling process
has permission to access the existing file"[1].

This change is known to break some implementations of the "at" daemon, though the version used by Fedora and Ubuntu has been fixed[2] for
a while. Otherwise, the change has been undisruptive while in use in Ubuntu for the last 1.5 years.

<snip>

This feature is turned on by default in /usr/lib/sysctl.d/50-default.conf in F19.

grep fs /usr/lib/sysctl.d/50-default.conf
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

There was some concern that this could cause problems in applications that expect this behaviour, so it can be disabled.
But overall, I think it is a positive feature for Fedora.

Dan Walsh: SELinux is a labeling system. First thought should be "Is there a label that would make this work?"

dwalsh@redhat.com — 2013-05-20T13:03:01+00:00

On the SELinux mail list today, someone asked:

I want to store the logs from openswan into a different file ( /var/log/ipsec ) than the default. For this purpose I added

plutostderrlog=/var/log/ipsec

to ipsec.conf.
    As long as I keep the server in permissive mode, openswan starts OK. If, however, I switch to enforcing, the daemon refuses to start with the following error message displayed in the console:

ipsec_setup: Starting Openswan IPsec U2.6.32/K3.0.78-1.el6.elrepo.x86_64...
ipsec_setup: Cannot write to "/var/log/ipsec".

   The audit log does not record anything useful so I tried to switch dontaudit to off and see if anything useful comes out. After running audit2allow and a bit of trial and error I came out with the following custom policy :

module myipsec 1.0;
require {
        type ipsec_t;
        type var_log_t;
        class file { write ioctl getattr append };
}
#============= ipsec_mgmt_t ==============
allow ipsec_mgmt_t var_log_t:file write;

   The above policy worked for me but I am wondering if it is OK

The problem is the administrator decided to add policy that allows ipsec_mgmt_t to write any file labeled var_log_t. A hacked ipsec_mgmt could now overwrite any log file on the system labeled var_log_t, including /var/log/messages. var_log_t is the default label for ANY file in /var/log directory that does not have SELinux policy controlling it. Also remember "write" access is always more dangerous then "append" access, since "write" allows you to truncate a file, destroying evidence, versus append to the end of a file.

In the paper I wrote a few years ago,

What is SELinux trying to tell me?
The 4 key causes of SELinux errors.

I explain that adding policy should be your third option, not your first. In this case Dominic Grift pointed out the admin, that changing the label of the target would fix the problem and not involve adding custom policy.

semanage fcontext -a -t ipsec_log_t "/var/log/ipsec.*"
restorecon -v /var/log/ipsec

By telling SELinux that the content in the /var/log/ipsec log file was ipsec_log_t, you solve your problem and end up with the same security you had before the change.

Think Labels First...

James Morris: Slides from my Security Subsystem Overview at LinuxCon Japan 2012

jamesm — 2013-05-13T11:14:29+00:00

Whoops. Looks like I forgot to post my slides from last year’s LinuxCon Japan talk on the Linux kernel security subsystem.

Here they are:

http://namei.org/presentations/kernel-security-state-linuxconjp-2012b.pdf

I’ll be giving an update at the upcoming LinuxCon Japan in Tokyo in a couple of weeks.

James Morris: Linux Security Summit 2013 (New Orleans) – Call for Participation

jamesm — 2013-05-06T09:59:59+00:00

The CFP for the 2013 Linux Security Summit has been announced.

The summit will be held across the 19th and 20th of September in New Orleans, co-located again with LinuxCon and Linux Plumbers. Note that presenters and attendees at LSS must be registered as LinuxCon attendees.

We’ll be following a similar format to last year, with a day of refereed presentations, followed by subsystem updates and break-out sessions on the second day. We’ll probably finish up around lunchtime on the Friday for people needing to head home that day, but check the final schedule for details once it’s published.

The CFP is open until 14th June, with speaker notifications to be posted by 21st June.

If you’ve been doing cool and interesting work in Linux security, be sure to submit a proposal!

Joshua Brindle: SE Android and the motochopper exploit

2013-04-30T05:00:00+00:00

SE Android prevents first exploit against commercial phone

That should have been the title of this post, but alas it is not.

By now you may know that the Samsung Galaxy S4 is the first commercial device shipped with SE Android included.

Included, but not enforcing. If you are familiar with SELinux you know that there is a developer mode (also called permissive) that audits access that would have been denied, but does not actually deny them. This is very useful for developing your policies without having to interate through accesses one at a time (this takes a very very long time with complex software).

The standard way of writing policy is to use permissive mode to run an application, then look at the logs and figure out what the access patterns are, what should be labeled what, write the policy, then try again. Eventually you go into enforcing mode when you are ready to send your product to production.

That is the theory, anyway.

History lesson

Back in the Fedora 2 days (that is 2004) SELinux shipped in enforcing, with a strict policy. It was a catastrophy. Linux users who were accustumed to cat'ing /dev/cdrom, for whatever reason, became angry that they couldn't do it all of a sudden. The targeted policy was then created which would resrtict only high-threat applications, like apache and ssh. Most recently Dan Walsh, over at Red Hat, introduces new application policies to the masses in permissive mode (note, SELinux supports permissive mode per-type, not just system wide) and collects denials from users for a few months, to figure out how people use the applications, since he can't be an expert at every single one. He then switches the policy to enforcing when the policy has been fleshed out.

Lost Opportunity

This is the first commercial phone with SE Android; there is a huge amount of risk to going into the wild in enforcing. I don't know if they were nervous that something like Fedora 2 would happen or it was carrier certification delays or perhaps they just don't think SE Android should be on unless explicitely requested. No matter what the reason, a huge opportunity to show the world the power of SE Android was lost. No worries, though, there will be another opportunity.

The Exploit

Ok, lets look at this exploit and see what would have happened. I don't happen to have a Galaxy S4 in front of me, but the stock recovery image has everything I need to look at this.

First, the exploit is motochopper and was originally written for a Motorola. The reason it works on the S4 is that the phones have similar chipsets. The chipset vendors provide kernel patches, drivers, userspace components, etc to the OEM's. The OEM's then integrate that into their version of Android, normally what Google gives them + their extras. In this case the vulnerability was in the code provided by the chipset, it had a world writable fb0 device node, that allowed an mmap() of kernel memory.

Without a phone in front of me, how on earth could I know that the exploit wouldn't have worked, you ask?

Edit: The above isn't quiet accurate. The vulnerability was a bug in the mainline framebuffer rather than in a specific chipset, which means it may affect even more devices.

The Policy

On the recovery ROM are 2 files that I can use to mount this investigation. I know the exploit mmap()'s /dev/graphics/fb0 so first I want to know what that would be labeled:

$ grep /dev/graphics file_contexts 
/dev/graphics(/.*)?     u:object_r:graphics_device:s0

So, /dev/graphics/fb0 (and indeed everything under the graphics directory) would be labeled graphics_device.

On SE Android the type you get when you use adb shell is shell. So, next I need to look for accesses between shell and graphics_device:

$ sesearch --all -s shell -t graphics_device sepolicy       
Found 7 semantic av rules:
   allow appdomain dev_type : file getattr ; 
   allow appdomain dev_type : dir { ioctl read getattr search open } ; 
   allow appdomain dev_type : lnk_file { read getattr } ; 
   allow appdomain dev_type : chr_file getattr ; 
   allow appdomain dev_type : blk_file getattr ; 
   allow appdomain dev_type : sock_file getattr ; 
   allow appdomain dev_type : fifo_file getattr ;

Indeed there is no write permission so the mmap attempt to write to kernel memory would fail. This only covers the adb shell case though, and that is typically done by the owner of the device. Granted that this makes problems for BYOD but the more interesting question is, could malicious apps exploit this?

In the seapp_contexts file it shows that third party apps will be labeled untrusted_app, so lets look at that:

$ sesearch --all -s untrusted_app -t graphics_device sepolicy      
Found 7 semantic av rules:
   allow appdomain dev_type : file getattr ; 
   allow appdomain dev_type : dir { ioctl read getattr search open } ; 
   allow appdomain dev_type : lnk_file { read getattr } ; 
   allow appdomain dev_type : chr_file getattr ; 
   allow appdomain dev_type : blk_file getattr ; 
   allow appdomain dev_type : sock_file getattr ; 
   allow appdomain dev_type : fifo_file getattr ;

Again, no dice. Apps can stat() the file but not read or write it. The same goes for the browser (browser_app) and even platform_app, which includes all of the apps included on the device from Samsung and Google.

But which types can write to the file? Good question, SE Android may be blocking all of this access but we know the vulnerability is there, we should find out what on the system is able to exploit it:

$ sesearch -t graphics_device --allow -c chr_file -p write sepolicy 
Found 7 semantic av rules:
   allow system graphics_device : chr_file { ioctl read write getattr lock append open } ; 
   allow system_app graphics_device : chr_file { ioctl read write getattr lock append open } ; 
   allow mediaserver graphics_device : chr_file { ioctl read write getattr lock append open } ; 
   allow unconfineddomain dev_type : chr_file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod open audit_access } ; 
   allow mm-pp-daemon graphics_device : chr_file { ioctl read write getattr lock append open } ; 
   allow surfaceflinger graphics_device : chr_file { ioctl read write getattr lock append open } ; 
   allow bintvoutservice graphics_device : chr_file { ioctl read write getattr lock append open } ;

Well, system and system_app, which are pretty powerful either way, granted it is an escalation if you can compromise them. unconfineddomain (hrm.. whats that?), the seapp_contexts file doesn't have any entries for it, so presumably it is there for MDM/MAM vendors to run unconfined apps if they choose to. surfaceflinger obviously needs to be able to write to the graphics device, and possibly mediaserver. bintvoutservice probably does too, and I don't know what mm-pp-domain is, probably a Qualcomm specific thing.

So, there are definitely vectors to get at this, but they involve compromising protected apps (in a real security analysis we'd keep backtracking to see what vectors there are to attack system and system_app, for example) but this exploit wouldn't have been pulled off nearly as easily as it was, if SE Android were enforcing.

Conclusion

Exploits like this are scary, not because of owners that want to root their phones but because, if an owner can do it, it is highly likely that an adversary can. These mobile devices are our lives, they have business data on them, they have private data, and they can be used to steal your money in various ways (such as premium SMS's). There will not be a shortage of vulnerabilities until OEM's and users alike start thinking from a security mindset. The tools are there, no OEM has an excuse not to use them.

It may not be a bad idea to set SE Android into enforcing once you've rooted your phone, so that malicious apps don't take advantage of the same vulnerability, if I get my hands on a GS4 I'll blog about doing that.

Dan Walsh: SELinux & PaaS: Deep Dive on Multi-tenancy, Containers & Security with Dan Walsh, Red Hat

dwalsh@redhat.com — 2013-04-23T20:52:39+00:00

SELinux & PaaS: Deep Dive on Multi-tenancy, Containers & Security with Dan Walsh, Red Hat

Last week I went to Portland, OR for the OpenShift Origin Day.
I gave a talk about SELinux and OpenShift.

The talk covered the importance of MAC and container/namespaces when using a multi-tenant environment like OpenShift.

The talk also covers enhancements I want to make to OpenShift gears (containers) and additional features that we will be adding.

The video has been posted to youtube.

Dan Walsh: What is the differences between user_home_dir_t and user_home_t

dwalsh@redhat.com — 2013-04-23T14:56:21+00:00

I just saw this email on the SELinux Fedora Mailing list and figured I would try to answer it here.

Lets look at the labels of content in my home directory.

> ls -lZd / /home /home/dwalsh /home/dwalsh/.ssh /home/dwalsh/.emacs /home/dwalsh/public_html
dr-xr-xr-x. root root system_u:object_r:root_t:s0 /
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 /home
drwx------. dwalsh dwalsh unconfined_u:object_r:user_home_dir_t:s0 /home/dwalsh
-rw-r--r--. dwalsh dwalsh unconfined_u:object_r:user_home_t:s0 /home/dwalsh/.emacs
drwxr-xr-x. dwalsh dwalsh unconfined_u:object_r:httpd_user_content_t:s0 /home/dwalsh/public_html
drwx------. dwalsh dwalsh unconfined_u:object_r:ssh_home_t:s0 /home/dwalsh/.ssh

As we go through the different files and directories that make up my home directory we see multiple SELinux labels. Notice the files that are owned by me have an SELinux user of staff_u. On most systems these would be labeled unconfined_u. In SELinux every file that is created by a process running as unconfined_u will get the unconfined_u SELinux user placed on the file label. Similarly staff_u will get staff_u, ...

This component is ignored on most SELinux systems, system_u on /home here is the default label set by restorecon or at install time.

object_r is just a place holder. For all SELinux systems other then some experimental systems, every object on the file system gets labeled object_r.

The last field is all s0. This is the MCS or MLS label depending on your policy. On most systems this will be s0 (SystemLow)

SELinux is a type enforcement system, and the interesting parts is the types. Lets look at each directory/file above and the types associated with them.

/ is labeled with the root_t type. This should be the only object on the system with the root_t type, if you have other objects on the computer with this label, then you were probably running in permissive mode and a confined process created it, you need to fix the labels. The main purpose of root_t is for policy writers to define transitions. for system applications that are going to create content in /. For example boot flags will get created with etc_runtime_t. Random directories created in / will get labeled default_t.

# touch /.autorelabel; ls -lZ /.autorelabel
-rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 /.autorelabel
# mkdir /foobar; ls -ldZ /foobar
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /foobar

One thing to note about default_t is that NO confined apps are allowed to read content labeled default_t, because we have no idea what kind of content would be in this directory. Invariably when some one creates a new directory in / without setting the labels, SELinux will have issues. If foobar above contained apache content you would need to execute the following in order to allow apache to read the content.

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

/home is labeled with the home_root_t type. home_root_t is basically used for the toplevel or root directory for homedirs. It's main purpose is to be used by policy for applications that need to create home directories or file system quota files.

# sesearch -T -t home_root_t
Found 10 semantic te rules:
   type_transition quota_t home_root_t : file quota_db_t;
   type_transition sysadm_t home_root_t : dir user_home_dir_t;
   type_transition firstboot_t home_root_t : dir user_home_dir_t;
   type_transition useradd_t home_root_t : dir user_home_dir_t;
   type_transition lsassd_t home_root_t : dir user_home_dir_t;
   type_transition oddjob_mkhomedir_t home_root_t : dir user_home_dir_t;
   type_transition smbd_t home_root_t : dir user_home_dir_t;
   type_transition automount_t home_root_t : dir automount_tmp_t;

/home/dwalsh is labeled with the user_home_dir_t type. Policy writers use this type to write transition rules to get content labeled correctly within the homedir. Confined applications that create content in a users home directory need transition rules to create the content with the proper label. For example if you use ssh-copy-id on the remote machine, this triggers sshd to create the /home/dwalsh/.ssh directory, which we want labeled ssh_home_t, to protect the content.

# sesearch -T -s sshd_t -t user_home_dir_t | grep "\.ssh"
type_transition sshd_t user_home_dir_t : dir ssh_home_t ".ssh";

sesearch -T -s staff_t -t user_home_dir_t |wc -l
118

Note there are over 118 transition rules for a confined user creating content in his home directory. With the advent of file name transition rules, we have exploded the number of these transitions in order to get proper labeling in the users home dir.

/home/dwalsh/.emacs is labeled user_home_t, which is the default label for all content in a users home directory. This is the label that users are allowed to read/write and manage. We try to prevent confined applications from being able to read and write this content, since this is where users store private content like credit card data, passwords shared secrets etc. When we have a confined application that needs to access this content we usually wrap it in a boolean like ftp_home_dir. Or we create a new type for this content, like mozilla_home_t or ssh_home_t.

/home/dwalsh/.ssh is labeled ssh_home_t, and contains content that only user types and sshd is allowed to read. Most other confined domains are not allowed to view content in this directory since it contains content like your secret keys.

/home/dwalsh/public_html is labeled httpd_user_content_t , which by default is the only place apache process is allowed to read in the home directory. Allowing apache to read .ssh or say your .mozilla directory is just asking for trouble.

Note: In order for apache or sshd to read their content they need to be allowed to search and getattr on every directory in the path. The httpd would need to search root_t, home_root_t, user_home_dir_t, httpd_user_content_t. It is not allowed to do this by default and needs the httpd_enable_homedirs boolean turned on.

# sesearch -A -b httpd_enable_homedirs -c dir -C | grep -v nfs | grep -v samba
Found 20 semantic av rules:
DT allow httpd_sys_script_t home_root_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_sys_script_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_user_script_t user_home_type : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_t user_home_type : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_user_script_t home_root_t : dir { ioctl read getattr lock search open } ; [ httpd_enable_homedirs ]
DT allow httpd_t home_root_t : dir { ioctl read getattr lock search open } ; [ httpd_enable_homedirs ]
DT allow httpd_user_script_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_suexec_t user_home_type : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_suexec_t home_root_t : dir { ioctl read getattr lock search open } ; [ httpd_enable_homedirs ]
DT allow httpd_suexec_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]

Getting back to the question that drove me to create this blog.

What is the differences between user_home_dir_t and user_home_t?

user_home_dir_t should only be the label of the users home directory but not of any content in the users home directory.
user_home_t is the label for generic content in a users homedir.

If you want to see all the labels that effect the users homedir, you can look at /etc/selinux/targeted/contexts/files/file_contexts.homedirs.

grep /home /etc/selinux/targeted/contexts/files/file_contexts.homedirs |wc -l
300

Dan Walsh: Understanding MCS Separation.

dwalsh@redhat.com — 2013-04-17T15:40:16+00:00

We designed a new way of using MCS, Multi Category Security, when we developed sVirt (Secure Virtualization) a few years ago.

To understand MCS it is helpful to understand something about MLS.

When Red Hat Enterprise Linux 5 came out, we had a done a lot of work adding MLS, Multi Level Security. MLS requires the Belle & La Padula model of security. This model takes into account the "Level and Category" of the data, and adds rules like a higher level process (TopSecret) is not allowed to write down (Secret) and a lower level (Secret) process is not allowed to read a higher level data (TopSecret). The simple description of categories would be in order to read or write your process must have all the categories of the target. Levels can go from s0 (SystemLow) to s15 (SystemHigh). Then you can have any combination of 1024 categories.

In MCS we stole the idea of categories and dropped the concept of levels.

As I mentioned above the process category most include ALL of the categories of the target, otherwise MCS separation would block the access. It is best to see an example of this.

Say I have a process labeled system_u:system_r:svirt_t:s0:c1,c2 from MCS Separation point of view. This process would be allowed to access any file with any of these 4 MCS labels.

s0:c1

s0:c2

s0:c1,c2

Since most files on a targeted system have the MCS label s0. MCS Labeling does not block much mcs constrained applications.

By convention MCS confinement always uses two categories, and the categories can not be the same. s0:c1,c1 == s0:c1. Secondarily tools that launch MCS separate apps like libvirt and sandbox, make sure they never launch two processes with the same MCS label. Which means we guarantee that two svirt_t always have two MCS labels that no other svirt_t or svirt_image_t would have. Therefore a process running svirt_t:s0:c1,c2 would not be prevented by MCS from access to any file with a MCS label of s0 or s0:c1,c2. It would be denied from reading any file labeled s0:c1,c3 or s0:c2,c4 or s0:c4,c6.

But looking at MCS separation as the only control, misses out on type enforcement controls.

svirt_t access

We define our virtual machines as svirt_t type, and then we define rules about which types an svirt_t type is allowed access to. If I wanted to see which types svirt_t is allowed to write, I could execute the following command.

# sesearch -A -s svirt_t -c file -p write -C | grep open | grep -v ^D
   allow virt_domain svirt_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow svirt_t xen_image_t : file { ioctl read write getattr lock append open } ;
   allow virt_domain svirt_image_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain svirt_tmpfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain virt_cache_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain qemu_var_run_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain anon_inodefs_t : file { ioctl read write getattr lock append open } ;
   allow virt_domain svirt_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow svirt_t svirt_t : file { ioctl read write getattr lock append open } ;
ET allow virt_domain dosfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ virt_use_usb ]
ET allow virt_domain usbfs_t : file { ioctl read write getattr lock append open } ; [ virt_use_usb ]

This means a confined virtual machine running as svirt_t:s0:c1,c2 would ONLY allowed to write to the following file types IFF they are MCS labeled s0 or s0:c1,c2

svirt_tmp_t, svirt_image_t, svirt_tmpfs_t, virt_cache_t, qemu_var_run_t, svirt_home_t,

dosfs_t and usbfs_t iff the virt_use_usb boolean is turned on, perhaps we should turn this off by default.

anon_inodefs_t and svirt_t are not file types, svirt_t is a process types which would be in /proc.

libvirt and the kernel need to ensure that non of these files get labeled with s0.

Openshift domains are allowed to write/open

Kernel file systems anon_inodefs_t, openshift_t,hugetlbfs_t, security_t

openshift_tmp_t, openshift_rw_file_t, openshift_tmpfs_t

MCS Constrained Types

Thee following types are MCS Constrained.

seinfo -amcs_constrained_type -x
   mcs_constrained_type
      svirt_lxc_net_t
      openshift_app_t
      openshift_min_t
      openshift_net_t
      openshift_min_app_t
      openshift_net_app_t
      svirt_tcg_t
      netlabel_peer_t
      sandbox_x_t
      svirt_t
      sandbox_min_t
      sandbox_net_t
      sandbox_web_t
      openshift_t
      sandbox_t

Dan Walsh: Audit2allow should be your third option not the first.

dwalsh@redhat.com — 2013-04-17T13:11:55+00:00

Whenever I talk about SELinux lately, I make everyone stand up and say.

SELinux is a labeling system.
Every process has a label every object on the system has a label. Files, Directories, network ports ...
The SELinux policy controls how process labels interact with other labels on the system.
The kernel enforces the policy rules.

The follow up to this is, if you get a denial the First thing you should think is, perhaps one of the labels is WRONG.

I wrote a paper a while ago called the SELinux Four Things. In which I point out the four causes of SELinux denials.

You have a labeling problem.

You have changed a process configuration, and you forgot to tell SELinux about it.

You have a bug in either an application or SELinux policy. Either SELinux policy did not know an application could do something, or the application is broken.

You have been hacked.

The solution to #3 is to report a bug and use audit2allow to generate a local policy module and install it until either the application is fixed or SELinux policy adds rules to allow it.

The problem i see is that administrators seem to go to this option when ever they see a denial.   Lets look at a recent example from email.

In a recent email on selinux@lists.fedoraproject.org, Richard reported:

I have a CGI application named "mapserv" that needs to write to a specific location: "/rwg/mapserver/tmp"

He figured out that Apache content was usually labeled httpd_sys_content_t, which was a step in the right direction, so I guess he labeled this rectory tree as
httpd_sys_content_t.

Then he asked about writing policy that looked like.

module test 1.0;

require {
        type httpd_sys_content_t;
        type httpd_sys_script_t;
        class dir add_name;
        class file { write create };
}

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_sys_content_t:dir add_name;
allow httpd_sys_script_t httpd_sys_content_t:file { write create };

This policy obviously came from audit2allow, and would work, except for a couple of problems, the biggest being that all CGI Scripts would be able to read write all Apache content. The policy is also fragile since you might get an AVC like httpd_sys_script_t is not allowed to append to httpd_sys_content_t.

manage_files_pattern(httpd_sys_script_t, httpd_sys_content_t, httpd_sys_content_t) Would have been better.

Is there a better label I could have used?

But the main point of this blog would be that Richard should not have used a audit2allow module. He could have used httpd_sys_rw_content_t for the tmp directory.

# semanage fcontext -a -t httpd_sys_rw_content_t "/rwg/mapserver/tmp(/.*?)"
# restorecon -R -v /rwg/mapserver/tmp

This would have been choice "1" above, one of the labels is wrong.

Could I change the process label?

Dominic Grift pointed out, in a mail reply, another solution.

cat > mywebapp.te << EOF
policy_module(mywebappp, 1.0.0)
apache_content_template(mywebapp)
EOF

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

Now you can use the following new types:

httpd_mywebapp_script_t (mywebapp process type)
httpd_mywebapp_script_exec_t (mywebapp cgi executable file type)
httpd_mywebapp_content_t (mywebapp readonly file type)
httpd_mywebapp_content_rw_t (mywebapp read/write file type)
httpd_mywebapp_content_ra_t (mywebapp read/append file type)
httpd_mywebapp_htaccess_t (mywebapp htaccess file types)

Basically you can just label the cgi script with the mywebapp script executable file type and then the mywebapp process will run with the mywebapp process type creating files with the mywebapp content file types.

This solution satisfies "1", changing both the process label and the target label. This is probably the best solution, since if Richard used other CGI scripts on his machine, only the mapserver cgi script would be able to write the mapserver cgi content, and he would have better separation.

Note: I would have used sepolicy generate --cgi PATHTO/mapserver.cgi to generate the policy.

Could I modify the SELinux configuration to allow this access?

A third option would be to turn on the httpd_unified boolean. (This would an option of type "2"). Although not the best solution for the problem.

httpd_unified is described as "Unify HTTPD handling of all content files."

# setsebool -P httpd_unified 1

This means it will allow the apache process and default apache scripts to read/write/execute all default labeled apache content.

Bottom line, when you see an SELinux AVC, the way your decision tree should go something like the following.

Is the process that is being denied running with the correct label? Could I make it run with a better label?

Does the target object have the correct label or could I assign it a label that would allow the access from the process label?

Is their an SELinux Boolean that would allow the access?

If this is a network port being denied, did I modify the default settings and could I modify the labels on network packets using semanage port.

Do I believe this is a bug in an application? If yes, I need to report a bug?

Is this a bug in SELinux policy and the access should be allowed by default? I should install a local modification and report this as a bug.

Am I being hacked?

setroubleshoot attempts to help you walk through this process, and newer versions of audit2allow show you booleans and potential labels you can use.

Joshua Brindle: And here it is... mRAT's found that bypass MAM

2013-04-12T05:00:00+00:00

As a follow-up to my last blog post, I just came across this article: Mobile malware gets serious – RATs can bypass sandboxes and encryption

1 in 1000 devices, the tools are in the wild. There is no reason to believe this number will go down. Further, these mRAT's apparently know how to bypass MDM and MAM sandboxes and encryption.

of course, mRAT's aren't anything new, but this is the first I've heard about ones that specifically target/bypass MDM/MAM.

Worse, the tools aren't just being used by experts; hackforums.net has tutorials on using them with commands like 'Hit Start then run, type "CMD" without quotations, hit OK, type "IPCONFIG" without quotations, etc'.

The solution is integrating SE Android into your devices; but SE Android, like SELinux is no silver bullet. You need good policies. Mobile device manufacturers are notoriously bad at securing their devices. The fact that a device node directly exposing kernel memory was world readable/writeable on many Samsung devices is direct evidence of this. The same people writing that software could not possibly be trusted to write secure SELinux policies. Separate teams that do security analysis and testing must ensure the policies are reasonable, etc.

This isn't rocket science, but it isn't standard operating procedure either. We've been doing independent verification and validation (IV&V) in government spaces forever. This needs to happen in mobile and there need to be security mechanisms that don't rely on discretionary access controls in place, which, of course, means mandatory access controls, which SE Android offers.

Dan Walsh: New Security Feature in Fedora 19 Part 2: Shared System Certificates

dwalsh@redhat.com — 2013-04-11T14:17:49+00:00

One of the cool things about writing this series of blogs for each Fedora Release is finding out about the changes is different parts of the OS outside of SELinux. I love getting suggestions of security topics to blog on. If you know of security topics I should cover send them to me at dwalsh@redhat.com or tweet @rhatdan

Shared System Certificates

Currently Tools like NSS (Mozilla products like Firefox/Thunderbird), GnuTLS, OpenSSL and Java on a Fedora box ship their own public key certificates and their own trust relationships. This means if an administrator wants to add/modify/delete trust to certain Certificates, he might have to modify several different stores in order to get the correct security.

A new feature in Fedora 19 is a system wide trust store of static data to be used by crypto toolkits as input for certificate trust decisions.

This feature the tools listed above a default source for retrieving system certificate anchors and black list information. Fedora 19 will be the first step toward development of a comprehensive solution.

Look at the feature for more information on the changes, but the following two sections explain the key benefits to this feature and how users will use it.

Benefit to Fedora

The goal is to empower administrators to configure additional trusted CAs, or to override the trust settings of CAs, on a system wide level, as required by local system environments or corporate deployments. Although this is theoretically possible today, it's extremely hard to get right.

Fedora will immediately gain a unified approach to system anchor certificates and black lists. This is then built on in the future to be a comprehensive solution.

User Experience

Administrators will be able to use a tool to add a certificate authority file to the system trust store and have it recognized by all relevant applications.

Users will stop being surprised by incoherent and unpredictable trust decisions when using different applications with websites/services which require custom trust policy.

Joshua Brindle: Security Anti-Pattern - Mobile Castles on Sand (or why app wrapping is not a security model)

2013-04-11T05:00:00+00:00

Mobile Application Management (MAM)

Mobile Device Management (MDM) was all the hotness just a few years ago. It gave IT departments the ability to manage both corporate owned devices and devices owned by employees (BYOD) but it was dissatisfying. As BYOD became more prevalent and corporate owned devices less it made users feel like they were giving up all control of their device to their employer, mainly because they were. Most users at this point probably know the feeling of adding their corporate credentials into their phone and seeing the dreaded 'you are giving administrators the ability to wipe your phone, install apps, remove apps, and locate your phone' screen.

Then there was the issue of having multiple administrators that wanted to do different things with your device.

Even for the administrators, the solution was incomplete. It did not give them the ability to manage app configuration, app storage, app authentication, etc.

That is where MAM comes in. For the administrators it means they can package apps with configuration, version it, push it out and wipe only corporate app data when an employee leaves. The nicer systems add single sign-on so that a user can authenticate once and get access to all corporate apps. They also store corporate data encrypted and can report usage statistics back to corporate IT. For users it means that they don't have to give up full control of their device.

Sounds great, right?

How does it work?

Well, mobile devices don't typically have this kind of granular control built in. Further, off-the-shelf applications generally don't come configured or support single sign-on. The solution that MDM vendors started peddling is called app wrapping. Basically it means that the IT department takes the apps they want to manage (whether they are internally developed or 3rd party) and runs a tool from the MAM vendor that packages the app within another app, the wrapper (or the castle).

The outside package interacts with the real device, including storing data to disk encrypted, verifying credentials with corporate authentication servers, etc. The fancier ones even prevent apps from running outside of specific physical locations (geofencing), and will attempt to detect a rooted device (though that is impossible in practice).

So, this still sounds great. From a functionality point of view this is a superior experience for both the user and IT, so what is the problem?

Userspace containerization (or building castles)

Lets start with the obvious one first. The inside (wrapped) app is modified to not be able to interact with the real device, but to interact with the wrapper instead. Two standard ways this is done is by providing an SDK that corporate apps can be written with and the other is called app wrapping. It should be noted that while using the SDK is the safer option, it will likely lock you in to a single MAM vendor.

App wrapping on Android involves modifying the Dalvik bytecode ahead of time to add all of the functional additions as well as changing functions that would normally interact directly with the system (think filesystem operations, intents, binder calls, etc) to use analogous calls in the wrapper instead. The effect here is that the wrapper can 1) ensure filesystem writes only go to allowed locations and are encrypted and 2) to prevent IPC with apps outside of the "container".

Well, that is the thought, anyway.

No one in their right mind would believe that they can write a libc wrapper that intercepts open() calls to make security decisions and think that it buys them anything, but that is fundamentally what is happening here. App wrappers cannot contain numerous, supported features on Android such as jni to native libraries and java reflection. A particularly crafty app might even have a scripting language interpreter or its own java class loader that would be nearly impossible for the wrapper to understand and secure.

There is no chance that an MAM implementation could keep an app that wanted to exfiltrate corporate data from doing so. That is an easy problem to solve though, you only wrap trusted apps, because they are either corporate or known 3rd party apps, right? Well, hopefully, for your sake, those apps don't have vulnerabilities that a spear phisher can take advantage of to gain access to corporate data (spoiler: they do).

In the scheme of things this is a relatively low threat, though, so lets move onto the real issue.

The insecure platform (or the sand)

People have tried building secure on top of insecure as long as personal computers have been around. The appeal is that there is always an insecure platform, be it Windows, Linux, iOS, or Android and there is always a need to access secure data is always there.

I'll take this opportunity to suggest that, if you haven't already, you should read: The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments

The fact is that if the system below your application isn't secure no amount of anything will make your application (or wrapper) secure. Detecting rooted devices is not enough. Most detection is heuristic, such as checking for the existence of /system/xbin/su. Suppose the device is not rooted by the user such that su exists but by an adversary? Root access gained for the intention of stealing corporate data would not likely be detected by an MAM solution and therefore malicious applications running on the device would be able to affect the corporate apps in various ways, from communicating with them, bypassing the wrapper, all the way to scanning their memory and extracting corporate data.

Most snake oil vendors will claim encryption solves this problem. Encryption may be a suitable solution to data-at-rest, data not currently being accessed that is sitting on disk, but when your corporate email app is running the emails are in memory, not encrypted. Even if an industrious app writer did extra work to keep them encrypted in memory the decryption key must also be in memory, and is vulnerable.

So, this is the real threat. If your app has data I want and it runs on a standard Android or iOS phone, I'll be able to get it, no matter what your MAM vendor is telling you.

As a non-security related aside, you probably don't have permission to download 3rd party apps from the app store and wrap them, which would constitute unlicensed distribution, you'd have to get permission from the app owner. An interesting ramification of this is that GPL apps can't be legally wrapped since the GPL license of the app would have to apply to the wrapper as well.

The solution

Just like in standard computing the solution isn't hard, but is rarely used.

You must have a secure host platform if you want your applications to be secure. Unfortunately not many options exist for this but fortunately there are options that are freely available. The one that I favor is, of course, SELinux. I've been involved in building SELinux systems to secure even the most important data for nearly a decade now and it has proven true.

Anecdotally, I have security researcher friends who work on the offensive side of the fence that have told me when they encounter an SELinux machine they bail and look for an easier target. It is important to note that we aren't talking about out-of-the-box Fedora installs, though, but systems intentionally and knowingly hardened against this type of adversary.

Which brings us back to Android. The Security Enhanced Android (SE Android) project has been picking up more and more steam. Much of it is already merged into AOSP which allows all Android vendors to use it and recently Samsung has announced a device that will have it included by default. This is definitely a step in the right direction but a far cry from what it will take to feel confident allowing important corporate data to be accessed on non-corporate owned devices.

With a secure platform you can enjoy the functionality benefits of an MAM solution and be confident that security provided by the platform will keep their castles secure, both from the inside and the outside.

Unfortunately, none of this is a solution you can use today. Technology must, as usual, catch up to market demands. The demand must be there, though. Demand secure platforms. There is no excuse for Android vendors to not include SE Android in future offerings, all the hard work has already been done by early adopters.

Update: My next entry has validation for this post, seen in the wild.

Dan Walsh: New Security Feature in Fedora 19 Part 1: New Confined/Permissive Process Domains

dwalsh@redhat.com — 2013-04-10T13:04:24+00:00

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.

In Fedora 18, we added 8 new permissive domains, all of which are now enforcing in Fedora 19.

Fedora 18 Permissive Domains/ Now Confined in Fedora 19
pkcsslotd_t (daemon manages PKCS#11 objects between PKCS#11-enabled applications)
   slpd_t (Server Location Protocol Daemon)
   sensord_t (Sensor information logging daemon)
   mandb_t (Cron job used to create /var/cache/man content)
   glusterd_t (policy for glusterd service)
   stapserver_t (Instrumentation System Server) Note: This was back ported to Fedora 17.
   realmd_t (dbus system service which manages discovery and enrollment in realms and domains like Active Directory or IPA)
   phpfpm_t (FastCGI Process Manager)

Fedora 19 Permissive Domains

systemd_localed_t
       systemd-localed is a system service that may be used as mechanism to
       change the system locale settings, as well as the console key mapping
       and default X11 key mapping. systemd-localed is automatically
       activated on request and terminates itself when it is unused.

systemd_hostnamed_t
       systemd-hostnamed is a system service that may be used as mechanism to
       change the system hostname. systemd-hostnamed is automatically
       activated on request and terminates itself when it is unused.

systemd_sysctl_t
       systemd-sysctl.service is an early-boot service that configures
       sysctl(8) kernel parameters.

httpd_mythtv_script_t
       mythtv cgi scripts used for managing mythtv scheduling and content.

   openshift_cron_t
        OpenShift System Cron jobs run as openshift_cron_t, not gear cron jobs.

   swift_t
OpenStack Object Storage (swift) aggregates commodity servers to work together
   in clusters for reliable, redundant, and large-scale storage of static objects.

Fedora 19 Modules Removed
shutdown.pp (Command no longer supported, functions suplanted by systemd)
consoletype.pp(Command should no longer be used, suplanted by systemd-logind)

Fedora 19 Modules Renamed or Consolodated
amavis.pp clamav.pp - These have been consolodated into a unified view of antivirus.pp, All aliased o antivirus_t.
    typealias antivirus_t alias { amavis_t clamd_t clamscan_t freshclam_t } ;

ctdbd.pp changed name upstream to ctdb.pp
isnsd.pp changed name upstream to isnd.pp
pacemaker.pp and corosync.pp rgmanager.pp aisexec.pp - These have been consolodated into a unified view of rhcs.pp, all aliased to the new type cluster_t.
     typealias cluster_t alias { aisexec_t corosync_t pacemaker_t rgmanager_t }

Dan Walsh: Security Vs Usability

dwalsh@redhat.com — 2013-03-15T14:59:02+00:00

One of the interesting things about working in the security field, is walking the balance between security and usability.

On one of the many mailing lists I read, an admin as complaining about his Apache server being hacked. Some application had been hacked in a way that it got apache to write to a particular directory and then executed the code it has written.

I decided to look at how SELinux Policy controlled httpd_t. I wanted to know what file types was httpd_t allowed to write and execute.

In Fedora 19, I executed the following command.

> sesearch -A -C -s httpd_t -p execute -c file | grep write
DT allow httpd_t httpdcontent : file { ioctl read write create getattr setattr lock append unlink link rename execute open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]

This indicates that the apache deamon (httpd_t) is allowed to write and execute files that have a label that has the attribute httpdcontent. But they would have to have the httpd_enable_cgi, httpd_unified, and httpd_builtin_scripting booleans turned on.

#semanage boolean -l | grep httpd_enable_cgi
httpd_enable_cgi               (on   ,   on) Allow httpd cgi support
# semanage boolean -l | grep httpd_unified
httpd_unified                  (off , off) Unify HTTPD handling of all content files.
# semanage boolean -l | grep httpd_builtin_scripting
httpd_builtin_scripting        (on   ,   on) Allow httpd to use built in scripting (usually php)

Out of the box we enable httpd_enable_cgi, so cgi scripts will run with your apache server. We also enable httpd_builtin_scripting, which allows you to run php scripts within the same processes as apache, this also enabled other builtin scripting tools like mod_python and mod_perl.

We disable httpd_unified, which basically says httpd_t has full access to all httpdcontent files.

# seinfo -ahttpdcontent -x
   httpdcontent
      httpd_sys_content_t
      httpd_user_ra_content_t
      httpd_user_rw_content_t
      httpd_sys_ra_content_t
      httpd_sys_rw_content_t
      httpd_user_content_t

So rather then treating each type differently we combine all access. We used to have this turned on by default for people who did not understand SELinux, probably still is in RHEL5 and maybe RHEL6. But in latest Fedora and RHEL7 we will turn it off by default.

If you are running a web site that does not do any scripting, it would probably be advisable to turn off the other two booleans.

Dan Walsh: SELinux Reveals Bugs in Code

dwalsh@redhat.com — 2013-03-14T18:35:27+00:00

I have noticed over the years random confined process that get avc denials for the SYS_RESOURCE and SYS_ADMIN capabilities. Most of the time, these are not easily repeated. The combination of these two usually indicate a confined processes is attempting to use a system resources beyond the limits for the owner UID. For example in RHEL6 a user, dwalsh, is only allowed to run 1025 processes, and an individual process running as dwalsh, is only allowed to open 1024 files.

/usr/include/linux/capability.h documents SYS_RESOURCE as the following

/* Override resource limits. Set resource limits. */
/* Override quota limits. */
/* Override reserved space on ext2 filesystem */
/* Modify data journaling mode on ext3 filesystem (uses journaling
   resources) */
/* NOTE: ext2 honors fsuid when checking for resource overrides, so
   you can override using fsuid too */
/* Override size restrictions on IPC message queues */
/* Allow more than 64hz interrupts from the real-time clock */
/* Override max number of consoles on console allocation */
/* Override max number of keymaps */

The goal of these limits is to prevent an individual user from doing a fork bomb or opening so many files the system gets a Denial of Service.

Even root processes are governed by these limits, however root processes almost always have SYS_ADMIN and SYS_RESOURCE capabilities, unless they have dropped them using something like libcap/libcap-ng or you are using an Mandatory Access System like SELinux.

Lon Hohberger, who is working on the OpenStack team at Red Hat and currently working on making SELinux work well with OpenStack, discovered some problems in RHEL6, that could and probably are triggering these AVC's.

Bug #1

Prior to RHEL6.4 ANY login to the system, including root, would get a process limit of 1024.

# ulimit -u
1024

Meaning if you started any processes on a system that already had 1025 processes running, the kernel would be checking SYS_RESOURCE. If you executed a command like

# service httpd restart

Then httpd would fall under the same limits, since httpd_t is not allowed these Capabilities, httpd_t would generate the AVC's and probably fail to start.

Worse then this, if you executed:

# yum -y update

There is a decent chance that during the update some packages post install would do a

# service foobar restart

If foobar was confined by SELinux, then the AVC could be generated.

Luckily we have had a fix for this in RHEL6.4, although this fix has not gone into Fedora yet...

The following line as added to /etc/security/limits.d/90-nproc.conf

root soft nproc unlimited

BUG #2

First if you login as root to a RHEL6.4 system, and check the max processes limit, you will get something like:

# ulimit -u
29924

If you login as a normal user you would get:

> ulimit -u
1024

If you run su from your normal user account and check the ulimit you get:

# ulimit -u
29924

But if you run sudo as a normal user and run ulimit you get:
# ulimit -u
1024

su and sudo should work the same way.

This is probably a bug in sudo or in the sudo pam stack. Have not determined which yet.

BUG #3

This one might be controversial, since these limits are supposed to count the resources used by a particular UID, we should be looking at ALL of the processes kicked off by the user, not only those running under his UID.    Since sudo in the above example was not modifying the maximum running processes when user dwalsh became root, the process started counted against the total number of root processes rather then the total number of processes started by dwalsh. I believe this is wrong. The kernel should be counting the number of processes started by user dwalsh and should look at the LoginUID rather then the actual UID. Now if dwalsh logged onto a system and was able to get some processes running as root, they could continue to count against dwalshs resource constraints and not against the systems.    I realize this might be difficult since you would probably want processes that have the SYS_RESOURCE capability to not count against the total.

systemd to the rescue

systemd has helped fix a lot of these issues.

In RHEL6 if an admin starts/restarts a system daemon, that daemon ends up being a subprocess of the user, meaning inherits any of the constraints on the user processes. In the latest Fedora's, systemd starts most system daemons. The user process sends a message to systemd and systemd starts/restarts the service, which means the service gets the system constraints not the user constraints.

KaiGai Kohei: OpenCLでCPU/GPUを使い分ける？

kaigai — 2013-03-07T23:00:00+00:00

最近、PG-Stromに興味があるという方からちょくちょく、個別に質問メールを頂く事がある。

その中で頂いたコメントに興味深い洞察が。

GPUによるアクセラレーションは確かに興味深い機能だけれども、PG-Stromの本質は突き詰めていえばパイプライン処理のお化けだよね？だから、計算処理をCPUでやるようにしても良いんじゃない？

確かに。GPUによる並列処理はハマると物凄い費用対効果をもらたすけれども、例えば正規表現マッチみたく、GPU向きじゃない処理もある。

PG-Stromの場合、SQLのWHERE句に与えられた条件から行を評価する関数を自動的に生成、それをJIT コンパイルして実行する。たぶん、プランナの時点でCPU実行用、GPU実行用の２種類の関数を自動的に生成して、計算サーバに渡すという処理は実現可能だろう。

NVidiaのGPUを前提とするCUDAと異なり、OpenCLはAMDのGPUやIntelのXeon Phiもサポートする。それどころか、OpenCL Cで書かれたコードをCPU用にコンパイルする事も可能。

その辺の事情もあり、今、PG-StromをOpenCLで再実装し直している。(works in progress)

だが、CPUとGPU用にそれぞれ計算サーバ書くのか、実装が複雑になってやだなぁ～と思っていたところ、実は勘違いである事が判明。

以下のgpuinfoコマンドの出力は、NVidiaのCUDA 4.2と、IntelのOpenCL SDKをインストールした環境でのもの。

なんと、Platform-1でGPUが、Platform-2でCPUが認識されている。

NVidiaのOpenCLライブラリでも、IntelのOpenCLライブラリでも同様。

という事はですよ、要求された計算の特性に応じて、1個の計算サーバでCPU/GPUを使い分けるという芸当もできるという事になるじゃありませんか。

いやー、面白い。実装意欲を掻き立てられる。

なお、以下のコマンド gpuinfo のURLは↓です。

https://github.com/kaigai/gpuinfo

[kaigai@iwashi gpuinfo]$ ./gpuinfo
platform-index:      1
platform-vendor:     NVIDIA Corporation
platform-name:       NVIDIA CUDA
platform-version:    OpenCL 1.1 CUDA 4.2.1
platform-profile:    FULL_PROFILE
platform-extensions: cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing
 cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll
  Device-01
  Device type:                     GPU
  Vendor:                          NVIDIA Corporation (id: 000010de)
  Name:                            GeForce GT 640
  Version:                         OpenCL 1.1 CUDA
  Driver version:                  310.32
  OpenCL C version:                OpenCL C 1.1
  Profile:                         FULL_PROFILE
  Device available:                yes
  Address bits:                    32
  Compiler available:              yes
  Double FP config:                Denorm, INF/NaN, R/nearest, R/zero, R/INF, FMA
  Endian:                          little
  Error correction support:        no
  Execution capability:            kernel, native kernel
  Extensions:                      cl_khr_byte_addressable_store cl_khr_icd \
   cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query \
   cl_nv_pragma_unroll  cl_khr_global_int32_base_atomics \
   cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics \
   cl_khr_local_int32_extended_atomics cl_khr_fp64
  Global memory cache size:        32 KB
  Global memory cache type:        read-write
  Global memory cacheline size:    128
  Global memory size:              2047 MB
  Host unified memory:             no
  Image support:                   yes
  Image 2D max size:               32768 x 32768
  Image 3D max size:               4096 x 4096 x 4096
  Local memory size:               49152
  Local memory type:               SRAM
  Max clock frequency:             901
  Max compute units:               2
  Max constant args:               9
  Max constant buffer size:        65536
  Max memory allocation size:      511 MB
  Max parameter size:              4352
  Max read image args:             256
  Max samplers:                    32
  Max work-group size:             1024
  Max work-item sizes:             {1024,1024,64}
  Max write image args:            16
  Memory base address align:       4096
  Min data type align size:        128
  Native vector width - char:      1
  Native vector width - short:     1
  Native vector width - int:       1
  Native vector width - long:      1
  Native vector width - float:     1
  Native vector width - double:    1
  Preferred vector width - char:   1
  Preferred vector width - short:  1
  Preferred vector width - int:    1
  Preferred vector width - long:   1
  Preferred vector width - float:  1
  Preferred vector width - double: 1
  Profiling timer resolution:      1000
  Queue properties:                out-of-order execution, profiling
  Sindle FP config:                Denorm, INF/NaN, R/nearest, R/zero, R/INF, FMA

platform-index:      2
platform-vendor:     Intel(R) Corporation
platform-name:       Intel(R) OpenCL
platform-version:    OpenCL 1.2 LINUX
platform-profile:    FULL_PROFILE
platform-extensions: cl_khr_fp64 cl_khr_icd cl_khr_global_int32_base_atomics \
  cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics \
  cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store \
  cl_intel_printf cl_ext_device_fission cl_intel_exec_by_local_thread
  Device-01
  Device type:                     CPU
  Vendor:                          Intel(R) Corporation (id: 00008086)
  Name:                                   Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
  Version:                         OpenCL 1.2 (Build 56860)
  Driver version:                  1.2
  OpenCL C version:                OpenCL C 1.2
  Profile:                         FULL_PROFILE
  Device available:                yes
  Address bits:                    64
  Compiler available:              yes
  Double FP config:                Denorm, INF/NaN, R/nearest, R/zero, R/INF, FMA
  Endian:                          little
  Error correction support:        no
  Execution capability:            kernel, native kernel
  Extensions:                      cl_khr_fp64 cl_khr_icd \
    cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics \
    cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics \
    cl_khr_byte_addressable_store cl_intel_printf cl_ext_device_fission \
    cl_intel_exec_by_local_thread
  Global memory cache size:        256 KB
  Global memory cache type:        read-write
  Global memory cacheline size:    64
  Global memory size:              386942 MB
  Host unified memory:             yes
  Image support:                   yes
  Image 2D max size:               16384 x 16384
  Image 3D max size:               2048 x 2048 x 2048
  Local memory size:               32768
  Local memory type:               DRAM
  Max clock frequency:             2600
  Max compute units:               32
  Max constant args:               480
  Max constant buffer size:        131072
  Max memory allocation size:      96735 MB
  Max parameter size:              3840
  Max read image args:             480
  Max samplers:                    480
  Max work-group size:             1024
  Max work-item sizes:             {1024,1024,1024}
  Max write image args:            480
  Memory base address align:       1024
  Min data type align size:        128
  Native vector width - char:      16
  Native vector width - short:     8
  Native vector width - int:       4
  Native vector width - long:      2
  Native vector width - float:     4
  Native vector width - double:    2
  Preferred vector width - char:   16
  Preferred vector width - short:  8
  Preferred vector width - int:    4
  Preferred vector width - long:   2
  Preferred vector width - float:  4
  Preferred vector width - double: 2
  Profiling timer resolution:      1
  Queue properties:                out-of-order execution, profiling
  Sindle FP config:                Denorm, INF/NaN, R/nearest

Joshua Brindle: Security Anti-Pattern - Mobile Hypervisors (for user facing VM's)

2013-02-11T06:00:00+00:00

One of the things I was working on for most of 2012 was mobile security, specifically SE Android.

My exposure to mobile was limited to using smart phones and making minor customizations to third party ROM's before 2012.

That would all change. A group of us started looking at a specific RFP that many believed would be the major mobile entréinto the federal government and military. It wasn't. It turned into a fiasco.

What it did do, however, was solidify many people's belief that hypervisors on mobile platforms was the way to achieve multi-level cross domain access. It convinced me that they couldn't be more wrong.

Since then, my colleagues and myself were on a mission to convince the world that virtualization on mobile for security is the wrong answer. Now that I am out on my own I want to take this opportunity to share some of my own beliefs on the matter.

First a CYA part: Although these beliefs were formed while I was working elsewhere I have no reason to believe they are proprietary and I don't, in any way, represent anyone except myself.

The Fiasco

At the beginning I, like everyone else, had no reason to doubt all the vendors out there selling mobile virtualization solutions. After all, they had demos, they had huge numbers like deployed on 1.5 billion devices. Many proposal writers would have been satisfied with this and gone to the next issue. However, because of the insane schedule requirements of this particular RFP I wanted to make sure there was software available today (which was March, 2012) that could be used immediately, on hardware that was already available.

Boy, that is an interesting rabbit hole. Anyone working in mobile knows that information in general is hard to come by. Anecdotally, people working at major mobile device manufacturers sometimes have trouble getting spec sheets for their own phones. Mobile hypervisors are no exception, and possibly worse.

Unlike Intel, which makes its own chips, ARM does not. Instead they license the chip designs to chip makers. Those makers, in general, are free to pick and choose various capabilities, extended instruction sets, add proprietary instruction sets, etc. They can even choose the endieness. This does not make a friendly environment for people who need to work very closely to the hardware, like a hypervisor developer.

Like Intel, ARM has virtualization extensions. For quite a while, in fact. ARM also has TrustZone, which is made for DRM, but provides a secure-world split from the rest of the system, and can be used for a hypervisor. The challenge at the time was that there were no mobile phones on the market that implemented either of these completely, correctly, or enabled. Further, TrustZone configuration is available only to the chip maker. This means that hypervisors that run on these technologies quite possibly work, on a development board, but not on any phones. Finally, a hardware vendor admitted that they never enable things like TrustZone because they didn't want to get into the key management business. Yay.

Well, there is still paravirtualization, right? Paravirtualization is great, really. Except that it requires modifying the OS, more specifically it means modifying the drivers. So, onto lesson #2 for the mobile noobs. No one gets driver source code except the chip manufacturers. That includes the people packaging them up into boards, the people building phones, the people building the OS for the phones, etc. Some chip manufacturers won't even let Google release binary blobs of their drivers on the website for Nexus devices, despite the fact that Nexus owners can unlock their phones and pull them all off.

One conclusion was that, while someone with deep connections to the chip makers might be able to eventually produce a phone that can run a hypervisor for multiple guest operating systems, it wasn't happening with phones on the market at the time, it wasn't happening within the schedule of this particular RFP, and it certainly wasn't going to be us doing it.

Reset

So, now the belief I went into this with has been broken down. Why did we have that belief at all? Why did we start thinking it was the right answer? We fell into the same trap that everyone else did. The Cross Domain Solution community has forgotten its heritage. Virtualization has become the magic bullet for cross domain access solutions, but why?

Once upon a time there were many trusted operating systems. They were mostly based on their non-trusted siblings. The names were straightforward; you had Trusted Solaris, Trusted IRIX, Trusted Xenix, etc. These were evaluated. You could run applications at multiple levels on them just fine. And people did, just not very many people.

By the end of the UNIX wars, most of these systems were Trusted Solaris, but they still weren't in huge use. Most people had settled on Windows for their standard tasks. Windows applications didn't run on Trusted Solaris. In fact, modern Solaris applications didn't run on Trusted Solaris, which was typically a couple major releases behind.

What to do? Well, SELinux was being developed. Virtualization was becoming possible on x86. The NSA tied the 2 together and released NetTop. You could now run Windows apps at multiple levels right next to each other on the same system, albeit very slowly. Then there were the various HAP (High Assurance Platform) projects, and other variations. Long story short, people started defaulting to 'virtualize for cross domain access', without even thinking.

For mobile this trap can be avoided entirely. You have a platform, and people are using apps written for that platform, not for another platform. You don't need to virtualize to run the apps you want.

Security Anti-pattern

Up until now I've been focusing on why hypervisors aren't there for mobile, and why that was the default thought anyway, but not much about the security anti-pattern part. So lets get started on that.

Mobile security is an interesting beast. It has all the issues of regular computing and a whole host of its own.

Power Management

Take power management, for example. On mobile systems you want the main application processor powered down as often as possible. How do you do that while maintaining a nice user experience? You don't want an app sitting in the background constantly polling for email, killing your battery, but you also don't want everything to fire up and go download data the instant the user unlocks the device, since that will make it unusable for some amount of time. Google implemented wakelocks for this purpose. They allow apps to notify the kernel that they are doing something, and that the kernel shouldn't put the device to sleep. You also want apps to be able to simultaneously use wakelocks, and let the system sleep sooner.

Now, instead of just getting to the kernel above the apps, those wakelocks would need to make it all the way to the hypervisor. Further, without sharing wakelocks between VM's you'll have the same power draining serial usage of processor awake time.

See what I did there? Automatic info-flow between VM's, regardless of whether you do it or not. If VM1 is doing something it'll keep the processor awake, VM2 will know. If you share wakelocks and VM1 is doing something VM2 will know.

The old trusty high assurance MILS way of fixing this? Fixed time-slice scheduling. Give each VM X amount of time, move on to the next when time is up. In this world, how will the hypervisor know when to sleep? How do you manage talking on the phone, a somewhat real-time activity, if you are cycling through VM's? Finally, what is someone going to do with a phone that has a 1 hour battery life because VM's can't cooperate?

So, choose between punching a hole in the hypervisor or getting miserable power performance.

Holes, holes everywhere

I already mentioned the issue with drivers. The current solution for hypervisors is to pass device access straight through to one (or more) of the VM's.

This is pretty standard for all virtualization based cross domain solutions, actually. Hypervisors are suppose to be small, they can't have a graphics subsystem. By using an IOMMU they assign a single VM to manage graphics (and nothing else) and then assign the DMA memory range of the device to that VM. No other VM can access that memory, so then you build one-way pipelines from all the VM's to the graphics VM and let it do compositing, etc.

As a sidenote, none of the solutions I know of actually have shared 3d acceleration, if you need 3d acceleration you have to lock a single VM to a video card.

So, back to mobile. You might be able to find an SoC with a working IOMMU, but I wouldn't count on it. I could find nothing of the sort back then.

This same method is used for all kinds of devices, such as networking. With networking, however, you now have 2-way communication. High assurance systems will need separate network cards that can each be assigned to a single VM. How do you do this on a mobile device, where there is generally one cellular radio? Typically the idea is that you have separate encryption VM's for each user facing VM.

How many device VM's are you willing to have? How many paths through the hypervisor do you open? How much security do you end up having when every device is shared between all VM's? What is the performance and power penalty if a simple action like downloading some data from a website, storing it to the filesystem and displaying a message to the screen involves no fewer than 4 VM's?

In the end you have VM's that are trusted to do the separation between user-facing VM's instead of having the hypervisor solely doing that. This means that all those assurance arguments and the fact that your hypervisor only has 10k lines of code is irrelevant. You've just added a bunch of Linux kernels to your trusted base.

In desktop virtualization based solutions these device managing VM's were typically SELinux systems. SE Android could be similarly used to lock down these systems, and at the time it was just being released. I figured that since it had to be done anyway, in order for the hypervisor use case to ever work, I might we well focus on it. At least then there would be a secure platform that could be used until the whole hypervisor thing got resolved. At this point my opinion is that even if they are available and working they aren't worth it, but I know many who disagree.

Functionality

Security is always at odds with functionality, by definition. Mobile users have fairly high expectations of their devices. One example is the ability to receive phone calls. Personally I have bad experiences with my smart phones receiving phone calls without extra security so this is a serious uphill battle.

So, if a user is using a secret level VM, and his child's school calls on the unclass VM to tell him that his child has been hurt and is going to the hospital, should he be able to be receive that call? I don't think many people would want to use these devices if the answer is no, but what does saying yes entail? More holes punched through the hypervisor? Probably, but you've already made plenty of those.

How about the baseband processor? Oh, right, I haven't mentioned that yet. Pretty much every smart phone has a whole 'nother processor, operating system and software stack connected to the radio. Sometimes this processor is actually primary (it bootstraps and starts the application processor).

So, on some smart phones the baseband processor is connected directly to the microphone. Obviously while in the secret VM access to the microphone must be restricted. What does this mean? There must be a VM managing communication with the baseband processor, so it is going to have to make the hard decision as to allow the microphone to be used while a secret VM is active. This, obviously, opens all sorts of serious issues.

There are many other examples of this. Switching between 5 VM's to check email isn't going to make anyone happy. Not getting text messages from the wife while at work may not make your home life better.

Conclusion

You'll notice that the title of this entry specifically mentions user facing VM's on mobile devices. I do not object to using a hypervisor in conjunction with a specialized integrity measurement and monitoring system for attestation purposes. The device access necessary to such a VM would be minimal, and it would only need to do something when an attestation request was made, so it has no reason to wake up the phone. It also doesn't add many VM's that need to constantly be scheduled.

I do object to the sentiment that a hypervisor is required for multi-level cross domain access on a mobile device. I believe the sentiment is guided by where the desktop multi-level market landed, without the requirements that got it there. Additionally, I believe, by the time you have a functional implementation you won't have any more assurance than running an SE Android system that implements multi-level access controls. On top of that, the system will be significantly less usable, battery life and performance will suffer, and you'll never get away from having to modify the underlying OS anyway.

SE Android is being developed at a rapid pace and new features are added often. I can't wait to see where it goes, but I hope the hypervisor evangelists aren't able to take the steam out of it before it gets there.

Joshua Brindle: Big changes

2013-02-06T06:00:00+00:00

New blogging system... Also I left Tresys.

After almost 9 years there I have resigned, which was a hard thing to do.

Spencer Shimko, Brandon Whalen and I left Tresys a couple weeks ago to start our own company, Quark Security. That decision wasn't easy but it is a good time in our careers and we all believe that we are prepared to succeed running our own company. We were joined by an ex-Tresys employee, Ed Sealing.

So, after a very crazy 2012, almost entirely focusing on mobile security for me, we are going forward, trying to figure out how to make our mark on the world. We are learning about the nitty gritty details about government contracting that we were never exposed to before. It is all very fascinating and definitely unlike what I've done before.

Strangely enough, my workload is much lighter at the moment, than it was before I left, so I hope to be able to spend some time writing up my thoughts on various things, including mobile security, before I get ramped back up to pre-leaving workloads.

James Morris: Save the Date: 2013 Linux Security Summit

jamesm — 2013-02-04T04:38:37+00:00

This year’s Linux Security Summit will be co-located with LinuxCon (along with Linux Plumbers) in New Orleans, USA, on the 19th and 20th of September.

The format is expected to be similar to the 2012 summit.

A CfP will be issued soon.

Russell Coker (security): SE Linux Things To Do

etbe — 2013-01-30T21:16:33+00:00

At the end of my talk on Monday about the status of SE Linux [1] I described some of the things that I want to do with SE Linux in Debian (and general SE Linux stuff). Here is a brief summary of some of them:

One thing I’ve wanted to do for years is to get X Access Controls working in Debian. This means that two X applications could have windows on the same desktop but be unable to communicate with each other by any of the X methods (this includes screen capture and clipboard). It seems that the Fedora people are moving to sandbox processes with Xephyr for X access (see Dan Walsh’s blog post about sandbox -X [2]). But XAce will take a lot of work and time is always an issue.

An ongoing problem with SE Linux (and most security systems) is the difficulty in running applications with minimum privilege. One example of this is utility programs which can be run by multiple programs, if a utility is usually run by a process that is privileged then we probably won’t notice that it requires excess privileges until it’s run in a different context. This is a particular problem when trying to restrict programs that may be run as part of a user session. A common example is programs that open files read-write when they only need to read them, if the program then aborts when it can’t open the file in question then we will have a problem when it’s run from a context that doesn’t grant it write access. To deal with such latent problems I am considering ways of analysing the operation of systems to try and determine which programs request more access than they really need.

During my talk I discussed the possibility of using a shared object to log file open/read/write to find such latent problems. A member of the audience suggested static code analysis which seems useful for some languages but doesn’t seem likely to cover all necessary languages. Of course the benefit of static code analysis is that it will catch operations that the program doesn’t perform in a test environment – error handling is one particularly important corner case in this regard.

Russell Coker (security): My SE Linux Status Report – LCA 2013

etbe — 2013-01-28T02:56:30+00:00

This morning I gave a status report on SE Linux. The talk initially didn’t go too well, I wasn’t in the right mental state for it and I moved through the material too fast. Fortunately Casey Schaufler asked some really good questions which helped me to get back on track. The end result seemed reasonably good. Here’s a summary of the things I discussed:

Transaction hooks for RPM to support SE Linux operations. This supports signing packages to indicate their security status and preventing packages from overwriting other packages or executing scripts in the wrong context. There is also work to incorporate some of the features of that into “dpkg” for Debian.

Some changes to libraries to allow faster booting. Systems with sysvinit and a HDD won’t be affected but with systemd and SSD it makes a real difference. Mostly Red Hat’s work.

Filename transition rules to allow the initial context to be assigned based on file name were created in 2011 but are not starting to get used.

When systemd is used for starting/stopping daemons some hacks such as run_init can be avoided. Fedora is making the best progress in this regard due to only supporting systemd while the support for other init systems will limit what we can do for Debian. This improves security by stopping terminal buffer insertion attacks while also improving reliability by giving the daemon the same inherited settings each time it’s executed.

Labelled NFS has been accepted as part of the NFSv4.2 specification. This is a big deal as labelled NFS work has been going for many years without hitting such a milestone in the past.

ZFS and BTRFS support but we still need to consider management issues for such snapshot based filesystems. Filesystem snapshots have the potential to interact badly with relabelling if we don’t develop code and sysadmin practices to deal with it properly.

The most significant upstream focus of SE Linux development over the last year is SE Android. I hope that will result in more work on the X Access Controls for use on the desktop.

During question time I also gave a 3 minute “lightning talk” description of SE Linux.

Dan Walsh: Where did audit2allow go in Fedora 18?

dwalsh@redhat.com — 2013-01-18T14:37:20+00:00

One of the goals of Fedora 18 is to shrink the size of the Minimal install as much as possible. We are concentrating on keeping this minimal.

Since a minimal install machine does not need to do SELinux policy development, it was decided to remove the selinux-policy-devel package from the minimal install, which is fairly large. But audit2allow was in policycoreutils-python, and required the selinux-policy-devel package. audit2allow needs the interface files in selinux-policy-devel package in order for audit2allow -R to work.

I decided to move the audit2allow script to policycoreutils-devel package, since its main job is to help develop selinux-policy.
If you do not find audit2allow you your system, just

yum install policycoreutils-devel
or
yum install /usr/bin/audit2allow

Note: The latest setroubleshoot-server package requires policycoreutils-devel, so if you have this installed you will get audit2allow for free...

Dan Walsh: rsync and SELinux

dwalsh@redhat.com — 2013-01-07T16:28:59+00:00

I have been pinged by a couple of users having problems with SELinux and rsync. We began confining the rsync service back in RHEL5.

The biggest problem SELinux has with rsync is there is no way to distinguish between the client and the server from an SELinux point of view.

rsync as a daemon

If someone sets up an rsync service to listen for connections they use the /usr/bin/rsync executable. In order to confine this application we label /usr/bin/rsync as rsync_exec_t. The init daemons (init_t, initrc_t) will transition to rsync_t when they execute /usr/bin/rsync. SELinux policy allows share parts of the host, mainly readonly, and allows admins to setup directories labeled rsync_data_t where content could be uploaded to the rsync domain.

There are lots of booleans defined for rsync_t to share data. On Fedora 18, I see.

getsebool -a | grep rsync
postgresql_can_rsync --> off
rsync_anon_write --> off
rsync_client --> off
rsync_export_all_ro --> off
rsync_use_cifs --> off
rsync_use_nfs --> of

man rsync_selinux

to see more info.

rsync as a client.

If you execute rsync as a client from a user script, everything works fine, since we do not transition from unconfined_t or other user domains to rsync_t, rsync runs within the user domain and is able to read/write anything the user process label is allowed to read/write.

If a service that SELinux does not have policy runs runs within the init system and attempts to use rsync as a client it can have problems. You see the service running within the init system that has no policy will run as either init_t or initrc_t. When a process running as init_t or initrc_t executes /usr/bin/rsync (rsync_exec_t), the rsync process will transition to rsync_t and SELinux will treat it as the rsync daemon not as a client.

There are many possible solutions for this problem.

Best would be to write policy for the init service that is currently running without confinement. I realize that most users will not do this, but you could contact us for help.
In RHEL5 you could turn on the rsync_disable_trans boolean. Which will stop the transition from initrc_t to rsync_t, and rsync_t would just tun in initrc_t domain, which by default is an unconfined domain.
You could use audit2allow to add all of the rules to rsync_t to allow it to run as a client.
You could change the label of /usr/bin/rsync to bin_t using semanage fcontext -m -t bin_t /usr/bin/rsync which would also stop the transition.
You could make rsync_t an unconfined domain.

There are many ways of fixing this problem. And perhaps I need to talk to the rsync packagers to see if we could figure a better way of handling this in the future.

Russell Coker (security): Finding an ATM Skimmer

etbe — 2012-12-23T01:08:49+00:00

A member of SAGE-AU [1] found two ATM skimmers [2] and gave me permission to publish his description and analysis of the situation. I’ve lightly edited this from a mailing list post to a blog format with permission from the author. This Courier-Mail article refers to the skimmers in question [3].

People were wondering what gave the skimmers away so here goes, NB this is only about the 2 I discovered.

The actual atms in question were the free standing type (but even this doesn’t matter in the scheme of things because they can be on those in a bank of the things).
I’d actually conducted transaction and was waiting for my card to come out of the machine – these things looked that good. The colours matched – especially in the 3/4 or less light that you typically have on the fascia’s of such machine. The backing plate grey matched atm fascia as did the green “bubble” where the card goes.
WHAT REALLY CAUSED SUSPICION – my card was having difficulty coming out of the atm at end of transaction i.e. card coming out extra slow – then only the end couple of mm, I had to physically grab my card with fingertips to get it out and there was barely perceptible movement of skimmer due to my fingers using the green “bubble” as purchase point, THAT was what made me suspect. I then really had close look and found that I could move the “bubble” with its backing plate – I pulled it off the machine and then looked at the atm next to it and found it to look exactly the same. These things are held on by double sided tape.
Grabbed the cleaning lady wandering past showed her the device and asked her to get security. Security and centre operations manager subsequently showed up, while waiting for them I had to stop people from using either machine (everyone amazed at how good these things looked). Centre ops guy went and checked other machines in the centre, I left my details and they called the cops… I went straight to my credit union and reported what had happened and they cancelled my card and ordered a new one on the spot for me.
Coincidently (or not) the centre ops and security lady told me that the machines had been serviced (refilled) not too much earlier that day – i.e. I wondered if the bad guys did the “service” or were tracking armaguard servicing types.

Quick side notes:

3 more skimmers have been found since then.
Subsequently, I found out these were the type that needed to be picked up for the bad guys to retrieve the data i.e. these weren’t the type that transmitted to some-one sitting near by via Bluetooth/wireless i.e. in this instance I need not have cancelled my card and gotten a new one from my credit union.
HOWEVER, it is best practice if you discover one and you’ve used that machine to immediately have your financial institution cancel your card and issue you a new one – though getting the new one can take up to a week.
As I understand it, These 2 devices (i.e. others could be different) have 2 usb ports one for the reader and the other to a pinhole camera (commercially available type removed from it’s original housing). The magnetic stripe data is held on the audio track associated with the video and there was an 8GB storage card to hold it all i.e. it makes things easier for the bad guys to match PINs to card details.
If you do find a skimmer DO NOT touch the insides (non public facing parts) of it – this is where the cops can really try lift dna and prints from; gathering prints from externally is far more fraught as everyone and their dog has probably touched the exterior of the skimmer.
In the lead up to Xmas these things or similar are highly likely to become more prevalent as we all go about parting with dosh while gift shopping – SO BE AWARE AND CAREFUL.

KaiGai Kohei: SE-PostgreSQLでリモートプロセスのセキュリティラベルを使用する

kaigai — 2012-12-06T05:26:19+00:00

PostgreSQL Advent Calendar 2012に参加しています。

何を設定する必要があるのか？

何か世のため人のためになりそうなネタは・・・という事で、SE-PostgreSQLでリモートプロセスのセキュリティラベルを使用する方法をまとめてみました。

v9.1からサポートされたSE-PostgreSQLは、OSの機能であるSELinuxと連携して、SQLを介したDBオブジェクトへのアクセスに対して強制アクセス制御を行う機能です。
かいつまんで言えば、○○のテーブルは機密度の高い情報を持っている、□□は機密度が低いと言った形で、PostgreSQL標準のDBアクセス制御機能に加えて、OSのセキュリティポリシーに従ってアクセス制御を行います。そのため、同じ”情報”であるにも関わらず、保存先がファイルかデータベースかといった”格納手段”によって異なるポリシーでアクセス制御が行われる事を避ける事ができます。
SE-PostgreSQLが追加のアクセス制御を行う際には、『誰が（subject）』『何に（object）』『何をする（action）』のかをひとまとめにして、OSの一部であるSELinuxに伺いを立てるのですが、この時に『誰が』『何に』を識別するために、セキュリティコンテキストと呼ばれる特別な識別子が使用されます。
セキュリティコンテキストというのはこんな感じです。ファイルのセキュリティコンテキストを確認するには ls -Z を、プロセスの場合は ps -Z や id -Z を実行して確認できます。

[kaigai@iwashi ~]$ ls -Z
drwxr-xr-x. kaigai users unconfined_u:object_r:user_home_t:s0 patch/
drwxr-xr-x. kaigai users unconfined_u:object_r:user_home_t:s0 repo/
drwxr-xr-x. kaigai users unconfined_u:object_r:user_home_t:s0 rpmbuild/
drwxr-xr-x. kaigai users unconfined_u:object_r:user_home_t:s0 source/
drwxr-xr-x. kaigai users unconfined_u:object_r:user_home_t:s0 tmp/
[kaigai@iwashi ~]$ ps -Z
LABEL                             PID TTY          TIME CMD
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 28791 pts/4 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 29093 pts/4 00:00:00 ps

DBオブジェクトの場合はSECURITY LABEL構文を用いて設定できるほか、システムビューのpg_seclabelsを用いて参照する事ができます。

postgres=# SELECT provider,label FROM pg_seclabels
              WHERE objtype = 'table' AND objname = 't1';
 provider |                  label
----------+------------------------------------------
 selinux  | unconfined_u:object_r:sepgsql_table_t:s0
(1 row)

そしてDB利用者の場合。やっと今回の記事の主題にたどり着けたワケですが、SE-PostgreSQLは『接続元プロセスのセキュリティコンテキスト』をDB利用者のセキュリティコンテキスト（= DB利用者の権限）として扱います。

SELinuxはgetpeercon(3)というAPIを持っており、この人はソケットのファイルディスクリプタを引数として与えると、接続相手のセキュリティコンテキストを返します。SE-PostgreSQLはこのAPIを使用して『接続元プロセスのセキュリティコンテキスト』を取得しています。
で、UNIXドメインソケットによるローカル接続の場合は特別な設定は何も必要ないのですが、TCP/IPによるリモート接続の場合、OSは相手側プロセスの情報を持っていないため、ネットワーク接続の確立に先立って双方のセキュリティコンテキストを交換する Labeled Network の設定を行う必要があります。
この機能、Linux kernel 2.6.16 からサポートされた機能で、IPsecの鍵交換デーモンである racoon と連携してネットワーク接続先とセキュリティコンテキストを交換します。つまり、IPsecで通信経路が保護されている（少なくとも、改ざん検知できる）事が前提です。IPsecが前提ですよ。大切な事なので２回書きました。

Linux kernelのバージョンからも分かるようにそれほど新しい機能ではないのですが、意外と設定手順がドキュメント化されていませんので、少しまとめてみました。

テスト環境の構成

IPsecの設定を極める事が目的ではありませんので、今回は、最も単純なHost-to-HostのPSK(Pre-Shared Key)の構成でIPsec通信経路を作成します。その上で、Labeled Networkの設定を追加する事にします。

今回のテスト環境では、2台のホストをそれぞれサーバとクライアントに見立てて設定を行いました。kg1(192.168.1.42)がクライアント、kg2(192.168.1.43)がサーバであると想定し、この2台の間にIPsecの接続を設定します。ディストリビューションは Fedora 17 を使用し、Development Workstation構成でクリーンインストールしました。

なお、IPsec接続の設定に関してはFedora Projectのドキュメントを参考にしています。
詳しくはIPsec Host-to-Host Configurationを参照してください。

事前の設定

パッケージの追加

インストール直後の状態では ipsec-tools と system-config-network パッケージが導入されていませんので、両ホストでこれらのパッケージをインストールします。

# yum install -y ipsec-tools system-config-network

また、サーバ側には postgresql-server と postgresql-contrib パッケージが、クライアント側には postgresql パッケージが必要です。

# yum install -y postgresql-server postgresql-contrib

# yum install -y postgresql

ファイアウォールの設定

IPsecの鍵交換デーモンの通信とPostgreSQLサーバへの接続にはファイアウォールの設定変更が必要です。
system-config-firewallを実行して関連するポートを解放してください。

IPsecの鍵交換デーモン用ポートは、サーバ側/クライアント側の双方で解放が必要です。

PostgreSQLサーバ用ポートは、サーバ側で解放が必要です。

これらの設定を保存し、有効化してください。

NetworkManagerの無効化

ちょっとダサいのですが、NetworkManager経由でうまくipsec0デバイスを自動起動させる事ができなかったので、レガシーなnetworkスクリプトによってネットワークデバイスをup/downさせる事にします。

# chkconfig NetworkManager off
# chkconfig network on

Host-to-Host IPsec デバイスの作成

今回は、system-config-networkを使ってipsec0デバイスの定義ファイルや、racoonの設定ファイルを自動生成させる方法でHost-to-HostのIPsecデバイスを作成します。
まず、system-config-networkを実行して設定GUIを起動します。

起動画面です。『IPsec』のタブを選択します。

左上の『New』をクリックすると、ウィザード形式でIPsec設定を追加することができます。

デバイス名を入力します。ここでは『ipsec0』としました。

今回は『Host-to-Host encryption』を選択します。

『Automatic encryption mode selection via IKA (racoon)』を選択します。

この設定での接続相手先のIPアドレスを入力します。画面は192.168.1.42ホストのものなので、接続先は『192.168.1.43』となります。

事前共有型の認証キーを入力します。ここでは『sepgsql920』としました。

入力したパラメータを確認して『Apply』をクリックします。

これで『ipsec0』デバイスが作成されているのが分かります。

設定を保存すると、右上の『Activate』『Deactivate』を選択することができるようになりますので、『Activate』をクリックしてください。

もう一方のノードでも同様の設定を行います。

IPsecの動作確認

ひとまず、SELinux関連の設定が絡まない範囲でHost-to-Host設定のIPsecがちゃんと動作しているかを確認します。双方のノードでネットワークを再起動します。

# service network restart

tcpdumpでパケットを観察すると、IPsecのAH/ESPプロトコルが使われている事が分かります。

[root@kg2 ~]# tcpdump -n -i eth1 host 192.168.1.42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:55:34.979277 IP 192.168.1.42 > 192.168.1.43: \
    AH(spi=0x03850f37,seq=0x10): ESP(spi=0x0f3c888b,seq=0x10), length 76
16:55:34.979505 IP 192.168.1.43 > 192.168.1.42: \
    AH(spi=0x0ebad42b,seq=0x6): ESP(spi=0x0183d073,seq=0x6), length 76
16:55:34.980000 IP 192.168.1.42 > 192.168.1.43: \
    AH(spi=0x03850f37,seq=0x11): ESP(spi=0x0f3c888b,seq=0x11), length 68
    :
    :

Labeled Network の設定

ipsec0デバイスを起動する時に、どの相手との接続にIPsecを使うのか、その際のアルゴリズムは何なのか…という事がOS側に伝えられます。これを行うのがsetkeyコマンドなのですが、通常、これはifcfg-ipsec0の記述に基づいて（ここにスクリプトファイル名）が自動的に実行されます。
実際には以下のような書式をsetkeyコマンドに与えるのですが、Labeled Networkを使用するにあたって重要なのは、2行目の-ctxから始まる行です。これを指定する事で、このIPsec通信経路ではLabeled Networkを使用するという事を宣言できます。

spdadd 192.168.11.6 192.168.11.8 any
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P out ipsec esp/transport//require;

が、FedoraのInitスクリプトから実行される/etc/sysconfig/network-scripts/ifup-ipsecは、この辺の設定を行うための処理が入っていません。そこで、パッチを当てる事にしました（うげげ…）。

--- ifup-ipsec.orig	2012-12-03 17:41:38.809689669 +0100
+++ ifup-ipsec	2012-12-04 17:52:43.356150231 +0100
@@ -123,6 +123,8 @@ if [ "$ESP_PROTO" = "none" ]; then
     unset SPI_ESP_IN SPI_ESP_OUT KEY_ESP_IN KEY_ESP_OUT SPD_ESP_IN SPD_ESP_OUT
 fi
 
+test -n "$SELINUX_CONTEXT" && SELINUX_CONTEXT="\"${SELINUX_CONTEXT}\""
+
 /sbin/setkey -c >/dev/null 2>&1 << EOF
 ${SPI_AH_OUT:+delete $SRC $DST ah $SPI_AH_OUT;}
 ${SPI_AH_IN:+delete $DST $SRC ah $SPI_AH_IN;}
@@ -164,33 +166,45 @@ EOF
 # This looks weird but if you use both ESP and AH you need to configure them together, not seperately.
 if [ "$ESP_PROTO" != "none" ] && [ "$AH_PROTO" != "none" ]; then
 /sbin/setkey -c >/dev/null 2>&1 << EOF
-spdadd $SPD_SRC $SPD_DST any -P out ipsec
+spdadd $SPD_SRC $SPD_DST any
+            ${SELINUX_CONTEXT:+-ctx 1 1 ${SELINUX_CONTEXT}}
+            -P out ipsec
             ${SPD_ESP_OUT:+esp/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require}
             ${SPD_AH_OUT:+ah/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require}
 	    ;
 
-spdadd $SPD_DST $SPD_SRC any -P in ipsec
+spdadd $SPD_DST $SPD_SRC any
+            ${SELINUX_CONTEXT:+-ctx 1 1 ${SELINUX_CONTEXT}}
+            -P in ipsec
 	    ${SPD_ESP_IN:+esp/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require}
 	    ${SPD_AH_IN:+ah/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require}
 	    ;
 EOF
 elif [ "$AH_PROTO" = "none" ]; then
 /sbin/setkey -c >/dev/null 2>&1 << EOF
-spdadd $SPD_SRC $SPD_DST any -P out ipsec
+spdadd $SPD_SRC $SPD_DST any
+            ${SELINUX_CONTEXT:+-ctx 1 1 ${SELINUX_CONTEXT}}
+            -P out ipsec
             ${SPD_ESP_OUT:+esp/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require}
 	    ;
 
-spdadd $SPD_DST $SPD_SRC any -P in ipsec
+spdadd $SPD_DST $SPD_SRC any
+            ${SELINUX_CONTEXT:+-ctx 1 1 ${SELINUX_CONTEXT}}
+            -P in ipsec
 	    ${SPD_ESP_IN:+esp/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require}
 	    ;
 EOF
 elif [ "$ESP_PROTO" = "none" ]; then
 /sbin/setkey -c >/dev/null 2>&1 << EOF
-spdadd $SPD_SRC $SPD_DST any -P out ipsec
+spdadd $SPD_SRC $SPD_DST any
+            ${SELINUX_CONTEXT:+-ctx 1 1 ${SELINUX_CONTEXT}}
+            -P out ipsec
             ${SPD_AH_OUT:+ah/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require}
 	    ;
 
-spdadd $SPD_DST $SPD_SRC any -P in ipsec
+spdadd $SPD_DST $SPD_SRC any
+            ${SELINUX_CONTEXT:+-ctx 1 1 ${SELINUX_CONTEXT}}
+            -P in ipsec
 	    ${SPD_AH_IN:+ah/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require}
 	    ;
 EOF

この修正により、TYPE=IPSEC として定義されている /etc/sysconfig/network-scripts/ifcfg-* 設定ファイルに「SELINUX_CONTEXT=...」という行が存在すれば、IPsec通信経路を定義する際に、Labeled Networkの定義も同時に行われる事となります。
『ipsec_spd_t』というのは、IPsec通信経路に対して定義されているタイプです。現時点ではこれ以外のタイプは定義されていませんので、”お約束”という事にしておきます。

# cat /etc/sysconfig/network-scripts/ifcfg-ipsec0
DST=192.168.1.43
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
# KaiGai added them
SELINUX_CONTEXT=system_u:object_r:ipsec_spd_t:s0

うまく設定できていれば、setkey -DPの出力結果の中に『security context: ...』がどーたらという行が出力されているハズです。

# setkey -DP
    :
192.168.1.42[any] 192.168.1.43[any] 255
        out prio def ipsec
        esp/transport//require
        ah/transport//require
        created: Dec  4 16:45:31 2012  lastused: Dec  5 21:26:24 2012
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 33
        security context: system_u:object_r:ipsec_spd_t:s0
        spid=1 seq=0 pid=3500
        refcnt=2

SE-PostgreSQLのインストール

続いて、SE-PostgreSQLのインストールに移ります。
インストール手順は公式ドキュメントにも記載されていますので、Fedoraのパッケージを前提にざっくりと紹介します。

まず、initdbを実行します。

# postgresql-setup initdb
Initializing database ... OK

次に、postgresql.conf を編集して shared_preload_libraries に '$libdir/sepgsql' を追加します。

# vi /var/lib/pgsql/data/postgresql.conf
    :
    :
#max_files_per_process = 1000           # min 25
                                        # (change requires restart)
shared_preload_libraries = '$libdir/sepgsql'

# - Cost-Based Vacuum Delay -

PostgreSQLをシングルユーザモードで起動し、各データベースに初期セキュリティラベルを割り当てます。

# su - postgres
$ for dbname in template0 template1 postgres
  do
    /usr/bin/postgres --single $dbname < \
      /usr/share/pgsql/contrib/sepgsql.sql > /dev/null
  done

これでSE-PostgreSQLの初期設定は完了です。

最後に、TCP/IP経由での接続を受け付けるための設定を行ってサーバを起動します。

# vi /var/lib/pgsql/data/pg_hba.conf
(以下の一行を追加; 設定簡略化のため、とりあえずtrust)
host    all    all    192.168.1.42/32    trust

vi /usr/lib/systemd/system/postgresql.service
(以下の一行を編集し、pg_ctlから-iオプションを渡すようにする)
ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o "-p ${PGPORT}" -w -t 300
  ↓
ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o "-i -p ${PGPORT}" -w -t 300

サーバを立ち上げます。

# service postgresql start

試してみる

長かった・・・。

そして、クライアント側からTCP/IP接続でPostgreSQLサーバに接続してみます。

[kaigai@kg1 ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[kaigai@kg1 ~]$ psql -h 192.168.1.43 -U postgres postgres
psql (9.1.6)
Type "help" for help.

postgres=# SELECT sepgsql_getcon();
                    sepgsql_getcon
-------------------------------------------------------
 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(1 row)

ふむふむ、ちゃんとセキュリティコンテキストが切り替わっているように見えます。

それでは、クライアント側で権限を切り替えてからPostgreSQLに接続してみましょう。

[kaigai@kg1 ~]$ runcon -l s0-s0:c0,c2 bash
[kaigai@kg1 ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0,c2
[kaigai@kg1 ~]$ psql -h 192.168.1.43 -U postgres postgres
psql (9.1.6)
Type "help" for help.

postgres=# SELECT sepgsql_getcon();
                   sepgsql_getcon
----------------------------------------------------
 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0,c2
(1 row)

キタコレ！

クライアント側のOS上で変更したプロセスのセキュリティコンテキストが、PostgreSQL側に透過的に伝えられている事が分かります。

なお、以下のようにgetpeercon(3)に失敗している場合は、TCP/IPレベルでの接続には成功したものの、Labeled Networkが機能していません。設定を見直してみてください。

$ psql -h 192.168.0.43 -U postgres postgres
psql: FATAL:  SELinux: unable to get peer label: Protocol not available

まとめ

今回紹介したLabeled Networkの機能を使う事で、SE-PostgreSQLが実現する”OSとDBのアクセス制御の統合”を複数ノードから成る環境にも拡大する事ができるようになりました。
ただ、これは不特定多数からの接続に対して、接続相手のセキュリティコンテキストを受け入れるという設定ではなく、あくまでも、信頼済みのホストが提示するセキュリティコンテキストを受け入れるという形になります。したがって、”誰か分からないけど世界中からアクセスが来る”という場合に使える方法ではなく、自サイトで管理下にあるWebサーバやAPサーバからPostgreSQLサーバに接続する際にセキュリティコンテキストを伝達するための手法という事になります。

現時点では、OS標準のスクリプトがLabeled Networkに対応しておらずスクリプトを修正する必要があったり、初回接続時に（racoonの鍵交換に時間がかかって？）タイムアウトになるといった現象が見られました。
この辺は改良の余地ありなので、引き続き調査してみようと思います。

Dominick Grift: Anatomy of a SELinux policy module: Dropbox

Dominick "domg472" Grift (noreply@blogger.com) — 2012-12-01T10:17:35+00:00

I was asked to write a SELinux policy module for Dropbox. For obvious reasons i do not use this user application myself but i was willing to make an exception for the sake of writing a SELinux policy configuration for Dropbox.

The module was designed for and developed on a Fedora 18 (Beta) system.

Before i start designing and writing a policy configuration for some application i usually do my home work first. That means reading up on the application as much as i can so that i have an idea what to expect.

In this case i already had a rough idea about the applications functionality. I was interested in seeing what is installed where and when.

And so i downloaded and extracted two packages from this location:

https://www.dropbox.com/install

I focussed on this package:

https://dl-web.dropbox.com/u/17/dropbox-lnx.x86_64-1.6.2.tar.gz

and also had a quick look at this:

https://www.dropbox.com/download?dl=packages/fedora/nautilus-dropbox-1.4.0-1.fedora.x86_64.rpm

Basically i downloaded both packages and extracted it to see what was in them.

The dropbox-lnx.x86_64-1.6.2.tar.gz package is expected to be downloaded to "~" and to be extracted there. It extracts a directory called ".dropbox-dist" with various files in it.

The installation guide suggests that one runs the "dropboxd" file that is location in the extracted "~/.dropbox-dist" location.

And so i decided to just try it out.

As it turns out the dropboxd programs runs another file in that location called "dropbox". Another file in that directory called "library.zip" turned out to be a "hard link" to " dropbox". I was also able to identify plenty library files by their ".so" extensions.

Anyways; A graphical window popped up and presented me with a series of questions. I followed the directions and when i was done the window exited and the process installed two more directories in my home directories called "~/.dropbox" and "~/Dropbox" respectively.

The " ~/.dropbox" directory has various files that seem to be configuration files of some sorts and the "~/Dropbox" directory is the location that gets synchronized.

Now i' ve had a rough idea of the locations and the nature of the files that were installed.

The next step was to think about design.

Were using the common security models available to us: Role based access control and Type enforcement. The aim is to improve integrity of our processes and files.

We must also do our best to support as much of the applications functionality as we possibly can.

We need to maintain a sub-tile balance between usability and security.

Designing policy configuration for applications that sit on top of a Desktop environment is more complicated than a text application that you can for example run from a console because they usually interact with components on the Desktop environment and operate on files maintained by the these components.

In a stock Fedora SELinux policy configuration most of the Desktop enviroment is not targeted. The result of this design decision is that components of the Desktop enviroment run with the same attributes and permissions as the user running them.

For us that means that we either target each Desktop environment component and each file they maintain that Dropbox interacts with, or we allow our targeted Dropbox application to interact with the components operating, and operate on files they maintain, with the attributes and permissions of the user.

I decided to go with the latter for simplicity.

With that in mind i set out some humble security goals to achieve:

1. Protect user application configuration, data and cache files as much as possible.
2. Protect and contain the Dropbox application and process as much as possible.

What follows now is my current SELinux policy configuration for Dropbox. The nautilus plugin (nautilus-dropbox-1.4.0-1.fedora.x86_64.rpm) is NOT supported. At least not currently.

This because i refuse to install it because it depends on libgnome which in turn depends on Orbit and Bonobo and i will do just about anything to not have that installed.

Here is the configuration. Below the configuration i will touch on its properties in detail:

1. The ~/mydopbox/mydropbox.te Type enforcement source policy file:

policy_module(mydropbox, 1.0.0)

attribute dropbox_domain;

type dropbox_exec_t;

type dropbox_home_t;
userdom_user_home_content(dropbox_home_t)

type dropbox_tmp_t;
userdom_user_tmp_content(dropbox_tmp_t)

type dropbox_tmpfs_t;
userdom_user_tmpfs_content(dropbox_tmpfs_t)

type dropbox_port_t;
corenet_port(dropbox_port_t)

allow dropbox_domain self:capability dac_override; # mount
allow dropbox_domain self:netlink_route_socket r_netlink_socket_perms;
allow dropbox_domain self:process { execmem signal };
allow dropbox_domain self:shm create_shm_perms;
allow dropbox_domain self:tcp_socket create_stream_socket_perms;
allow dropbox_domain self:udp_socket create_socket_perms;

allow dropbox_domain dropbox_home_t:dir manage_dir_perms;
allow dropbox_domain dropbox_home_t:file manage_file_perms;
allow dropbox_domain dropbox_home_t:sock_file manage_sock_file_perms;
userdom_user_home_dir_filetrans(dropbox_domain, dropbox_home_t, dir, ".dropbox")

allow dropbox_domain dropbox_tmp_t:file { manage_file_perms mmap_file_perms };
files_tmp_filetrans(dropbox_domain, dropbox_tmp_t, file)

can_exec(dropbox_domain, dropbox_exec_t)

kernel_getattr_core_if(dropbox_domain)

corecmd_exec_shell(dropbox_domain)

corenet_tcp_bind_generic_node(dropbox_domain)
corenet_tcp_sendrecv_generic_if(dropbox_domain)
corenet_tcp_sendrecv_generic_node(dropbox_domain)
corenet_udp_bind_generic_node(dropbox_domain)
corenet_udp_sendrecv_generic_if(dropbox_domain)
corenet_udp_sendrecv_generic_node(dropbox_domain)

corenet_sendrecv_http_client_packets(dropbox_domain)
corenet_tcp_connect_http_port(dropbox_domain)
corenet_tcp_sendrecv_http_port(dropbox_domain)

allow dropbox_domain dropbox_port_t:{ tcp_socket udp_socket } name_bind; # temporary workaround: 17500

dev_list_sysfs(dropbox_domain)
dev_read_sysfs(dropbox_domain)
dev_read_urand(dropbox_domain)

dev_dontaudit_getattr_all_blk_files(dropbox_domain) # panic
dev_dontaudit_getattr_all_chr_files(dropbox_domain) # panic

fs_getattr_tmpfs(dropbox_domain)
fs_getattr_xattr_fs(dropbox_domain)
fs_rw_inherited_tmpfs_files(dropbox_domain) # this is that xserver shm thing

auth_read_passwd(dropbox_domain)

init_getattr_initctl(dropbox_domain)

libs_exec_ldconfig(dropbox_domain)

mount_exec(dropbox_domain)
mount_manage_pid_files(dropbox_domain) # mount: read/write /run/mount/utab

sysnet_exec_ifconfig(dropbox_domain)
sysnet_read_config(dropbox_domain)

userdom_manage_user_home_content_dirs(dropbox_domain)
userdom_manage_user_home_content_files(dropbox_domain)
userdom_mmap_user_home_content_files(dropbox_domain) # libraries in ~/.dropbox-dist
userdom_user_home_dir_filetrans_user_home_content(dropbox_domain, dir) # cannot use named file transition due to random names
userdom_use_user_terminals(dropbox_domain)

optional_policy(`
 dbus_session_bus_client(dropbox_domain) # probably not actually optional
 dbus_connect_session_bus(dropbox_domain) # probably not actually optional
')

optional_policy(`
 gnome_read_generic_data_home_dirs(dropbox_domain) # searching ~/.local/share
 gnome_read_home_config(dropbox_domain) # ibus, might not be optional

 # hack
 gen_require(`
  type config_home_t;
 ')

 allow dropbox_domain config_home_t:dir setattr_dir_perms;
')

2. The ~/mydopbox/mydropbox.if Interface source policy file:

Blogspot does not format this content properly: View/Get it here instead:

http://pastebin.com/zcfSK2n3

## Dropbox is a free service that lets you bring all your photos, docs, and videos anywhere.

#######################################
## 
## The role template for the dropbox module.
## 
## 
## 
## This template creates a derived domains which are used
## for dropbox applications.
## 


## 
## 
## 
## The prefix of the user domain (e.g., user
## is the prefix for user_t).
## 
## 
## 
## 
## The role associated with the user domain.
## 
## 
## 
## 
## The type of the user domain.
## 
## 
#
template(`dropbox_role_template',`
 gen_require(`
  attribute dropbox_domain;
  type dropbox_exec_t, dropbox_home_t, dropbox_tmpfs_t;
 ')

 ########################################
 #
 # Declarations
 #

 type $1_dropbox_t, dropbox_domain;
 userdom_user_application_domain($1_dropbox_t, dropbox_exec_t)
 role $2 types $1_dropbox_t;

 ########################################
 #
 # Policy
 #

 domtrans_pattern($3, dropbox_exec_t, $1_dropbox_t)

 ps_process_pattern($3, $1_dropbox_t)
 allow $3 $1_dropbox_t:process { ptrace signal_perms };

 allow $1_dropbox_t $3:process signull;
 allow $1_dropbox_t $3:unix_stream_socket connectto;

 allow $3 dropbox_exec_t:file { manage_file_perms relabel_file_perms };
 userdom_user_home_content_filetrans($3, dropbox_exec_t, file, "dropbox")
 userdom_user_home_content_filetrans($3, dropbox_exec_t, file, "dropboxd")
 userdom_user_home_content_filetrans($3, dropbox_exec_t, file, "library.zip")

 allow $3 dropbox_home_t:dir { manage_dir_perms relabel_dir_perms };
 allow $3 dropbox_home_t:file { manage_file_perms relabel_file_perms };
 allow $3 dropbox_home_t:sock_file { manage_sock_file_perms relabel_sock_file_perms };
 userdom_user_home_dir_filetrans($3, dropbox_home_t, dir, ".dropbox")

 kernel_read_system_state($1_dropbox_t)

 corecmd_bin_domtrans($1_dropbox_t, $3)

 corenet_all_recvfrom_unlabeled($1_dropbox_t)
 corenet_all_recvfrom_netlabel($1_dropbox_t)

 logging_send_syslog_msg($1_dropbox_t) # might want to make this conditional if possible

 optional_policy(`
  dropbox_dbus_chat($1, $3) # probably not actually optional
 ')

 optional_policy(`
  xserver_user_x_domain_template($1_dropbox, $1_dropbox_t, dropbox_tmpfs_t) # might not be optional
 ')
')

########################################
## 
## Send and receive messages from
## dropbox over dbus.
## 
## 
## 
## The prefix of the user domain (e.g., user
## is the prefix for user_t).
## 
## 
## 
## 
## Domain allowed access.
## 
## 
#
interface(`dropbox_dbus_chat',`
 gen_require(`
  type $1_dropbox_t;
  class dbus send_msg;
 ')

 allow $2 $1_dropbox_t:dbus send_msg;
 allow $1_dropbox_t $2:dbus send_msg;
')

3. The ~/mydopbox/mydropbox.fc File contexts source policy file:

HOME_DIR/\.dropbox(/.*)? gen_context(system_u:object_r:dropbox_home_t,s0)
HOME_DIR/\.dropbox-dist/dropbox(d)? -- gen_context(system_u:object_r:dropbox_exec_t,s0)
HOME_DIR/\.dropbox-dist/library\.zip -- gen_context(system_u:object_r:dropbox_exec_t,s0)

Declaring types, classifying them and making sure that SELinux knows what to label what

Note that the policy above is the current result. Many of the properties of Dropbox where discovered after studying the contents of the package by trial and error.

type dropbox_exec_t;

This is the declaration of the type of the dropbox executable files. Since "library.zip" is a hard link of "dropbox", we need to make sure that both are labeled identical. The file "dropboxd" is also a Dropbox user application executable file.

HOME_DIR/\.dropbox-dist/dropbox(d)? -- gen_context(system_u:object_r:dropbox_exec_t,s0)
HOME_DIR/\.dropbox-dist/library\.zip -- gen_context(system_u:object_r:dropbox_exec_t,s0)

Above is how we instruct SELinux about where these Dropbox application executable files are located and how they should be labeled.

type dropbox_home_t;
userdom_user_home_content(dropbox_home_t)

This is the declaration of the Dropbox user configuration content located in "~/.dropbox" as well as the interface call that classifies the type as " user home content".

HOME_DIR/\.dropbox(/.*)? gen_context(system_u:object_r:dropbox_home_t,s0)

Here we tell SELinux that the ~/.dropbox directory and everything in it should be labeled with type "dropbox_home_t" which is the Dropbox user home content type.

type dropbox_tmp_t;
userdom_user_tmp_content(dropbox_tmp_t)

Dropbox maintains a file in " $TMP". Here we declare a type "dropbox_tmp_t" for this file and we classify this file "user tmp content" by calling the "userdom_user_tmp_content() interface with the "dropbox_tmp_t" file type parameter.

SELinux does not have to be aware of the location of the file in "$TMP" since for reason that i will not touch on in this article it should not maintain any contexts in "$TMP". Hence there is no entry for this in the "~/mydropbox/mydropbox.fc" file.

type dropbox_tmpfs_t;
userdom_user_tmpfs_content(dropbox_tmpfs_t)

Dropbox opens a GTK window when you first run it to guide you through the installation process. Dropbox also has i icon in the taskbar that opens a settings window if you select it. The result is that Dropbox interacts with X server and operates on content maintained by X server.

For this we have to declare a type for Dropbox shared memory in "/dev/shm". We classify this type "user tmpfs content".

There is no need to specificy a file context for this content as SELinux should not maintain file contexts in this locations for the same reasons as it should not maintain them in "$TMP".

type dropbox_port_t;
corenet_port(dropbox_port_t)

Dropbox listens on the UDP and TCP network for connections on port 17500. We Declare a type for this port object and classify the type "corenet_port". This will allow us to tell SELinux that Dropbox may only bind TCP and UDP sockets to ports that are classified "dropbox_port_t".

Ports are not files and thus their contexts should not be specified in the file context file (~/mydropbox/mydropbox.fc).

Instead we need to , after we installed the policy module package, manually label the 17500 UDP and TCP ports type "dropbox_port_t"

This is done by issuing the following command:

semanage port -a -t dropbox_port_t -p tcp 17500
semanage port -a -t dropbox_port_t -p udp 17500

You may have noticed that we have not yet classified our " dropbox_exec_t" user application executable file type.

You may also have notices that we have not yet declared and classified a type for the Dropbox process.

This is because of the properties of this application and it is also related to my design decision.

Dropbox runs Nautilus and Firefox on your behalf to open your "~/Dropbox" location and to direct you to the "www.dropbox.com" website respectively.

These two applications are currently not targeted in Fedora and i have decided to not do that either.

How can we tell SELinux that if Dropbox runs Nautilus or Firefox that it does that on behalf of the user and that SELinux thus should run these two applications with the attributes and permissions of the user rather than the attributes and permission of Dropbox?

This requires that we create a template because not all SELinux users are created equal. We need to use the "user role prefix" to declare a derived Dropbox process type. This will allow use to create rules that specify with which attributes and permissions Dropbox should run Nautilus and Firefox.

This is done in a template called "dropbox_role_template" that i have created in the "~/mydropbox/mydropbox.if" interface file.

 type $1_dropbox_t, dropbox_domain;
 userdom_user_application_domain($1_dropbox_t, dropbox_exec_t)
 role $2 types $1_dropbox_t;

The above declares a derived dropbox process type "$1_dropbox_t" where "$1" is the "user role prefix". It then goes on to classify this process "dropbox_domain" This is done by assigning it a "type attribute" that we i declared in the "~/mydropbox/mydropbox.te" type enforcement file. You can find it on top, right below the policy module declaration.

Next we classify both the Dropbox process type as well as the Dropbox user application executable file type "user application domain". This interface has all the permissions needed to classify our process type "user application process" and our application executable file "user application executable file".

The last rule is a "Role based access control" rule that allows the "calling" role access to the prefixed Dropbox type.

Policy.

domtrans_pattern($3, dropbox_exec_t, $1_dropbox_t)

This rule is a domain transition rule, or if you like "process type transition rule". It tells SELinux that the "calling" user process type should transition to the derived Dropbox process type when it runs the Dropbox user application executable file.

 ps_process_pattern($3, $1_dropbox_t)
 allow $3 $1_dropbox_t:process { ptrace signal_perms };

The above rules allow the calling user process type to "ps" processes labeled with the derived Dropbox process type as well as ptrace it and send all signals to it.

logging_send_syslog_msg($1_dropbox_t)

This will allow Dropbox to for example show up in "top", " ps x" and it allows you to "strace", kill etc. the Dropbox process.

 allow $1_dropbox_t $3:process signull;
 allow $1_dropbox_t $3:unix_stream_socket connectto;

Here are some interesting rules. The first allows the derived Dropbox process type to send null signals to the calling user process type and the second one allows the derived Dropbox process type to connect to the calling user process type with a unix domain stream socket.

The processes here labeled with the "calling user process types" aren' t actually the calling user. These are for example Nautilus or Firefox. Since we decided not to target them they are labeled with the " calling user process type".

In this case Dropbox probably wants to see if Nautilus is already running, and Dropbox probably wants to communicate with Nautilus using a unix domain stream socket.

These rules are problematic because they are coarse. You can't tell by just looking at these rules who "$3" or if you will the process labeled with the "calling user process type" really is. Is it Nautilus or is it Firefox? Maybe it another process that currently is not targeted.

Basically it allows Dropbox to send null signals and talk using a unix domain stream socket to any application currently not targeted labeled with the "calling user process type".

 allow $3 dropbox_exec_t:file { manage_file_perms relabel_file_perms };
 userdom_user_home_content_filetrans($3, dropbox_exec_t, file, "dropbox")
 userdom_user_home_content_filetrans($3, dropbox_exec_t, file, "dropboxd")
 userdom_user_home_content_filetrans($3, dropbox_exec_t, file, "library.zip")

These rules allow processes labeled with the " calling user process type" to "manage and relabel" files labeled with the dropbox use application executable type " dropbox_exec_t".

Users need to be able to manage and relabel content in their home directory as they own it.

The other three rules are interesting as well. They use a pretty new feature called "named file type transitions",

These rules tell SELinux that if a process labeled with the " calling user process type" create files with named "dropbox, dropboxd and library.zip" in directories that are labeled with the user home content type "user_home_t" that the files should be created with the dropbox user application executable file type "dropbox_exec_t".

This is a important rule because proper labelling of files is of vital importance to the integrity of SELinux policy enforcement.

When you extract the "dropbox-lnx.x86_64-1.6.2.tar.gz" into you home directory, this rule ensure that the Dropbox executable files automatically get the right security context.

The file context specification for these files that we added to " ~/mydropbox/mydropbox.fc" ensure that if restorecon gets run on any and all of these files that they will stay labeled properly.

 allow $3 dropbox_home_t:dir { manage_dir_perms relabel_dir_perms };
 allow $3 dropbox_home_t:file { manage_file_perms relabel_file_perms };
 allow $3 dropbox_home_t:sock_file { manage_sock_file_perms relabel_sock_file_perms };
 userdom_user_home_dir_filetrans($3, dropbox_home_t, dir, ".dropbox")

The same applies to the above except that this applies to Dropbox user home content and it applies to files, directories and sock files.

The named file transtion rule dictates that SELinux should make sure that processes with the calling user process type create directories with the name ".dropbox" in directories with type "user_home_dir_t" (~) with type "dropbox_home_t".

Note: I should probably allow allow processes with the calling process type to manage and relabel files with type dropbox_tmp_t as well dropbox_tmpfs_t.

 kernel_read_system_state($1_dropbox_t)

This rule allows the derived Dropbox process type to read generic system state files in "/proc", like for example "/proc/meminfo".

We added this rule (and some other rules that would normally go into the type enforcement file) here because it uses type attributes and were also using our "dropbox_domain" type attribute in our type enforcement file to write rules.

One can only assign type attribute to types. You cannot assign a type attribute to a type attribute and thus we decided to deal with this in this manner.

corecmd_bin_domtrans($1_dropbox_t, $3)

This is the rule that caused me to implement the "dropbox_role_template" template.

It is what enables us to tell SELinux that dropbox should run application that are not targeted with the "calling user process type".

Basically it dictates that when the derived Dropbox process type runs a file with the generic "bin_t" "core command executable type" that the process type should transition from "$1_dropbox_t" (the derived Dropbox process type) to "$3" ( the calling user process type)

 corenet_all_recvfrom_unlabeled($1_dropbox_t)
 corenet_all_recvfrom_netlabel($1_dropbox_t)

These rules allow the derived Dropbox process type to recv from all unlabeled and netlabel network connections.

It is basically a rule that effectivily disabled SELinux network controls enforcement.

These rules are here because again they use type attributes and one cannot assign type attributes to type attributes. That means we cannot use our "dropbox_domain" attribute to call these in our ~/mydropbox/mydropbox.te" file.

logging_send_syslog_msg($1_dropbox_t)

This rule allows the prefixed Dropbox process type to send messages to syslog. Same as above it uses type attributes and so i had to add it here instead of in the type enforcement file.

 optional_policy(`
  dropbox_dbus_chat($1, $3) # probably not actually optional
 ')

This allows the derived dropbox process type to communicate using DBUS with processes that are labeled with the "calling user process type". Probably Nautilus or some Gnome Desktop environment compoment like GVFS.

Since None of them are targeted we are forced to allow the prefixed dropbox process type to communicate using DBUS with any process as long as its labeled with the "calling user process type".

We could have used raw policy to write these rules here but since DBUS is a "object manager" and also since its good to have a " dropbox_dbus_chat" interface we decide to create one (you can find it below the "dropbox_role_template" template in "~/mydropbox/mydropbox.if" and to call it in our own module.

The "optional_policy" block indicates that this module does not actually depend on the rule in the block. I was assuming that Dropbox does not depend on the presence of DBUS but i may well be mistaken.

 optional_policy(`
  xserver_user_x_domain_template($1_dropbox, $1_dropbox_t, dropbox_tmpfs_t) # might not be optional
 ')

This rule allows the derived Dropbox process type to interact with X server and to operate on files maintained by X server. It also makes our "dropbox_tmpfs_t" "user tmpfs content" available for use with X server.

I was under the impression that Dropbox does not depend on X server since on their website they claim that Dropbox works on "any Linux server" but again i may be mistaken.

allow dropbox_domain self:capability dac_override; # mount
allow dropbox_domain self:netlink_route_socket r_netlink_socket_perms;
allow dropbox_domain self:process { execmem signal };
allow dropbox_domain self:shm create_shm_perms;
allow dropbox_domain self:tcp_socket create_stream_socket_perms;
allow dropbox_domain self:udp_socket create_socket_perms;

These are what i call " self-rules". Basically rules where a source process labeled with a process type interacts with or operates on itself.

The first rule allow any Dropbox process type the "dac_override" capability. This capability is needed to override discretionary access controls.

Dropbox runs the mount command with the derived Dropbox process type (rather than with a process type transition) which is a setuid command.

When the command is run your shell sessions current "pwd" is probably "~/.dropbox-dist" since thats where you run dropboxd from. The root Linux user does (or might not) have access to that location as " $HOME" might have the "0700" attibutes. The "dac_override" access vector permission allow the process type to access it anyway from a SELinux perspective.

The second rule is probably to read the routing table. Dropbox is a network application and so i am not surprised that it needs these permissions.

The third rule allows all Dropbox process types to "execute anonymous memory", Basically memory that is world writable. It is usually a sign of bad programming practices but there are also legitimate use cases such as "just in time compiling". This rule also allows Dropbox process types to send generic signals to itself.

The fourth rule allows Dropbox processes to create shared memory. This is for X server interaction and is related to the " dropbox_tmpfs_t" "user_tmpfs_content" type.

The fifth and the sixth rule allows dropbox and any other process labeled with any dropbox process type to create tcp stream sockets and udp sockets. This is needed because Dropbox is listening on the network for connections (port udp/tcp 17500 dropbox_port_t)

allow dropbox_domain dropbox_home_t:dir manage_dir_perms;
allow dropbox_domain dropbox_home_t:file manage_file_perms;
allow dropbox_domain dropbox_home_t:sock_file manage_sock_file_perms;
userdom_user_home_dir_filetrans(dropbox_domain, dropbox_home_t, dir, ".dropbox")

These rules allow all Dropbox process types to "manage" directories, files and sock files that are labeled with the "dropbox_home_t" " user home content type". This is configuration content amongst other things. Stuff that could use protecting to ensure optimal integrity.

The fourth rule is another named file type transition rule. It dictates that if any dropbox process type creates a directory with name ".dropbox" in directories with type " user_home_dir_t" which is "~" that the directory be created with the "dropbox_home_t" type. Thus file transitioning from "user_home_dir_t" to "dropbox_home_t".

allow dropbox_domain dropbox_tmp_t:file { manage_file_perms mmap_file_perms };
files_tmp_filetrans(dropbox_domain, dropbox_tmp_t, file)

Dropbox maintains a file in "$TMP" with a random name. It also "mmaps" that file. The second rule dictates that if any Dropbox process type creates a file in a directory with type " tmp_t" that the file is created with the " dropbox_tmp_t" " user_tmp_content" type. Since this file has a random name i have to use a regular file type transition and i cannot use a named file type transition.

can_exec(dropbox_domain, dropbox_exec_t)

The dropboxd process executes the dropbox "user application executable file" Both dropboxd as well as dropbox are labeled with the " dropbox_exec_t" type. This rule allows all Dropbox process types to execute files with the dropbox_exec_t type without a process type transition.

kernel_getattr_core_if(dropbox_domain)

I am not sure why but Dropbox wants to get attribute of the core if file in "/proc". Fine.

corecmd_exec_shell(dropbox_domain)

This rule allows all Dropbox process types to run a shell without a process type transition.

corenet_tcp_bind_generic_node(dropbox_domain)
corenet_tcp_sendrecv_generic_if(dropbox_domain)
corenet_tcp_sendrecv_generic_node(dropbox_domain)
corenet_udp_bind_generic_node(dropbox_domain)
corenet_udp_sendrecv_generic_if(dropbox_domain)
corenet_udp_sendrecv_generic_node(dropbox_domain)

corenet_sendrecv_http_client_packets(dropbox_domain)
corenet_tcp_connect_http_port(dropbox_domain)
corenet_tcp_sendrecv_http_port(dropbox_domain)

allow dropbox_domain dropbox_port_t:{ tcp_socket udp_socket } name_bind; # temporary workaround: 17500

Network related rules. The first block of rules are "generic" in the sense that it basically does not support the use of the SELinux network controls. Or it supports them in the most generic way.

The second block allows all dropbox process types to connect to TCP ports that are labeled with the "httpd_port_t" port type. Dropbox connects to "tcp:443" (their Dropbox web application). It allow Dropbox to send and receive client packets that are labeled with the httpd packet type and it allows Dropbox to send and receive traffic from http classified ports.

The last rule of the bunch allows all dropbox process types to bind TCP and UDP sockets to ports that are labeled with the "dropbox_port_t" port type. We labeled UDP/TCP 17500 with that type.

dev_list_sysfs(dropbox_domain)
dev_read_sysfs(dropbox_domain)
dev_read_urand(dropbox_domain)

Above allows all Dropbox process types to list directories with the generic "sysfs_t" type. This is generic content in "/sys". The second rule allow Dropbox to actually read files with this type.

The third rule allows all Dropbox process types to read character device nodes with "urandom_device_t" device node type. E.g. /dev/urandom.

dev_dontaudit_getattr_all_blk_files(dropbox_domain) # panic
dev_dontaudit_getattr_all_chr_files(dropbox_domain) # panic

"Dontaudit" is a access vector that tells SELinux to silently block a specified interaction or operation.

In the above case we silently deny any Dropbox process type to get attributes of all block and character files that are classified "device_node".

To expose " hidden denials" one needs to issue the "semodule -DB" command which will build the policy database without any " dontaudit" rules. To reinsert the "dontaudit" rules simply issue 'semodule -B".

fs_getattr_tmpfs(dropbox_domain)
fs_getattr_xattr_fs(dropbox_domain)
fs_rw_inherited_tmpfs_files(dropbox_domain) # this is that xserver shm thing

This allow all Dropbox process types to get attributes of filesystems with the "tmpfs_t" filesystem type. This a common access vector for processes that maintain content in the " /dev/shm" location.

The second rule allow any Dropbox process type to get attribute of any filesystem that supports extended attributes. E.g. types that are classified "filesystem type" as well as "Extended attribute file system". This is to allow Dropbox to stat "/" which is a common thing to do.

The Third rule is related to X server interaction. I am not sure why it is the way it is but it has been this way for as long as i can remember. Inherited means that it doesnt actually opens the "generic tmpfs" file but it still reads and writes it. That means that either Dropbox got passed a open file or that there is a leaked file descriptor. Since, if i remember correctly , things will break if you do not allow this, i assume that X server or whatever passed the open file to Dropbox and dropbox reads and write it.

Note that the file is not labeled with the "dropbox_tmpfs_t" "user tmpfs content" file type either. Instead it is labeled with a generic type for content in "/dev/shm".

auth_read_passwd(dropbox_domain)

Allow all Dropbox process types to read files with the passwd_file_t file type. E.g. "/etc/passwd" amongst others.

This could simply be a side effect from Dropbox running a bash shell. The shell needs to read the password file in order to get the information needed for the shell prompt (user name etc.)

init_getattr_initctl(dropbox_domain)

Get attributes of initctl (named pipe i believe it was)

libs_exec_ldconfig(dropbox_domain)

Execute ldconfig program without a process type transition. It probably runs ldconfig on that file it maintains in "$TMP" that it also mmaps.

mount_exec(dropbox_domain)
mount_manage_pid_files(dropbox_domain) # mount: read/write /run/mount/utab

Execute the mount command without a process type transition. Not sure what it does with mount.

Mount reads and write /run/mount/utab which is labeled with the mount pid file type.

sysnet_exec_ifconfig(dropbox_domain)
sysnet_read_config(dropbox_domain)

Executes ifconfig command without a process type transition and read files that are classified network configuration files (net_conf_t) This is probably "/etc/resolve.conf"

userdom_manage_user_home_content_dirs(dropbox_domain)
userdom_manage_user_home_content_files(dropbox_domain)
userdom_mmap_user_home_content_files(dropbox_domain) # libraries in ~/.dropbox-dist
userdom_user_home_dir_filetrans_user_home_content(dropbox_domain, dir) # cannot use named file transition due to random names
userdom_use_user_terminals(dropbox_domain)

These are interesting. These rules allow all dropbox process types to operate on content maintained by processes labeled with the user process type.

In some cases this is bad news but in our case we will have to embrace it.

Here is why

The first two rules allow all Dropbox process types to manage directories and files that are labeled with the generic user home content type (user_home_t)

I decided to keep "~/Dropbox" location generic. The idea of Dropbox is that users can "drag and drop" content in there to synchronise with the Dropbox. Usually that is program Photos (~/Pictures), documents (~/Documents), maybe tunes (~/Audio or ~/Music). These locations should be generic since they are not related to any single user application.

"Drag and dropping" equals "moving" if done on a single partition. When you move a file you also move its context and so we want "~/Dropbox" to have the same type as the content that is expected to be dropped in there.

If a user is stupid enough to drop his " ~/.gnupg" or "~/.ssh" directory into the "~/Dropbox" then the dropbox process type will not be able to access that content. E.g. it wont be able to synchronize your sensitive files.

Unless ofcourse if you really want it to. In that case you would first manually relabel the content to the generic user home content type (user_home_t) with the "chcon" command and them drop it into your Dropbox.

So leaving "~/Dropbox" type "user_home_t" and allowing Dropbox to manage files and directories with the "user_home_t" seems to me the sensible thing to do here.

The third rule is a bit more controversial. The Dropbox archive copies library files into ~/.dropbox-dist. I decided to only give "dropboxd, dropbox and library.zip" in there a private type for simplicitly but the side effect is the now all dropbox process types need to mmap generic user home content files (the libraries).

The fourth rule is a file type transition rule. The Dropbox installed creates "~/Dropbox" which we want to have type "user_home_t". But this location has a fixed name so we could have used a named file transition rather than a normal file transition. However during installation Dropbox also create a directory in "~" with a random name andso we could not use a named file type transition for that anyways, and so it was decided to use this rule

Basically it dictates that if any Dropbox process type creates a directory in a directory with type "user_home_dir_t" (~) that the directory should be created with the "user_home_t" generic user home content type.

The fifth rule allows any dropbox process type to "use" user terminals. This will allow Dropbox to print any messages to the terminal when you run "./dropboxd"

optional_policy(`
 dbus_session_bus_client(dropbox_domain) # probably not actually optional
 dbus_connect_session_bus(dropbox_domain) # probably not actually optional
')

This will allow anydropbox domain to become a DBUS session bus client and to aquire service on the session bus. Since i was under the assumption that DBUS is not a requirement for Dropbox i wrapped these rules in a "optional_policy" block that basically tells the policy compiler that these rules are optional. E.g. if they are not available for use then do not sweat it and proceed.

optional_policy(`
 gnome_read_generic_data_home_dirs(dropbox_domain) # searching ~/.local/share
 gnome_read_home_config(dropbox_domain) # ibus, might not be optional

 # hack
 gen_require(`
  type config_home_t;
 ')

 allow dropbox_domain config_home_t:dir setattr_dir_perms;
')

These rules are related to content in X desktop (XDG) standard locations. Basically all Dropbox process types need to be able to read IBUS files in "~/.config" These IBUS files are labeled with the generic "config_home_t" user home content type.

Dropbox is probably using some Gnome library that does this on behalf of Dropbox. It also wants to set attributes of generic "config_home_t" directories and search generic "data_home_t" directories (~/.local/share).

Okay... I think i touched on everything now, except...

How to actually implement this policy

Create a working directory and change directory into it:

mkdir ~/mydropbox; cd ~/mydropbox;

Create three "mydropbox" source policy files:

touch mydropbox.{te,if,fc}

Copy the policy above in their respective files

Next, create another file:

touch myunconfineduser.te

and paste the following in that file:

policy_module(myunconfineduser, 1.0.0)

gen_require(`
 type unconfined_t;
 role unconfined_r;
')

dropbox_role_template(unconfined, unconfined_r, unconfined_t)

This is what actually calls or if you will activates the "dropbox_role_template()" that i have created in the "~/mydropbox/mydropbox.if" interface file.

Now build the two policy packages. You may or may not need to install the "selinux-policy-devel" package for this:

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

Next install the policy packages that were created in "~/mydropbox":

sudo semodule -i mydropbox.pp myunconfineduser.pp

If you have already installed Dropbox then make sure to restore the context of the "~/.dropbox" directories and the "dropboxd, dropbox and library.zip" files in "~/.dropbox-dist":

restorecon -R -v -F ~

If you have not yet installed Dropbox:

cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -

~/.dropbox-dist/dropboxd

Disclaimer:

I do not encourage nor endorse the use of Dropbox. Security means taking responsibility. Do not trust your content to third parties.

Dan Walsh: Using Apache and SELinux Together

dwalsh@redhat.com — 2012-11-01T17:42:31+00:00

A few months ago, I wrote an article on "Using Apache and SELinux Together" for DrupalWatchDog Magazine. They publish it first in hard copy, and then after a couple of months publish it on line. Here is a link to the online version.

http://drupalwatchdog.com/2/2/apache-selinux

Dan Walsh: New Security Feature in Fedora 18 Part 8: Introducing sepolicy generate

dwalsh@redhat.com — 2012-10-31T18:23:56+00:00

sepolgen

sepolgen is the tool that I recommend people use to start generating policy. We have decided to merge this tool into the sepolicy suite

sepolicy generate

man sepolicy-generate

sepolicy-generate(8)                                                                                                                                            sepolicy-generate(8)

NAME
       sepolicy-generate - Generate an initial SELinux policy module template.

SYNOPSIS
       sepolicy generate [-h] [-t TYPE] [-n NAME] [-T TEST] [ command | confineduser ]

DESCRIPTION
       Use sepolicy generate to generate an SELinux policy Module. sepolicy generate will generate 4 files.

       Type Enforcing File NAME.te
       This file can be used to define all the types rules for a particular domain.

       Interface File NAME.if
       This file defines the interfaces for the types generated in the te file, which can be used by other policy domains.

       File Context NAME.fc
       This file defines the default file context for the system, it takes the file types created in the te file and associates file paths to the types. Tools like restorecon and RPM will use these paths to put down labels.

       RPM Spec File NAME_selinux.spec
       This file is an RPM SPEC file that can be used to install the SELinux policy on to machines and setup the labelling. The spec file also installs the interface file and a man page describing the policy. You can use sepolicy manpage -d NAME to generate the man page.

       Shell File NAME.sh
       This is a helper shell script to compile, install and fix the labelling on your test system. It will also generate a man page based on the installed policy, and compile and
       build an RPM suitable to be installed on other machines

       If a generate is possible, this tool will print out all generate paths from the source domain to the target domain

OPTIONS
       -h, --help
              Display help message

       -t, --type
              Specify the type of policy you want to create.
              Valid Options:
              0 : Standard Init Daemon (Default)
              1 : DBUS System Daemon
              2 : Internet Services Daemon
              3 : Web Application/Script (CGI)
              4 : User Application
              5 : Sandbox
              6 : Minimal Terminal User Role
              7 : Minimal X Windows User Role
              8 : User Role
              9 : Admin User Role
              10 : Root Admin User Role
       -n, --name
              Specify alternate name of policy. The policy will default to the executable or name specified.

EXAMPLE
       sepolicy generate /usr/sbin/rwhod
       Generating Policy for /usr/sbin/rwhod named rwhod
       Created the following files in:
       rwhod.te # Type Enforcement file
       rwhod.if # Interface file
       rwhod.fc # File Contexts file
       rwhod_selinux.spec # Spec file
       rwhod.sh # Setup Script

sepolicy generate has some nice new features over sepolgen.

sepolicy generate does not to be run as root.
sepolicy generate now generates a RPM spec file. This spec file can be used to build and RPM package that will install the policy package file (pp) and interface file (if) in the correct location, install it into the kernel and fix the labelling.
The sepolicy generated setup script continues to install the policy and setup the labelling, and also generates a man page based on the installed policy using sepolicy manpage, finally it build and compiles the policy and man page into an rpm ready to be installed on other machines.

selinux-polgengui no longer needs to be run as root either, since it is using the sepolicy generate python bindings to generate the policy files. sepolgen command will now just execute sepolicy generate as a shell script.

Dan Walsh: New Security Feature in Fedora 18 Part 8: Introducing sepolicy transition

dwalsh@redhat.com — 2012-10-29T13:26:28+00:00

Another advanced topic of SELinux, that is hard to understand is process transitions. Basically this is the mechanism where most processes get their labels. The init_t domain transition to the initrc_t domain when it executes an initrc_exec_t labelled script. initrc_t transition to httpd_t when it executes and file labelled httpd_exec_t ...

Two questions can arise from this,

What process domains can one process domain transition too?
Can one process domain transition to another?

I orginally created a tool called setrans but now we are shipping it as part of the sepolicy suite.

> man sepolicy-transition
sepolicy-transition(8)                                  sepolicy-transition(8)

NAME
       sepolicy-transition - Examine the SELinux Policy and generate a process transition report

SYNOPSIS
       sepolicy transition [-h] -s SOURCE

       sepolicy transition [-h] -s SOURCE -t TARGET

DESCRIPTION
       sepolicy transition will show all domains that a give SELinux source domain can transition to, including the entrypoint.

       If a target domain is given, sepolicy transition will examine policy for all transition paths from the source domain to the target domain, and will list the paths. If a transition is possible, this tool will print out all transition paths from the source domain to the target domain

OPTIONS
       -h, --help
              Display help message

       -s, --source
              Specify the source SELinux domain type.

       -t, --target
              Specify the target SELinux domain type.

If I want to see what process domains guest_t can transition too, I can execute the following:

# sepolicy transition -s guest_t
guest_t @ abrt_helper_exec_t --> abrt_helper_t
guest_t @ loadkeys_exec_t --> loadkeys_t
guest_t @ chkpwd_exec_t --> chkpwd_t
guest_t @ passwd_exec_t --> passwd_t
guest_t @ updpwd_exec_t --> updpwd_t
guest_t @ chfn_exec_t --> chfn_t
guest_t @ oddjob_mkhomedir_exec_t --> oddjob_mkhomedir_t
guest_t @ shell_exec_t --> httpd_user_script_t

If I wanted to see how httpd_t can read system_mail_t

# sepolicy transition -s httpd_t -t system_mail_t
httpd_t --> httpd_suexec_t --> httpd_mojomojo_script_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> postfix_showq_t --> spamc_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> uux_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> uux_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> procmail_t --> clamscan_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> postfix_master_t --> postfix_local_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> postfix_master_t --> postfix_pipe_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> uux_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> clamscan_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_bugzilla_script_t --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> daemon --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> systemprocess --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> sulogin_t --> unconfined_t --> dhcpc_t --> NetworkManager_t --> pppd_t --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> sulogin_t --> unconfined_t --> rpm_t --> rpm_script_t --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> sulogin_t --> unconfined_t --> rpm_script_t --> system_mail_t
httpd_t --> passenger_t --> system_mail_t
httpd_t --> httpd_bugzilla_script_t --> system_mail_t
httpd_t --> httpd_mojomojo_script_t --> system_mail_t

Note currently this command does not take into account boolean settings, it is just showing you that it is possible. Future enhancements would be to list the booleans required to allow the access.

Dan Walsh: New Security Feature in Fedora 18 Part 8: Introducing sepolicy network

dwalsh@redhat.com — 2012-10-27T11:57:24+00:00

One problem uses have with SELinux is understanding the network protections. SELinux controls which ports a domain is able to connect to and which ports it is able to bind to. Since SELinux is a type enforcement system, it controls ports access via types. Processes get assigned types and port numbers get assigned types. Since users think in terms of port numbers, we built a tool to more easily allow users understand the relationships. I orginally called this tool senetwork, but now we are shipping it as part of the sepolicy suite.

> man sepolicy-network
sepolicy-network(8)                                                                                                            sepolicy-network(8)

NAME
       sepolicy-network - Examine the SELinux Policy and generate a network report

SYNOPSIS
       sepolicy network [-h] (-l | -p PORT [PORT ...] | -t TYPE [TYPE ...] | -d DOMAIN [DOMAIN ...])

DESCRIPTION
       Use sepolicy network to examine SELinux Policy and generate network reports.

OPTIONS
       -d, --domain
              Generate a report listing the ports to which the specified domain is allowed to connect and or bind.

       -l, --list
              List all Network Port Types defined in SELinux Policy

       -h, --help
              Display help message

       -t, --type
              Generate a report listing the port numbers associate with the specified SELinux port type.

       -p, --port
              Generate a report listing the SELinux port types associate with the specified port number.

sepolicy network allows you to ask SELinux what port type is associated with a specific port number.

sepolicy network --port 8080
8080: tcp unreserved_port_t 1024-32767
8080: udp unreserved_port_t 1024-32767
8080: tcp http_cache_port_t 8080

Or what port number is associated with a port type.

sepolicy network -t dns_port_t
dns_port_t: tcp: 53
dns_port_t: udp: 53

Note that sepolicy also supports bash completion.

sepolicy network -t d<tab>
daap_port_t     dccm_port_t     dhcpc_port_t    dict_port_t     dns_port_t      dogtag_port_t
dbskkd_port_t   dcc_port_t      dhcpd_port_t    distccd_port_t dnssec_port_t

Finally you can ask which ports a process domain type is allowed to connect or bind:

# sepolicy network -d cupsd_t
cupsd_t: tcp name_connect
    all ports
cupsd_t: tcp name_bind
    reserved_port_t: 1-511
    rpc_port_type: all ports > 500 and < 1024
    ipp_port_t: 631,8610-8614
cupsd_t: udp name_bind
    howl_port_t: 5353
    ipp_port_t: 631,8610-8614

Dan Walsh: New Security Feature in Fedora 18 Part 8: Introducing sepolicy manpage

dwalsh@redhat.com — 2012-10-26T12:05:56+00:00

In my previous blog, I introduced the sepolicy command, today I am going to talk about sepolicy manpage. This is probably the most important command in the sepolicy command suite.

man sepolicy-manpage
sepolicy-manpage(8)                                                                                                            sepolicy-manpage(8)

NAME
       sepolicy-manpage - Generate a man page based on the installed SELinux Policy

SYNOPSIS
       sepolicy manpage [-w] [-h] [-p PATH ] [-a | -d ]

DESCRIPTION
       Use sepolicy manpage to generate manpages based on SELinux Policy.

OPTIONS
       -a, --all
              Generate Man Pages for All Domains

       -d, --domain
              Generate a Man Page for the specified domain. (Supports multiple commands)

       -h, --help
              Display help message

       -w, --web
              Generate an additonal HTML man pages for the specified domain(s).

       -p, --path
              Specify the directory to store the created man pages. (Default to /tmp)

We are now using this tool to generate hundreds of man pages to document SELinux policy on every process domain.
Each confined domains will have an _selinux extension added for example.

man httpd_selinux
httpd_selinux(8)                                      SELinux Policy documentation for httpd                                      httpd_selinux(8)

NAME
       httpd_selinux - Security Enhanced Linux Policy for the httpd processes

DESCRIPTION
       Security-Enhanced Linux secures the httpd processes via flexible mandatory access control.

       The httpd processes execute with the httpd_t SELinux type. You can check if you have these processes running by executing the ps command
       with the -Z qualifier.

       For example:

       ps -eZ | grep httpd_t
...

These are pretty extensive man pages including sections:

Process types associated with the domain, the tool attempts to associate all process types that begin with the same prefix as the target domain.
File Types associated with the domain. This will list all file types that are included in this policy. (Using the prefix to gather the information) The man page describes what the type is used for, along with the default path labelling on the system.
Booleans associated with the domain. The manpage lists all booleans matching the prefix and then describes what the boolean is used for.
Port Types associated with the domain. The manpage lists the port types matching the prefix and describes the default port numbers assigned to these port types.
Sharing Types associated with the domain. If the domain uses "Sharing Types" like public_content_t, the man page will have a section explaining how to use them.
Managed Files section describes the types that the domain is allowed to write and the default paths associated with these types.

This is pretty extensive documentation, and the beauty of it, is that it is automatically generated so it will not get out of date.
In Fedora 18, the man page for Apache is over 1600 lines long.

> man httpd_selinux | wc -l
1603

Currently in Fedora 18 we have over 700 man pages.

> man -k selinux | grep _selinux | wc -l
734

Miroslav Grepl is building a web site that will list all SELinux Policy Man pages for RHEL6, Fedora 17 and Fedora 18.

Dan Walsh: New Security Feature in Fedora 18 Part 8: Introducing sepolicy

dwalsh@redhat.com — 2012-10-26T11:27:36+00:00

Over the years people have struggled to understand SELinux Policy and how it confined applications. Administrators would want to know what types the Apache process can read or write. What booleans were available for samba. Can one domain write to the users home directory?

sepolicy python bindings

The tool suite we had to do this was called setools, which included apol (A tcl/tk graphical tool) and sesearch and seinfo. I found that I hardly ever used apol and mainly used sesearch and seinfo. But I wanted more control. I decided to add python bindings for these two commands, which in prior releases were in setools package. These python bindings were rejected for merging upstream, for whatever reason. I decided to move them into their own package sepolicy.

> python
Python 2.7.3 (default, Aug 9 2012, 17:23:57)
[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sepolicy
>>> sepolicy.info(sepolicy.ATTRIBUTE)
Returns a dictionary of all information about SELinux Attributes
>>>sepolicy.search([sepolicy.ALLOW])
Returns you a dictionary of all allow rules in the policy.

sepolicy command

Using these python bindings we have begun to build a new series of commands that I have found very useful for understanding policy. I decided to combine these tools into a new command line tool sepolicy.    Some of these tools I have blogged about in the past but now I have consolidated them into a single tool and made it part of the distribution. Over the next couple of blogs I will explain some of the tools.

> man sepolicy

sepolicy(8)                                                                                                                            sepolicy(8)

NAME
       sepolicy - SELinux Policy Inspection tool

SYNOPSIS
       semanage {manpage,network,communicate,transition,generate} OPTIONS

       Arguments:

       communicate
       Query SELinux policy to see if domains can communicate with each other sepolicy-communicate(8)

       generate
       Generate SELinux Policy module template sepolicy-generate(8)

       manpage
       Generate SELinux man pages sepolicy-manpage(8)

       network
       Query SELinux policy network information sepolicy-network(8)

       transition
       Query SELinux Policy to see how a source process domain can transition to the target process domain sepolicy-transition(8)

DESCRIPTION
       sepolicy is a tools set that will query the installed SELinux policy and generate useful reports, man pages, or even new policy modules.
       See the argument specific man pages for options and descriptions.

Dan Walsh: sandbox can now shred in Fedora 18 and RHEL7

dwalsh@redhat.com — 2012-10-26T10:33:34+00:00

I have heard from a couple of people who are real concerned about security, that they wanted sandbox to not only delete the content but to "shred" it on exit.

policycoreutils-2.1.13-17.fc18
policycoreutils-2.1.13-17.el7

man shred
...
DESCRIPTION
Overwrite the specified FILE(s) repeatedly, in order to make it harder
for even very expensive hardware probing to recover the data.

cat untrustedcontent | sandbox --shred sandbox -M filter.sh > /tmp/trustedcontent

or

sandbox -X -s -W metacity firefox

Dan Walsh: Process Confinement in Fedora 18

dwalsh@redhat.com — 2012-10-18T19:00:26+00:00

I have not done this blog for a while. Fedora 12?

A good estimate of the number of different confined processes is to count the number of types with the domain attribute.

seinfo -adomain -x | tail -n +2 | wc -l
707

Note: I am removing the first line because it lists the attribute name.

Not all domain types are confined. If we want to look at the number of unconfined domains, we can use the unconfined_domain_type attribute.

seinfo -aunconfined_domain_type -x | tail -n +2 | wc -l
61

Unconfined Domains
sosreport_t	bootloader_t	devicekit_power_t	nova_api_t
nova_network_t	dirsrvadmin_unconfined_script_t	nova_objectstore_t	certmonger_unconfined_t
unconfined_cronjob_t	abrt_handle_event_t	setfiles_mac_t	initrc_t
fsadm_t	lvm_t	mdadm_t	rpm_t
wine_t	nova_vncproxy_t	unconfined_dbusd_t	nova_volume_t
nova_scheduler_t	prelink_t	anaconda_t	boinc_project_t
nova_ajax_t	rpm_script_t	system_cronjob_t	openshift_initrc_t
samba_unconfined_net_t	kdumpctl_t	devicekit_disk_t	firstboot_t
samba_unconfined_script_t	nagios_eventhandler_plugin_t	httpd_unconfined_script_t	depmod_t
insmod_t	kernel_t	livecd_t	puppet_t
tomcat_t	apmd_t	clvmd_t	crond_t
inetd_t	init_t	udev_t	virtd_t
nagios_unconfined_plugin_t	rgmanager_t	devicekit_t	inetd_child_t
nova_direct_t	semanage_t	sge_shepherd_t	xdm_unconfined_t
unconfined_t	abrt_watch_log_t	sge_job_t	xserver_t

If you disable the unconfined policy package, which I recommend.

This leaves only user domains unconfined, along with some domains that do not make sense to confine. (anaconda, firstboot, kernel,rpm)

# semodule -d unconfined
seinfo -aunconfined_domain_type -x | tail -n +2 | wc -l
14

Unconfined Domains
rpm_t	anaconda_t	rpm_script_t	openshift_initrc_t
firstboot_t	kernel_t	livecd_t	unconfined_t

You can disable all unconfined domains by disabling unconfineduser module

# semodule -d unconfineduser

Note: You need to setup all your users as confined users, before removing the unconfineduser module.
Disabling the unconfined and unconfineduser policy modules is the equivalent of what we used to call strict policy.

One other interesting domain is permissive domains. Permissive domains can be listed with the --permissive qualifier.

# seinfo --permissive -x | tail -n +3 | wc -l
31

Permissive Domains
phpfpm_t	virt_qemu_ga_t	pkcsslotd_t	realmd_t
mandb_t	rngd_t	slpd_t	glusterd_t
stapserver_t	sensord_t

A couple of other interesting statistics.

Total number of file types.

seinfo -afile_type -x | tail -n +2 | wc -l
2375

In order to get the number of allow rules, you need to use sesearch

sesearch --allow | wc -l
81736

Dontaudit Rules

sesearch --dontaudit | wc -l
6532

Dan Walsh: New Security Feature in Fedora 18 Part 7: Secure Linux Containers

dwalsh@redhat.com — 2012-10-18T15:54:24+00:00

Secure Linux Containers

In Fedora 18 we have enhanced the libvirt-sandbox package to allow for easy creation of Secure Containers.

Containers are a form of isolating one or more processes from the rest of the system. Some times containers are described as lightweight virtualization. Containers are really just a userspace concept. The Linux kernel has no concept of a container. The kernel implements namespaces and cgroups. Userspace tools can combine these kernel services into a "container".

Namespaces

Namespaces are a way of changing a processes view of its environment from its parents processes. For example the file system namespace allows me to change a processes view of the file system hierarchy. pam_namespace introduced way back in Fedora 6/RHEL5, allowed a login program to create a namespace and mount file systems that would not be seen by the ancestor processes. Meaning I could have multiple processes with different /tmp directories and multiple home directories mounted on /home/dwalsh.

The kernel currently implements 5 name spaces.

mount - mounting and unmounting filesystems will not affect rest of the system
UTS - setting hostname, domainname will not affect rest of the system
IPC - process will have independent namespace for System V message queues, semaphore sets and shared memory segments
network - process will have independent IPv4 and IPv6 stacks, IP routing tables, firewall rules, the /proc/net and /sys/class/net directory trees, sockets etc.
pid - processes have an independent pids from the rest of the system. Each namespace can have its own pid 1.

Note: A UID namespace is being developed, but is not ready to be used yet, and I have some concerns about how well this will work. Our tools do not currently use the UID namespace.

pam_namespace, sandbox -X, unshare, systemd allow allow you to take advantage of namespaces.

CGROUPS

Wikipedia describes cgroups as:

cgroups (control groups) is a Linux kernel feature to limit, account and isolate resource usage (CPU, memory, disk I/O, etc.) of process groups.

Basically you can use cgroups to control the amount of resources a process or groups of processes can get on a system.
I put together a little screen-cast of cgroups to demonstrate their power.

LXC
Tools like LXC have existed for a while to allow users to create containers but the tool set is at a very low level.

Libvirt-lxc

"Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). The main package includes the libvirtd server exporting the virtualization support."

libvirt-lxc was introduced in Fedora 16. It enhanced the libvirt API to allow users to build containers using libvirt. This allows you to manage your kvm/qemu virtualization along with your linux containers, all within the same framework. The only problem, is setting up a linux container using the libvirt api is fairly difficult.

libvirt-sandbox

Dan Berrange created a new package called libvirt-sandbox in Fedora 17. The libvirt-sandbox package provides an application development library (libvirt-sandbox) to facilitate the embedding of virtualization into applications. One of the main advantages of this new tool set, was that it greatly simplified the API for creating virtual machines and containers.

SELinux

Using containers by itself does not give you good security separation. The reason for this is kernel file systems like /proc, /sys, cgroupsfs and selinuxfs are not containerized. A privileged process running within a container can affect other processes running outside of the container or processes running in other containers. In libvirt-sandbox and libvirt-lxc you can use SELinux Labelling to further lock down privileged processes, for example preventing mounting of random file systems or stopping processes from disabling SELinux.

virt-sandbox-service

Dan Berrange and I have been working to enhance libvirt-sandbox. We have added a command line tool called virt-sandbox-service which allows a user to easily create an application sandbox. virt-sandbox-service allows an administrator to run multiple services on the same machine each service in a secure Linux Container. Some major features of virt-sandbox-service containers.

Use systemd within the container as the init processes.
Uses standard unit files for starting and stopping containerized applications.
Shares the /usr partition, meaning if you are running hundreds of Apache containers, and update Apache code, each container will instantly use the new version of Apache.
Uses SELinux MCS Labelling to separate each container, preventing even root processes from interfering with the host or other containers.

The goal of this tool is not to allow general purpose applications to run within the container, although we will work to get most services to be able to run. The tool is not goaled at running full OS chroot, but more towards particular applications.

I have done preliminary tests on running. httpd, mysql, postgresql, dovecot within these containers. I am hoping people begin to play with the tool and help us expand which applications can run within the container. Also you can run multiple applications within a container at the same time. For example, I have tested httpd and mysql running within the same container.

How to use:

# yum install libvirt-sandbox httpd
There is a bug in the tool right now where it will not work without an /selinux file.
# touch /selinux

Use the virt-sandbox-service command to create a container.

virt-sandbox-service create -C -l s0:c1,c2 -u httpd.service container1
Created sandbox container dir /var/lib/libvirt/filesystems/container1
Created sandbox config /etc/libvirt-sandbox/services/container1.sandbox
Created unit file /etc/systemd/system/container1_sandbox.service

Manipulate the data within the container while running outside of the container.

cd /var/lib/libvirt/filesystems/container1/var/log
touch content
ls -lZ content
# Make sure the content gets created with the correct MCS label.
# Content should be labeled with s0:c1,c2 : Not s0

Now create a file with a bad label for the container.
cat "Secret" > badcontent
chcon -l s0:c3,c4 badcontent

Start the container:

virt-sandbox-service start container1

In another window

Make sure the processes are running with the proper SELinux label. ps -eZ | grep svirt_lxc You should see processes like systemd, systemd-journal, dhclient and httpd running within the container with the MCS label of s0:c1,c2

Connect to the container

virt-sandbox-service connect container1
id 
getenforce   # Should tell you SELinux is disabled.
setenforce 1 # Should be denied
touch /file  # Should deny you creating this file
touch /var/www/html/content  # Should be allowed
cat /var/www/html/badcontent # Should be denied
Configure the apache server any way you would like, and manipulate html pages
ifconfig eth0  # Grap IP Address for use on next test
# Use the shell running with in the container to attempt to break out of the container. 
^]

On your hosts Firefox use the IP within the container

firefox $IP # Using IP address from container, make sure you see the content.

Shut down the container

virt-sandbox-service stop container1

Now lets try to do the same but starting and stopping the container using systemctl commands

systemctl start container1_sandbox.service
systemctl enable container1_sandbox.service # Check on reboot if the container is running

Make sure the container is running.

virt-sandbox-service connect container1
ps -eZ
^]

I would like to hear what you think?  What enhancements you would like to see?  What 
applications would you like to see run within the containers.  

Since this is a first version, we think there could be some growing pains, so use at your own 
risk, but we would love to work with the community to improve this tool set.

Dan Walsh: New Security Feature in Fedora 18 Part 6: KRB5 Credential Cache Moved under /run/user directory

dwalsh@redhat.com — 2012-10-15T18:50:06+00:00

KRB5 Credential Cache Move

The default location of a user's Kerberos Credential Cache (CC) has moved from /tmp to user directory under /run/user.

Back in the 1980's, when Kerberos was first developed, various login programs were enhanced to talk to the Kerberos servers to authenticate users, and to store credentials (tickets and session keys) that they obtained while doing so in a file, sometimes called a ticket file, but now more commonly called a credential cache (ccache for short), for the user to use during their session.

The cache had to be owned by the user, so that additional tickets obtained by the user could be added to the cache, and so that it could be cleared or just destroyed.

For the sake of users whose credentials were needed for accessing a remote home directory, login programs could not store the credentials in the user's home directory. Since the only other location where a user could write to was the /tmp directory, the cache file was stored there by default.

Security Problems with the Credential Cache file in /tmp.

There were a couple of problems with storing the cache file in /tmp:

All users of the system can write to /tmp. To sidestep the possibility that a rogue user could trick the system into writing a user's credentials to an incorrect location, many login facilities would generate uniquely-named credential caches for users. Others used predictable but different names for various other reasons.
But when the name of a user's credential cache isn't predictable, it can cause problems for services which don't run as part of the user's session, and which therefore can't consult the $KRB5CCNAME environment variable to discover which cache to use. Services like these, for example rpc.gssd (the daemon which handles the client parts of Kerberized NFS), have historically had to make a best-guess as to what the Kerberos credential cache file's name was, and they had to do that by trawling through /tmp, looking for potential matches.
/tmp can be setup using pam_namespace such that processes running in the "root" namespace will see a different /tmp then the user sees when he logs in. This can prevent services from even being able to find the Credential Cache.
The /tmp directory is often not a temporary file system. Logging out of the system or rebooting the system would not guarantee the Credential Cache would be removed/destroyed.

SSSD to the rescue in Fedora 18

In Fedora 18 the Credential Cache file was moved by SSSD, System Security Services Daemon, to /run/user/UID/krb5cc_XXXXXX/tkt.
Where XXXXXX is a random number.

For example on my box when I execute klist i see the following:

> klist
Ticket cache: DIR::/run/user/3267/krb5cc_ca3a4331e17e8e80cb0c46ea507840bc/tkt
Default principal: dwalsh@REDHAT.COM

Valid starting Expires Service principal
10/12/12 12:48:17 10/12/12 22:48:17 krbtgt/REDHAT.COM@REDHAT.COM
renew until 10/12/12 12:48:17

Note: There are two colons between "DIR" and the path part of the ccache name gives away that the parent of the named path is the directory that's being used to hold the cache file (or possibly more than one cache file).

The main benefit here is that /run/user/3267 and all its sub-directories have a mask of 700 and are owned by dwalsh:dwalsh. No other users know that the cache is there, and they can't tell how big it is or when it was last touched. This means we don't have to deal with other users trying to mess around in /tmp.

Secondarily /run is always tmpfs, if the user logs out cache gets destroyed and if the system crashes the cache file is also gone.

Since the tickets are stored in a predictable path, privileged processes like rpc.gssd have an easy time finding the correct tickets. And since they are off of /tmp, pam_namespace will not hide the credential cache from the system services.

Finally now SSSD can actually get multiple tickets from different domains and easily store them in the /run directory, allowing a user
to login into multiple kerberos domains at the same time.

Dan Walsh: New Security Feature in Fedora 18 Part 5: Systemd Secures Journald from attack

dwalsh@redhat.com — 2012-10-09T14:14:05+00:00

Forward Secure Sealing (FSS)

Forward Secure Sealing is a new feature of systemd/journald in Fedora 18.

If your machine is cracked, (Did you disable SELinux?) and a hacker gets administrative control, he wants to cover their tracks, by modifying the system log files. This presents a problem in that you might not know when the machine was hacked and whether any of your log files have been tampered with. Before FSS the only way to know your log files have not been tampered with is to store them on a different machine, IE Setup rsysog and auditlogs to be sent to different machines. With FSS you can verify the journald logs on your system and know if they have been tampered with. Even better you will have an idea when the hacker started tampering with them, and which part of the logs files are still valid.

The basic idea is you establish a verification ID and store it externally or just use a QR code and store it on a smart phone.

Read Lennart Poettering posting on Google+ For more explanation.

Dan Walsh: New Security Feature in Fedora 18 Part 4: FreeIPA/SSSD distributes Confined SELinux Users

dwalsh@redhat.com — 2012-10-09T13:03:46+00:00

FreeIPA now supports the distribution of SELinux Users

Confined SELinux Users was introduced a while ago. The basic idea is to give users different access depending on the machine they log into.

Using myself as an example, I regularly login to 5 different machines, not including VMs. My Laptop, My Test machine, shell.devel.redhat.com, people.redhat.com and people.fedoraproject.com.

people.redhat,com and people.fedoraproject.com: I should login as guest_u:guest_r:guest_t:s0. These machines are used to share content via the Web Servers. I should be only allowed to modify my home directory. I should not have access to the network, setuid applications like su and sudo, or be able to build and execute code in the home directory.
shell.devel.redhat.com. This machine is a shared developer shell machine, to be used by all developers. I should be allowed to execute content in the home directory and maybe setup and test networking applications, since this is a development machine. But I am not an administrator, I should not be allowed to execute su or sudo. user_u:user_r:user_t:s0-s0:c0.c1023 would be a good SELinux user label for this machine.
My Laptop and test machines, (holycross and redsox), should either be setup to use unconfined_t or staff_t. In my case I run them with staff_u:staff_r:staff_t:s0-s0:c0.c1023, and administrator processes as staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023.

The problem with this configuration is that each one of these machines has to be setup individually. My identity is shared by a directory server and authorization is confirmed by kerberos. But until now, there was no standard way to setup these confined users on a centralized server.

One big advantage of FreeIPA is it adds identity to machines. FreeIPA knows the difference between dwalsh on people.redhat.com versus dwalsh on shell.devel.redhat.com. The FreeIPA team added the ability to store SELinux Users definitions based on User/Machine mappings.

In Fedora 18 you will be able to setup confined users using the FreeIPA gui.

At Red Hat we could setup a user/machine mapping like all users on people.redhat.com will login with the SELinux user/level guest_u:s0.

SSSD plays a large role in assigning the SELinux User/Level from IPA to the user process at login.

When a user logins to a box say through sshd, sshd uses the pam stack. One of the first pam modules used is pam_sss. pam_sss sends a request to SSSD telling it that dwalsh is logging in. SSSD contacts the FreeIPA server and asks what SELinux User/Level should dwalsh get when he logs in. SSSD takes the string returned and creates a file in /etc/selinux/POLICYTYPE/logins/dwalsh. During the session of the pam stack, the pam_selinux module is called. pam_selinux reads /etc/selinux/POLICYTYPE/logins/dwalsh and tells the kernel to launch the user process with the SELinux User specified in FreeIPA, for example guest_u:guest_r:guest_t:s0.

Currently SSSD only supports FreeIPA for this transaction. In the future it could be modified to use other sources for SELinux information.

Note: In FreeIPA you can set up a set of the Host Based Access Control rules. These rules define which users (and groups of users) have access to which machines (and groups of machines) via which login services (like ssh, ftp, sudo, su etc.) The administrator can reuse the user-host associations defined in the HBAC rules to define SELinux user mapping rules. This helps to avoid duplicate management and express a notion: user set X can access set of hosts Y and would get SELinux user Z.

I have been asked many times when I have given the Confined SELinux Users talk, about how would you manage confined users in a large environment, now we have a solution.

Dominick Grift: Easy ways to help improve refpolicy contrib

Dominick "domg472" Grift (noreply@blogger.com) — 2012-10-08T06:21:59+00:00

Here is what you can do to help improve refpolicy contrib for your distro and everyone else:

1. See if the file context specification from the various modules in refpolicy contrib match the locations of the corresponding packages that your distribution uses.

Here is how i do that on Fedora:

I basically check each modules file context files.

Find which package installs the executable file, either with the full path or if my package manager cannot find that using a wild card:

yum whatprovides /usr/sbin/someapp

or if it cannot find that:

yum whatprovides *\someapp

Then you should figure out which (applicable) locations that package installs.

Applicable locations are among others:

/etc/someapp /etc/sysconfig/someapp /etc/default/someapp /var/lib/someapp /var/log/someapp /var/spool/someapp /etc/init.d/someapp /etc/rc.d/init.d/someapp /var/run/someapp /var/cache

In Fedora i use the handy repoquery tool for that. This tool allows me to list the files that a specificied package installs without me actually having to install the package

Example:

repoquery -ql someapp | less

Labeling files properly is very important for SELinux operation and so you can improve your distributions SELinux experience by making use applicable files and locations are labeled correctly by fixing or adding the appropriate file context specification.

2. Somewhat related to (1): label service etc files with a declared private type for etc files and allow the service to read files it owns with the private type, then also allow the "service"_admin() to find and manage content with that type.

In the past we only use to label service etc files with a private"files config file" private type if the file has sensitive information.

Later we came up with an idea to confine root using "service"_admin interfaces that give the caller access to manage a particular service and its files.

However we do not want to give the "service"_admin access to manage generic etc_t files since that will allow the process to manage things it shouldnt, instead of just the configuration files for the service that the caller is allowed to manage.

So we need to find each config file a confined service owns label that with a declared "files_config_file" file type, allow the owning service to read applicable content with that type and allow the service admin to get to and manage content with that type.

You can use the method of (1) to find which etc files a package installs where

Then if needed declare a new files_config_file type

type someapp_conf_t;
files_config_file(someapp_conf_t)

Then make sure the file or directory is labeled correctly in the file context file. Some examples:

Single configuration file:

/etc/someapp\.conf -- gen_context(system_u:object_r:someapp_conf_t,s0)

A configuration directory and all its contents:

/etc/someapp(/.*)? gen_context(system_u:object_r:someapp_conf_t,s0)

Then allow the service domain type to read the content:

in case of a single file:

allow someapp_t someapp_conf_t:file read_file_perms;

in case of a directories and its contents:

read_files_pattern(someapp_t, someapp_conf_t, someapp_conf_t)

If your service domain type is not already allowed to read generic etc_t files (e.g. if it does not have a rule similar to for example: files_read_etc_files(someapp_t) then you will also need to allow the service domain type to traverse etc_t directories so that it can actually get to there:

files_search_etc(someapp_t)

If the module has a service admin interface, for example someapp_admin in the someapp.if interface file, then add the rules that will allow the caller to get to and manage content with the new type:

a. Import the type by adding for example;

type someapp_conf_t;

to the existing "gen_require(`')" block on top of the interface.

b. Add the rules to allow caller to get to and manage the content with the new type , for example:

files_search_etc($1)
admin_pattern($1, someapp_conf_t)

Note: also consider environment files in /etc/sysconfig. We would want the service administrator to be able to manage those as well.

If you are unsure about some specifics then look into existing source policy modules. Much efford goes into writing these modules as consistently as possible.

This allows you to see patterns easily and will help you read the policy.

Dan Walsh: New Security Feature in Fedora 18 Part 3: New Confined/Permissive Process Domains

dwalsh@redhat.com — 2012-10-04T14:32:16+00:00

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.

In Fedora 17, we added 11 new permissive domains, 10 of which are now enforcing in Fedora 18. matahari policy was removed, since the project was cancelled.

Fedora 17 Permissive Domains/ Now Confined in Fedora 18

couchdb_t, blueman_t, httpd_zoneminder_script_t, zoneminder_t, selinux_munin_plugin_t, sge_shepherd_t, sge_execd_t,
sge_job_t, keystone_t, pacemaker_t

Fedora 18 Permissive Domains

   pkcsslotd_t (daemon manages PKCS#11 objects between PKCS#11-enabled applications)
   slpd_t (Server Location Protocol Daemon)
   sensord_t (Sensor information logging daemon)
   mandb_t (Cron job used to create /var/cache/man content)
   glusterd_t (policy for glusterd service)
   stapserver_t (Instrumentation System Server) Note: This was back ported to Fedora 17.
   realmd_t (dbus system service which manages discovery and enrollment in realms and domains like Active Directory or IPA)
   phpfpm_t (FastCGI Process Manager)

Fedora 18 Confined Domains
With the open sourcing of OpenShift we have created several new process domains. openshift controls separation between each of its users and users applications, which means it needs to be confined out of the box. openshift_t is the type that each application runs as, with a difference MCS label. I will blog on the openshift policy in the future.
      openshift_app_t, openshift_cgroup_read_t, openshift_initrc_t, httpd_openshift_script_t, openshift_t

Fedora 18 Domains Removed
matahari (Project cancelled)

Fedora 18 Domains Reorganization
We split sandbox and sandboxX policy apart, in order to shrink the policy size. and now disable sandbox policy by default. We are doing this because not many people use sandbox (Character only version of sandbox, used for pipes and streams) versus sandboxX. sandbox policy is very big, and disabling by default reduces the size of policy by around 8%.

Dan Walsh: New Security Feature in Fedora 18 Part 2: Mutual Trusts with Active Directory domains

dwalsh@redhat.com — 2012-10-01T15:45:30+00:00

FreeIPA has a couple of new features that are showing up in Fedora 18. Support for SELinux Confined User labelling will be covered in a future blog... In this blog I will be talking about better integration with Windows environments.

I am saddened to realize that there are still people out there using Microsoft Windows!

My house has been Windows free for a number of years now. It is a lot darker, but much more secure! :^)

I also have heard that those Windows environments are using Active Directory.

Well Fedora 18 will make these environments a little more secure.

FreeIPA and Active Directory can be setup with mutual trust.

In Fedora 18 it is possible to create a trust relationship between an FreeIPA and an Active Directory domain. This means users defined in Active Directory can access resources defined in FreeIPA. In a future release, users defined in FreeIPA will be able to access resources defined in Active Directory. You can manage all of your user accounts in a single place. If you are using Active Directory to manage your users, you can now use the same user accounts on your Linux boxes.

Fedora 17 FreeIPA used winsync to allow users from an Active Directory domain to access resources in the IPA domain. To achieve this winsync had to replicate the user and password data from an Active Directory server to FreeIPA server and attempt to keep them in sync. Causing potential race conditions.

In Fedora 18, SSSD, System Security Services Daemon, has been enhanced to work with AD. SSSD understands some of the native AD controls and features that it did not understand in the previous Fedoras.

You can set this up without using FreeIPA at all!

In addition SSSD can work in the environment where it is connected to FreeIPA that is in trust relationships with AD. In this case, SSSD not only recognises users defined in FreeIPA but also recognizes users coming from the trusted AD domains. SSSD can read user and group directory data directly from the Active Directory server.

Additionally if you do use FreeIPA you can setup Kerberos cross realm trust. This allows Single-Sign-On between the Active Directory and the IPA domain.

A user from the Active Directory Domain can access kerberized resources from the FreeIPA domain without being asked for a password.
If you choose to setup users in the FreeIPA Domain, they will be able to access resources from the Active Directory domain. No need to set POSIX attributes in the Active Directory Domain
Single sign-on for all kerberized services is possible

We may never get to full single sign on, where I only have one password asked of me, but this is a step in right direction.

Dominick Grift: Determine whether Cron can execute jobs on behalf of the user with login user SELinux permissions

Dominick "domg472" Grift (noreply@blogger.com) — 2012-09-30T12:07:20+00:00

Cron would run jobs on behalf of users in a "cronjob" domain. This domain is reasonable restricted compared to the domain in which most users operate.

Fedora changed this behaviour to allow Cron to execute these jobs in the default login user domain of the user that owns the job.

Recently i added a boolean to Reference policy that enables one to tune the policy to allow Cron to run user cronjobs in the default login user domain conditionaly.

By default Cron will still execute the jobs in the Cron job domain but if you toggle the cron_userdomain_transition boolean to true then Cron will run the jobs in the default login user domain of the user owning the job.

This allows Cron to run jobs with the SE-Linux permissions that the owner of the job has.

Cron is SELinux aware. It queries the policy to see to which domain it should transition when running a job.

It does not do a automatic domain transition because it does not actually execute the Cron job. Instead if uses "setexec" to domain transition.

It looks to see to which domains the Cron job file is a entrypoint. Then it needs to be able to process transition to that domain and then it checks the default login user domain of a user and with this information it determines in which domain to execute the job

By default:

allow cronjob_t user_cron_spool_t:file entrypoint;
allow crond_t cronjob_t:process transition;

Then there is a default context of for staff this is for example:

system_r:crond_t:s0 staff_r:cronjob_t:s0

But when you tune the policy with cron_userdomain_transition then these rules will be replaced by:

allow $1 user_cron_spool_t:file entrypoint;
allow crond_t $1:process transition;

Where $1 is the calling login user domain, and then it will look up the default login user domain and role, for staff this is for example:

# semanage user -l | grep staff_u
staff_u user SystemLow SystemLow-SystemHigh staff_r sysadm_r system_r unconfined_r

That means:

"staff_r:staff_t"

Then Cron daemon has permission to run the job in the staff domain with the staff role.

The benefits of running jobs in the login user domain are that now your Cron job can interact with your processes and operate on your files as if it were you interacting with your processes and operating on your files.

Needless to say that other SE-Linux rules that apply to you now also apply to your Cron jobs.

The policy may still have some rough edges but it was tested on Gentoo and is said to work. I did make some changes after that but hopefully i have not introduced regression.

Currently Redhat distributions do not have this cron_userdomain_transition boolean and i am not sure if she will adopt it.

Dan Walsh: Where does SELinux allow my application to write?

dwalsh@redhat.com — 2012-09-28T12:40:43+00:00

SELinux's Number one goal:

Stop confined application/process from affecting other processes on the system.

One of the biggest ways that a process can affect another process is by writing content that that process reads.

If a hacked process can write ~/.bashrc in a users home directory; the next time the user logs in, the hacker gets control of a process running as unconfined_t.
If a hacked process can write to /etc/httpd/config, the hacker gets control of the Apache process.

Because of this SELinux blocks confined applications the ability to write content, unless the directories/files have the proper labels.

Users want to know:

What label is my application allowed to write to?
Where on the file system are these labels?

For example in another blog, I got asked today where can mozilla_plugins write their logs?

Well in an effort to better document SELinux policy we have been auto-generating man pages, and have just added a new section called MANAGED FILES. This section of the man page will list the files/directories that a confined application is able to write.

man mozilla_plugin_selinux
...
MANAGED FILES
       The SELinux user type mozilla_plugin_t can manage files labelled with
       the following file types. The paths listed are the default paths for
       these file types. Note the processes UID still need to have DAC per‐
       missions.

       gnome_home_type

       home_cert_t

            /root/.cert(/.*)?
            /home/[^/]*/.kde/share/apps/networkmanagement/certificates(/.*)?
            /home/[^/]*/.pki(/.*)?
            /home/[^/]*/.cert(/.*)?

       mozilla_home_t

            /home/[^/]*/.java(/.*)?
            /home/[^/]*/.adobe(/.*)?
            /home/[^/]*/.gnash(/.*)?
            /home/[^/]*/.galeon(/.*)?
            /home/[^/]*/.spicec(/.*)?
            /home/[^/]*/.mozilla(/.*)?
...

In Fedora 18, we now have 951 man pages related to SELinux.

> man -k selinux | wc -l
951

We will be generating these Man Pages in Fedora 17 and RHEL6/RHEL6 and hope to put them up on a web site so that "search engines" will have an easier time searching them.

You can generate your own man pages using these tools, which should be showing up in policycoreutils soon.

http://people.fedoraproject.org/~dwalsh/SELinux/genman/segenman
http://people.fedoraproject.org/~dwalsh/SELinux/genman/senetwork.py

Dan Walsh: New Security Feature in Fedora 18 Part 1: SELinux Systemd Access Control

dwalsh@redhat.com — 2012-09-27T13:21:17+00:00

For Fedora 17 I did a series of blogs on new security features. I guess it is time to start it for Fedora 18.
If you want me to talk about a new security feature, email dwalsh@redhat.com, or comment on this blog.

New Feature in Fedora 18 SELinux Systemd Access Control.

In previous versions of Fedora/RHEL SELinux could control which processes were able to start/stop services based on the label of the process and the label on the Init Script.

For example NetworkManager (NetworkManager_t) was allowed to execute /etc/init.d/ntp (ntp_initrc_exec_t) but not allowed to access /etc/init.d/httpd (httpd_initrc_exec_t).

With the advent of systemd we lost this ability since systemd starts and stops all services.

We had to allow NetworkManager (NetworkManager_t) to execute systemctl which would send a dbus message to systemd, and systemd would start/stop whatever service NetworkManager requested. Actually we ended up allowing NetworkManager to do everything systemctl could do. We also wanted to setup confined administrators, but we ended up having to allow them to either start/stop all services or no services. We could no longer allow the webadm_t to only start/stop httpd_t.

In Fedora 18, we have fixed this by making systemd an SELinux Access Manager. Now systemd will retrieve the label of the process running systemctl or the process that sent systemd a dbus message. systemd will then look up the label of the unit file that the process wanted to configure. Finally systemd will ask the kernel if SELinux policy allows the specific access between the process label and the unit file label. This means a hacked NetworkManager or any other application that needs to interact with systemd for a specific service can now be confined via SELinux. Policy writers can use these fined grained controls to confine administrators.

Policy changes.

We have added a new class to SELinux Policy called "service". The service class has the following permissions defined:

start stop status reload kill load enable disable

This means a policy writer can allow a domain to get the status on a service or start and stop a service, but not enable or disable a service. This gives us better control then we have ever had in the past.

To demonstrate this, I setup webadm_t as my root process:
Note: For more information on setting up confined users see my other blogs.

# id -Z
staff_u:webadm_r:webadm_t:s0-s0:c0.c1023
# /bin/systemctl status httpd.service
httpd.service - The Apache HTTP Server
    Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
    Active: inactive (dead)
    CGroup: name=systemd:/system/httpd.service

# /bin/systemctl status NetworkManager.service
Failed to issue method call: SELinux policy denies access.

In a separate window running as unconfined_t, I can look at the AVC message created.

# id -Z
staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# ausearch -m user_avc
time->Thu Sep 27 08:54:10 2012
type=USER_AVC msg=audit(1348750450.105:135): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=3267 uid=0 gid=0 path="/usr/lib/systemd/system/NetworkManager.service" cmdline="/bin/systemctl status NetworkManager.service" scontext=staff_u:webadm_r:webadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:NetworkManager_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

And of course you could use audit2allow to write policy to allow this access.

audit2allow -la
#============= webadm_t ==============
allow webadm_t NetworkManager_unit_file_t:service status;

# audit2allow -laR
#============= webadm_t ==============
networkmanager_systemctl(webadm_t)

Make sure you have the latest systemd and selinux-policy to try this out. These are my current versions:

rpm -q selinux-policy systemd
selinux-policy-3.11.1-26.fc18.noarch
systemd-191-2.fc18.x86_64

Paul Moore: My LPC and LSS 2012 Presentations

2012-09-12T22:00:29+00:00

I gave a brief presentation on virtualization security at the Linux Plumbers Conference this year as well as a lightning talk on seccomp/libseccomp at the Linux Security Summit. The slides for both presentations are available below.

Virtualization Security Discussion: http://www.paul-moore.com/files/lj/virt_security-pmoore-lpc2012-r1.pdf
Syscall Filtering Made (sort of) Easy: http://www.paul-moore.com/files/lj/libseccomp-pmoore-lss2012-r1.pdf

James Morris: Linux Security Summit 2012 – Slides published

jamesm — 2012-09-10T14:40:40+00:00

Slides from the Linux Security Summit 2012 talks are now available via the schedule page.

It seems to have been a very successful event, with the move to a two-day format allowing for a day of refereed presentations, and then a day of more collaborative discussion. We’re aiming for a a similar format next year.

Thanks to everyone who made the event happen: presenters, attendees, the program committee, and of course, the great team at Linux Foundation, who made everything work flawlessly!

ETA: The slides from Matthew Garrett’s keynote on UEFI Secure Boot are now up.

Dan Walsh: Running unconfined scripts from a confined domain

dwalsh@redhat.com — 2012-09-05T19:31:27+00:00

I received the following email from an engineer named Marko.

I've got a program (actually a shell script) which does various things and sudoers is configured so that users can run it without a pw being asked. By using sudo from the cmd line everything works as expected.

However, if the script is invoked by udev rules (and thus run as root) under certain circumstances, it fails on several cases due to AVCs as the commands it is trying to execute won't work or the services it starts/stops fail partially as the context (udev_t) is not what it'd be when run with sudo from the command line. Examples include inability to communicate with dbus, accessing log/config files, etc. So figuring out all of those would be quite a task and if the local program is later changed it might require even more policy changes.

So what would a custom policy look like for a program "foo" so that it would work equally well when invoked by udev like it now works when a user invokes it from the command like with sudo? Any examples, blog posts, howtos, etc to look at?

Basically since his users are most likely running as unconfined_t, the sudo command is running the script as unconfined_t and SELinux is not blocking anything. When he runs the command out of udev, it is running as udev_t and udev_t is not allowed the access.

To solve this problem, Marko has three choices:

Add the allow rules to allow udev to have all the access required to run his application
Write policy for his application and transition from udev and unconfined_t to this new domain.
Write policy to allow udev_t to transition to unconfined_t when running only his application.

Since Marko did not want to all udev scripts this access, he chose not to do 1. Marko decided it would be to difficult to do 2 and difficult to maintain, so he chose to do 3.

Here is the original policy written by Marko.

# cat myapp.fc /usr/sbin/myapp --
gen_context(system_u:object_r:myapp_exec_t, s0)

# cat myapp.te
policy_module(myapp, 1.0.0)

require {
   type fs_t; type setfiles_t;
   type udev_t; type unconfined_t;
   class process transition;
}

type myapp_exec_t;

allow setfiles_t myapp_exec_t:file { getattr relabelto };
allow myapp_exec_t fs_t:filesystem { associate };

allow unconfined_t myapp_exec_t:file *;

domain_auto_trans(udev_t, myapp_exec_t, unconfined_t);

Not bad.

The first problem I notice is lots of rules around myapp_exec_t. Since the myapp_exec_t was never defined as a particular TYPE of type. Since myapp_exec_t is planned to be used on a file or directory it needs to have the attribute file_type. All domains that interact with all files/directories, have rules defined in policy which allow them to interact with the attribute file_type. You can add the file_type attribute to a file by using the files_type(myapp_exec_t) interface. This will eliminate most of the rules involving myapp_exec_t.

As a rule of thumb, anytime you define a new type in policy you should call an interface to define the "TYPE" of the type. domain_type() for processes, files_type for files/directories, dev_node() for devices corenet_port() for network ports etc.

Here is a my simpler policy.

policy_module(myapp, 1.0.1)
gen_require(`
type udev_t;
type unconfined_t;
role system_r;
')

type myapp_exec_t;
files_type(myapp_exec_t)

domain_auto_trans(udev_t, myapp_exec_t, unconfined_t);
allow unconfined_t myapp_exec_t:file entrypoint;
role system_r types unconfined_t;

The domain_auto_trans rule tells the SELinux kernel, when a process labeled udev_t executes a file labeled myapp_exec_t, transition the new process to unconfined_t.

SELinux controls the labels of "entrypoint", so we need to state that myapp_exec_t is an entrypoint to the unconfined_t domain.
For a further description of the entrypoint access see: SELinux By Example 2.2.4

Finally I added the role definition for system_r, since udev_t will be running as system_r, when it executes myapp_t it will attempt to run unconfined_t was system_u:system_r:unconfined_t:s0. roles system_r types unconfined_t, states that the unconfined_t type can be executed in the system_r role.

While the ideal solution for this problem from a security point of view would have been to write policy for myapp_t, and have unconfined_t and udev_t transition to this domain, as a work around and not shutting SELinux off this is a decent alternative.

Note: When ever you write a shell script that will have more privs then the calling app, you should be really carefull that the calling application can not effect the running app. The script needs to up its environment and ignores stuff from the calling program, if the script takes arguments you must be sure these arguments are handled properly and can not get the script to do something unexpected. SELinux will protect you somewhat but you need to be careful. Every python scripts I write, I always use "#! /usr/bin/python -Es" for example. Apple has a nice page on this.

Thomas Biege (Security): SUSE Cloud: How we secured the Cloud

Thomas (noreply@blogger.com) — 2012-09-03T03:59:56+00:00

Yes we did it! We created SUSE Cloud, based on OpenStack, to provide a software stack for IaaS providers and companies that want to create purpose out of their bare metal IT equipment, to build private clouds as easy as installing RPM files.

The project was very ambitious; integration work, bug fixing, adding features, packaging, testing, and finally releasing a cloud software stack with a SUSE gecko on it within less than 7 month.

I was asked to take care of the security. It was a challenge because I was not familiar with the inherit security issues of Cloud technology and I had to realize that OpenStack was very complex. Additionally security seems not to be a major concern when OpenStack was designed. Don't get me wrong, the upstream developers have a well working security team, quick patches, professional response and process handling. But for example OpenStack makes heavy use of RESTful APIs which are publically available, authentication (authC) is password-based, connections were not encrypted by default, passwords are send over the wire without encryption, and so on.

Even if the start of the project was very challenging for everyone involved it was a great success at the end. Let me tell you in this blog how we managed to ship the most secure OpenStack-based Cloud solution. But at first kudos to all people that helped making it possible. I had a lot of help from the SUSE Cloud team, then two of my former team-mates from the SUSE Security-Team (Sebastian Krahmer, Matthias Weckbecker) built the powerful validation and verification team to test the software for vulnerabilities based on an initial risk assessment, and last but not least, the OpenStack (especially the secuirty guys) community which is incredible!

The secure application development process

As you know from my ealier postings, we introduced something equal to Mircosofts "Secure Developemt Life Cylce" process and I called it SAD, Secure Application Development. (Not very clever but good to remember)
In this case we do not develop the stack from scratch, we do integration and add features. So, I had neither influence on the secure coding standards used nor on the code quality. Therefore we were limited to define security requirements and drive the "Verification and Validation" (V&V) process.

How to find a Needle in a Haystack

... at the end you will see that we found many "needles".

When you try to get familiar with Cloud Computing you will stumble through a field of marketing buzzwords, various commercial Cloud providers with very special/limited solutions, different security guidelines and so on and so on... maybe you will feel lost.
Well that was the way I felt when I started. I wanted to find Cloud-specific attack vectors / risks which are unique to this new technology... but there isn't much new technology involved in Cloud Computing and there isn't much research of the new stuff. So, where to start?

I decided to start with the things I know best and which are exposed to attackers, not only to grab the low hanging fruits first but also to save some time because time was something we didn't have for this project. These easy wins could be:

Web-security issues of the Dashboard
deployment issues, like file permissions, host and network hardening
API security

Therefore my risk assessment was focused on these attack vectors.

Security Requirements

The German Federal Office for Information Security (BSI) provides some simple and effective security requirements for Cloud Service Providers which I prefered to use because we are a German company and the set of recommendations is manageable.

Our Testing

My testing suite based on the OWASP testing guide v3
Fuzzing
API fuzzing
Manual reviews
Code reviews
Regression testing

Vulnerabilities and Hardening

CVE-2012-2094: The log viewer of the Dashboard was vulnerable to an XSS attack.
CVE-2012-2144: One of the first bugs we found was a Session Fixation vulnerability in the Dashboard
CVE-2012-3360: (lpd#1015531) The Nova API was vulnerable to Path Traversal which allowed remote users to overwrite arbitrary files with chosen content.
CVE-2012-3537 The crowbar ohai plugin insecurely handles temp. files which leads to local privilege escalation
CVE-2012-3540: Just a few days before the Gold Master we found an Open Redirect vulnerability using the next= paramater, that would allow a remote attacker to execute a Phishing attack.
CVE-2012-3551: A simple XSS attack was possible using the file= parameter.
lpd#963098 and lpd#948317: Guessing passwords was very easy, there is no way to specify a mandatory password policy for newly created users in the Dashboard, authentication violations weren't logged by Keystone, and there is no limit per client for guessing passwords. We tried to introduce cracklib to enforce a password policy, but it was just "a" policy not the one the CSP would like to use, therefore a configureable regex was introduced in local_settings.py, BTW, don't foret to enable it. Additionally our Keystone server logs authentication violation in /var/log/keystone now. A rate limit to stop online password guessing will be introduced later.
lpd#1006414 : Remote command execution via pickle. No CVE-ID assigned, severity unclear.
With SUSE Cloud it is possible to enable SSL for the API, the Dashboard (Session Cookies use "secure" and "httpOnly" flag in SSL mode), the VNC server, etc. All this interfaces to the Cloud are used via the Internet and are therefore easy to attack.
OpenStack, crowbar, ceph come with a lot of configuration files, a lot of them contain passwords, keys and other sensitive information. These files are not world-readable anymore in SUSE Cloud.
Default passwords/secrets/keys (for example to secure session cookies) are a big problem in current web-frameworks like Rails or Django, especially when you use cloned images in a VM. (Django's SECRET_KEY was fixed, take care yourself about static secrets)
Fuzzing the RESTful APIs of Nova/Compute and Keystone was done using the fuzz_xmlrpc.pl script and did not reveal any additional suspicious actions (beside watching logs and error messages, behavior was monitored with an inotify and exec monitor). This testing was sufficient for the first round.
... and various other tiny issues...
... about 40% of the current Essex security issues were found by us.

Lessons learned

Agile development is something I really like, it doesn't try to tame the chaos, it is just open, pragmatic, and adaptive. The problem is that the code changes very often and even lately. This can cause failures to re-occurre therefore automatic regression testing is very important. (CI server)
To make automatic regression testing effective it is very important for security engineers to create testcases (proof-of-concept exploits) which is time consuming but a clear proof of the problem which helps developers to understand the problem, and to reproduce it automatically.
Even if creative minds, which security engineers are IMO, didn't like it, but risk assessment based on design analysis is the key element to be successful.

What will come next?

Automatic security tests are my major concern for the next product release, this would minimize regressions and gives the security engineers the time to concentrate on more sophisticated attacks as well on focusing on design improvements. I will try to leave my microcosm and get more involved in the upstream development as well as defining meaningful security guidelines for CSPs and for Cloud Computing software stack developers.
This project brings a lot of joy and the next major release will become even more secure ... so remember to have fun! :-)

James Morris: Linux Security Summit 2012 – Schedule update

jamesm — 2012-08-29T04:41:52+00:00

Just to let folks know who are attending, we’ve added a lightning talks slot to the LSS 2012 schedule, on Friday 31st August at 2pm.

If you have any emerging topics to discuss, come along on the day and contact me to schedule a slot. We have one confirmed talk already: Dave Jones will be discussing his Trinity system call fuzzing work.

Note that this change pushes the LF Linux Security Workgroup BoF back thirty minutes.

KaiGai Kohei: mod_selinuxのアーキテクチャを考える(後編)

kaigai — 2012-08-17T20:53:30+00:00

前回の記事では、現在の mod_selinux モジュールの問題点を解決するために複数のタスクキューにワーカースレッドを紐付ける方法を考え、そこから一歩考察を進めて、FastCGIを使ってマルチプロセス実装にすればよりセキュアなWebアプリケーション環境を実現できるのではないか？というアイデアを紹介した。

実際にやってみた。

もちろんSELinuxの権限に紐付けてリクエストの送出先を切り替えるFastCGIモジュールは存在しないので、既存のものに少し手を加える事にする。今回は（たぶん最も広く使われているであろう）mod_fcgidをベースに修正を加える事にする。

mod_fcgidモジュールではFcgidWrapperディレクティブを使って、例えば .php 拡張子を持つURLが指定された場合、FastCGIプロトコルを介して/usr/bin/php-cgiにリクエストを処理させるという指定ができる。
例えばこんな感じ。

AddHandler      fcgid-script     .php
FcgidWrapper    /usr/bin/php-cgi .php

で、mod_fcgidのソースを読んでみて気が付いたのだが、この人はFastCGI常駐プログラムが既に起動しているかどうかをチェックするために、内部テーブルをスキャンして、動作中のプロセスを起動したときのコマンドライン文字列（要はFcgidWrapperで指定した内容）と、これから起動するFastCGI常駐プログラムのコマンドライン文字列を比較するという処理を行っている。
そうすると、仮にラッパープログラムのコマンドライン文字列の一部を、HTTPリクエストを処理するセキュリティコンテキスト（あるいはユーザIDでも可）で置換するような仕組みを作ってあげれば、FcgidWrapperを次のように指定するだけで、後はmod_fcgidが善きに計らってくれる。

FcgidWrapper  "runcon %(SELINUX_CONTEXT) /usr/bin/php-cgi" .php

例えば、HTTPユーザ alice の場合に %(SELINUX_CONTEXT)が "system_u:system_r:httpd_t:s0:c0" に置換されたら、この設定内容は次のコマンドと等価である。おそらく、認証モジュールで設定するようなHTTP環境変数か何かを使うのが汎用的な実装だろう。兎に角、%(SELINUX_CONTEXT)の部分を動的に置換するというのがポイントである。

FcgidWrapper  "runcon system_u:system_r:httpd_t:s0:c0 /usr/bin/php-cgi" .php

もう一点。PHPのような動的コンテンツであれば既存のFastCGIの設定と同様にできるが、静的コンテンツの場合、apache/httpdはhandlerフックの一番最後で他のモジュールが処理できないタイプのHTTPリクエストを処理する…という流れになる。
つまり、ap_hook_handler() に APR_HOOK_LAST を付けて関数ポインタを登録し、静的コンテンツを読むだけのFastCGI常駐プログラムを実行するような拡張が必要になる。

この２点の魔改造を加えた mod_fcgid がこちら。
https://github.com/kaigai/mod_fcgid

KaiGai版 mod_fcgid のインストールと設定

mod_fcgid(魔改造版)のインストールは以下の通り。

$ git clone git://github.com/kaigai/mod_fcgid.git
$ cd mod_fcgid
$ git checkout --track origin/defhnd
$ ./configure.apxs && make
$ sudo make install

Apache/httpdの設定ファイルを編集。ここでは、.php ファイルに対してrunconを介して/usr/bin/php-cgiを実行するのと同時に、静的コンテンツに対してはfcgi-cat(後述)コマンドを実行する。
runconの引数に%(AUTHENTICATE_SELINUX_TYPE)と%(AUTHENTICATE_SELINUX_RANGE)が付いているが、これは実行時にHTTP環境変数と置換される。で、この環境変数を設定するのがauthn_dbd_moduleで、AuthDBDUserPWQueryが2個以上のカラムを返すとき、それらの内容はHTTP環境変数として後続のモジュールで参照する事ができる。

LoadModule fcgid_module      modules/mod_fcgid.so
LoadModule dbd_module        modules/mod_dbd.so
LoadModule authn_dbd_module  modules/mod_authn_dbd.so

DBDriver    pgsql
DBDParams   "host=localhost dbname=web user=apache"

AddHandler      fcgid-script  .php
FcgidWrapper    "/bin/runcon -t %(AUTHENTICATE_SELINUX_TYPE)  \
                             -l %(AUTHENTICATE_SELINUX_RANGE) \
                     /usr/bin/php-cgi" .php
FcgidDocumentWrapper  "/bin/runcon -t %(AUTHENTICATE_SELINUX_TYPE)  \
                                   -l %(AUTHENTICATE_SELINUX_RANGE) \
                           /usr/local/bin/fcgi-cat"

<Directory "/var/www/html">
# BASIC authentication
AuthType    Basic
AuthName    "Secret Zone"
AuthBasicProvider    dbd
AuthDBDUserPWQuery    "SELECT upasswd, selinux_type, selinux_range \
                       FROM uaccount WHERE uname = %s"
Require     valid-user
</Directory>

次に、認証DBのセットアップ。uaccountテーブルにBASIC認証の情報をインプットしておく。$PGDATAはPostgreSQLのDBクラスタのトップディレクトリ。まぁ、COPYコマンドで読めればドコでもいいんですが。

$ htpasswd -c $PGDATA/uaccount.master alice
New password:
Re-type new password:
Adding password for user alice
$ htpasswd $PGDATA/uaccount.master bob
New password:
Re-type new password:
Adding password for user bob
$ createdb web

$ pgsql web
web=# CREATE USER apache;
CREATE ROLE
web=# CREATE TABLE uaccount (
     uname   text primary key,
     upasswd text,
     selinux_type text,
     selinux_range text
 );
CREATE TABLE
web=# GRANT SELECT on uaccount TO public;
GRANT
web=# COPY uaccount(uname,upasswd) FROM '/opt/pgsql/uaccount.master';
web=# COPY uaccount(uname,upasswd) FROM '/opt/pgsql/uaccount.master' DELIMITER ':';
COPY 2
web=# UPDATE uaccount SET selinux_type = 'httpd_t';
UPDATE 2
web=# UPDATE uaccount SET selinux_range = 's0:c0' WHERE uname = 'alice';
UPDATE 1
web=# UPDATE uaccount SET selinux_range = 's0:c1' WHERE uname = 'bob';
UPDATE 1
web=# SELECT * FROM uaccount;
 uname |                upasswd                | selinux_type | selinux_range
-------+---------------------------------------+--------------+---------------
 alice | $apr1$HQtZm8Sz$ZwXm9tx6Kz7g2wiE1LBUZ/ | httpd_t      | s0:c0
 bob   | $apr1$YJWn7hx3$iJyazYClFeFF0n8EgIMSi. | httpd_t      | s0:c1
(2 rows)

次に、静的ドキュメントを参照するFactCGI常駐プログラムのfcgi-catをビルドして /usr/local/bin にインストールする。こやつのビルドには fcgi-devel パッケージも必要です。

$ git clone git://github.com/kaigai/toybox.git
$ cd toybox
$ gcc -g fcgi-cat.c -lfcgi -o fcgi-cat
$ sudo install -m 755 fcgi-cat /usr/local/bin

最後に、SELinuxのセキュリティポリシーを追加し、Booleanを調整して設定は終わり。

$ make -f /usr/share/selinux/devel/Makefile webapps.pp
$ sudo semodule -i webapps.pp
$ sudo setsebool httpd_can_network_connect_db on

動かしてみた

お試しとして、以下の内容のPHPスクリプトを実行させてみる。

<?php
echo "<h3>".selinux_getcon()."<h3>\n";
echo "<h3>username = ".$_SERVER["REMOTE_USER"]."</h3>\n";

phpinfo();
?>

ユーザ alice としてアクセスした場合。確かにDBで指定した通り、セキュリティコンテキストの末尾が ":s0:c0" となっている。

一方、ユーザ bob としてアクセスした場合。今度はセキュリティコンテキストの末尾が ":s0:c1" となっている。Server APIの欄が "CGI/FastCGI" となっている点にも注目。

では、静的ドキュメントを参照した場合。２つの画像ファイル test00.jpg と test01.jpg のセキュリティコンテキストはそれぞれ以下のように設定されているため、alice は test00.jpg を参照できるが、test01.jpg は見えないはず。

$ ls -Z /var/www/html
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 mytest.php
-rwxr--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0:c0 test00.jpg
-rwxr--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0:c1 test01.jpg

これが test00.jpg を参照したケース。正しく読み込めている。

今度は test01.jpg を参照した場合。サーバは 403 Forbidden を返している。ヒャッハー！

画像は省略するが、これをユーザbobで試した場合は逆の結果となる。

もちろん、これらはFastCGIで動作しているので、psコマンドを叩くと常駐プロセスの様子が見える。
確かにユーザ alice と bob それぞれのHTTPリクエストを処理するために、別個のプロセスが起動している。

[root@iwashi ~]# ps -AZ | grep php-cgi
system_u:system_r:httpd_t:s0:c0 23960 ?        00:00:00 php-cgi
system_u:system_r:httpd_t:s0:c1 24062 ?        00:00:00 php-cgi
[root@iwashi ~]# ps -AZ | grep fcgi-cat
system_u:system_r:httpd_t:s0:c0 24098 ?        00:00:00 fcgi-cat
system_u:system_r:httpd_t:s0:c1 24107 ?        00:00:00 fcgi-cat

まとめ

今までの mod_selinux と違い、この方法では全てのDSOモジュールに作用させるという事はできない。
PHPならPHP用の、RubyならRuby用の設定がそれぞれ必要となる。これは確かにデメリット。

その一方で、HTTPユーザ毎にアプリを実行するメモリ空間を分けられるという事は、セキュリティの観点からは非常に大きなアドバンテージである。Web管理者がその気になれば、Apache/httpdでは一切Webアプリの実行を行わず、ある種のアプリケーションサーバとして振る舞うFastCGI常駐プログラムが、HTTPユーザ毎に閉じたコンテナ環境を提供するという事も可能だろう。
セキュリティの強化を目的とするモジュールなので、ここのアドバンテージはでかい、と思う。

KaiGai Kohei: mod_selinuxのアーキテクチャを考える(前編)

kaigai — 2012-08-11T06:52:26+00:00

mod_selinuxはapache/httpdのプラグインで、利用者のHTTP要求の認証(BASICとかDIGESTとか)結果に基づいて、PHPスクリプトや静的コンテンツを参照するContents Handlerの実行権限を切り替える。
やっている事は単純で、ap_hook_handlerの先頭で mod_selinux が処理を乗っ取り、一時的にワーカースレッドを作成して権限を縮退させる。で、以降のContents Handlerの実行はワーカースレッドに託されるという形になる。

だが、このデザインだと問題になる事が２点。

ap_invoke_handler()が再入可能ではない
Bounds domainの範囲でしかドメイン遷移ができない

前者の問題について。CGIが自サーバ内のURLを含むLocation: ヘッダを返した場合など、internal redirectionという処理が走り、cgi_handlerのコンテキストでap_invoke_handler()が再び呼ばれる事がある。
この場合、再びHTTP認証が実行され、その結果、cgi_hanclerのコンテキストとは異なるsecurity contextが指定される事があり得る。が、既にsecurity contextを変更する権限を放棄しているハズなので、詰む。この場合はエラーを返してごめんなさいするしかない。
この問題は、SELinuxに限った話ではなく、CAP_SETUIDを放棄するシナリオでも同じ。

後者の問題について。これはSELinux固有の話で、マルチスレッドのアプリがドメイン遷移を行う場合、遷移先のドメインは bounds domain 制約を満足する必要がある。
（いや、これは元々私の提案だが・・・。）
ドメイン httpd_t が user_webapp_t の bounds domain であるという状態は、user_webapp_t の持っている権限は全て httpd_t も持っているという事。つまり、ドメイン遷移元のhttpd_tは、システム管理系のツール等もWeb経由で実行させると考えると、相当に広範な権限を付与する必要がある・・・事になる。
実際にセキュリティポリシーを書くとなると、これが地味に効いてくる。
端的に言って、書きにくい・・・。（´ω｀;;）

まず前者の問題を解決するため、mod_selinuxの構造を上の模式図のように変更してみた。このデザインではsecurity context毎にタスクキューを持ち、ap_handler_hookの先頭でHTTP認証に応じてキューにタスクを振り分けるという形になる。
キューは on demand で生成され、適合する security context が存在しない場合にはTask Launcher Threadにキュー生成要求を行ってこれを作成してもらう。
このデザインだと、ap_invoke_handler()の延長でinternal redirectionが走った場合でも、再帰して呼び出されたap_handler_hookの先頭で行う処理は『適切なキューに処理要求を投げる』だけなので問題は生じない。

・・・と、ここまで実装してハタと気が付いた。

これって本質的には (1)プロトコル処理サーバと (2)アプリケーションサーバの分離と同じことだよねと。
だとすると、上のデザインでは各キューに紐付いていたワーカースレッドをワーカープロセスとして分離すると、最初に挙げた２つの問題のうち後者の Bounds domain の制限を取り払う事ができるようになる。

つまり、利用者のcredentials（uid/gid/security context）毎にワーカープロセスをon demandで起動し、HTTPリクエストの解析はapache/httpd自身で行う一方で、静的コンテンツの参照も含めたHTTPリクエストの処理をワーカープロセスで実行するようにすれば、問題は全て解決するのではなかろうか。

幸いな事に、この手のプロトコルとしてFastCGIが既に定義されており、PHPやRuby、Javaなどメジャーどころの言語はこれに対応している。

．．．とすると、mod_selinuxを拡張するよりも、mod_fcgidに対する追加機能としてSELinux（やその他のセキュリティ機構を包含する）仕組みを提案した方が、メンテナンスが楽になるのかな、と考え中。

Dan Walsh: Article I wrote on Harvard PAAS.

dwalsh@redhat.com — 2012-08-04T11:52:22+00:00

Occasionally I write longer articles that I feel are too long for a blog...

Harvard CS Uses PAAS and Fedora.

Kind of nice to get the message out to other people also. Thanks to OpenSource.com for publishing it.

Dan Walsh: SELinux Apache Security Study

dwalsh@redhat.com — 2012-08-02T20:01:02+00:00

Kirill Ermakov recently posted a study he did of SELinux protections against a vulnerable Apache server.

After reading the study you might come a way with the idea that SELinux did not block anything. After all it allowed the hacked process to read /etc/passwd. SELinux also allowed a hacked Apache to upload a file and execute it.

This points out what most people do not understand about SELinux. SELinux does not necessarily block errors in applications from happening. SELinux will just contain them. If you are able to subvert the Apache application then you can become the Apache application and will have the rights allowed to the apache application. In his examples he was able to take over the Apache server and do what an apache server needs to do, including reading the /etc/passwd file. A better test would be:

Try to connect to a few network ports like the mail port - Out of the box we should not allow Apache to connect to many network ports.
Read /secrets/mysecrets - Random content on the file system should not be readable by Apache
Read /home/dwalsh/creditcard.txt - Random content in a users home dir should not be readable by apace
Read /var/lib/mysql/mysqld.data. - Database data should not be readable by Apache except if allowed through a constricted path like a unix domain socket.
Try to run su or sudo, or strace, or network sniffer.

All things the Apache server should not be allowed to do.

If an Apache server has a bug in its code, then it can be owned whether or not SELinux is in enforcing mode, the goal is to confine the attacker to just the Apache data and not allow him to attack other data or processes on the system.

Apache Booleans

Now lets look further at Apache SELinux policy configuration. A while ago I wrote a blog on "Security vs Usability", in which I explained the continuing conflict between setting up a machine with security as tight as possible, but not so tight as forcing people to turn the security off. When we ship SELinux policy we have to make compromises on security, to avoid the "Just turn it off crowd".
Lets look at some of these compromises, and maybe explain how you could tighten the security in your Apache.

Out of the box SELinux in RHEL6 has the following boolean settings for an Apache server.

On RHEL6 we have

# semanage boolean -l | grep httpd | grep -v off
httpd_enable_cgi               (on   ,   on) Allow httpd cgi support
httpd_dbus_avahi               (on   ,   on) Allow Apache to communicate with avahi service via dbus
httpd_unified                      (on   ,   on) Unify HTTPD handling of all content files.
httpd_builtin_scripting         (on   ,   on) Allow httpd to use built in scripting (usually php)
httpd_tty_comm                  (on   ,   on) Unify HTTPD to communicate with the terminal. Needed for entering the passphrase for certificates at the terminal.

On RHEL7 and Fedora we have

# semanage boolean -l | grep httpd | grep -v off
httpd_enable_cgi               (on   ,   on) Allow httpd cgi support
httpd_graceful_shutdown    (on   ,   on) Allow HTTPD to connect to port 80 for graceful shutdown
httpd_builtin_scripting        (on   ,   on) Allow httpd to use built in scripting (usually php)

I was interested on how he was able to execute tmp_t content.

# sesearch -A -s httpd_t -t httpd_tmp_t -p execute -C
Found 1 semantic av rules:
DT allow httpd_t httpd_tmp_t : file { ioctl read getattr lock execute
execute_no_trans open } ; [ httpd_tmp_exec httpd_builtin_scripting && ]

# sesearch -A -s httpd_sys_script_t -t httpd_tmp_t -p execute -C
Found 1 semantic av rules:
DT allow httpd_sys_script_t httpd_tmp_t : file { ioctl read getattr lock execute execute_no_trans open } ; [ httpd_tmp_exec httpd_enable_cgi && ]

Reading this, it looks like SELinux should have blocked the ability for the Apache process or a cgi script to execute the content by default. IE You would need to turn on the httpd_tmp_exec boolean as well as the httpd_enable_cgi boolean.

But examining further the booleans, I wanted to know what content could httpd_t (Apache) or httpd_sys_script_t (Apache CGI Scripts) could execute and write.

# sesearch -A -s httpd_sys_script_t -t httpd_sys_content_t -p execute -C
Found 3 semantic av rules:
   allow httpd_sys_script_t exec_type : file { ioctl read getattr lock execute execute_no_trans open } ;
   allow httpd_sys_script_t httpd_sys_content_t : file { ioctl read getattr lock execute entrypoint open } ;
ET allow httpd_sys_script_t httpd_sys_content_t : file { ioctl read getattr lock execute execute_no_trans entrypoint open } ; [ httpd_enable_cgi httpd_unified && ]

So the problem here is actually httpd_unified. httpd_unified basically says to SELinux allow Apache processes to treat all Apache content with the same rules. In RHEL7 we feel users are familiar enough with SELinux to disable the httpd_unified boolean by default.   If this boolean is off, then users would have to label files/directories as httpd_sys_content_rw_t if they wanted Apache to be able to write to a directory rather then the read/only label of httpd_sys_content_t. With the boolean on, Apache processes can read/write/execute all httpd_sys_content* labels.

If you are not uploading data to Apache then it is a good idea to turn off this boolean.

# setsebool -P httpd_unified 0

Now lets look at other booleans that are turned on by default in RHEL6. (And RHEL7 for that matter).

httpd_enable_cgi

This boolean enables your Apache server to run cgi scripts. We leave this on by default because out of the box, any person running Apache would blow up with a permission denied when they tried to execute a cgi script. If you were not running cgi scripts, it would be a good idea to turn this off.

# setsebool -P httpd_enable_cgi 0

httpd_builtin_scripting

This boolean your Apache server to run builtin scripting, mod_php, mod_python, mod_perl ...
We leave this on by default because out of the box, any person running Apache would blow up with a permission denied when they tried to execute a php script.

If you are just allowing users to view Apache content, then you really should turn off both of these booleans.

# setsebool -P httpd_builtin_scripting 0

httpd_tty_comm

This boolean allows httpd to talk to the terminal that launches it. The risk here is a hacked apache server could trick an admin into entering his password, by putting a passwd: prompt on the screen and then reading the admins commands. This access is necessary for people who setup apache servers which require a passwd from the admin when they start, it also allow apache to output errors to the screen, like the configuration is screwed up. In Fedora and RHEL7 this output is handled by systemd, so this access is no longer needed, and can be disabled by default. If your apache server does not require a password at start and you know that your config is correct you should turn this boolean off.

# setsebool -P httpd_tty_comm 0

httpd_dbus_avahi

This boolean allows apache to communicate with the avahi daemon over DBUS. This boolean should have been disabled by default, but most likely does not add much risk. It is turned off by default in Fedora and RHEL7.

# setsebool -P httpd_dbus_avahi 0

Bottom line as people grow to peoples understanding of SELinux, we can slowly tighten up the controls...

Paul Moore: New Release for libseccomp

2012-07-31T19:03:59+00:00

Just a few minutes ago we announced the second release of the libseccomp library, version 1.0.0. The libseccomp library is designed to provide an easy to use, platform independent, interface the Linux's syscall filtering mechanism: seccomp.

Significant changes in this release include:

The API is now context-aware; eliminating all internal state but breaking compatibility with the initial 0.1.0 release. The major version number has been bumped with this release to allow both version to coexist on the same system.

Added support for multiple, simultaneous build jobs and verbose build output. This should not affect individual developers, but it should make life easier for packagers.

Once again, thanks to everyone who has submitted suggestions, provided testing
help, and contributed patches to the project.

SourceForge project page: http://sourceforge.net/projects/libseccomp
Direct download: http://sf.net/projects/libseccomp/files/libseccomp-1.0.0.tar.gz/download

Dan Walsh: SELinux with cp/mv

dwalsh@redhat.com — 2012-07-30T18:40:03+00:00

Back in March 22nd, 2006, I wrote a blog on coreutils and SELinux . In that blog I had a couple of paragraphs on cp and the mv command.

mv

The mv command will attempt to maintain the security context of the file when it is moved to a different directory... This causes some
confusion, but this works the same was as with discretionary access. If I create a file owned by dwalsh in /tmp and then copy it to /etc, the ownership of the file will still be dwalsh in /etc. Similarly if the file was created in /tmp, it will have a security context of tmp_t, so when it is moved to /etc. It will continue to have tmp_t as it's security context.

cp

The cp command is a little different. If a file exists at you are copying over, the new file will maintain the file context of the previous file. So if I look at /etc/resolv.conf, I will see that it is labeled net_conf_t. If I copy a file over it say /tmp/resolv.conf, labeled tmp_t, onto /etc/resolv.conf, it will still be labeled net_conf_t. If I moved the file /tmp/resolv.conf onto /etc/resolv.conf, it will end up with tmp_t.

If the file does not exist it follow the rules defined above, IE it will either get the security context of the directory, or if a file_transition rule exists it will transition the context to follow the rule. So if you remove /etc/resolv.conf and cp /tmp/resolv.conf to /etc, you will end up with a security context of etc_t. Similarly if cp /etc/resolv.conf to ~/ it will end up with a security context of user_home_t. cp has an option to preserve the mode, ownership, and timestamps, but this option does not work with the file_context, you need to use -Z.

UPDATE: We now have named file transitions in Fedora which for certain files/directory get labeled correctly on creation, so cp of a file named resolv.conf into a directory labeled etc_t will now get labeled net_conf_t atomically.

One of the problems we see quite often is a user creates an html file in his home dir or in /tmp and then moves it to /var/www/html. Apache then gets an access denied because apache is not allowed to read user_home_t. The quickest way to clean this up is with the restorecon command. The restorecon command reads the default file_contexts for the installed policy and then resets the file_context of all specified files.

restorecon /var/www/html/mypage.html

Sadly people continue to stumble on this. Today I saw email from a user who was setting up a apache server and obviously mv'd content from his home dir to the /var/www/html/updates directory. I know this because the person attached a setroubleshoot message
Which showed the following alert.

Raw Audit Messages
type=AVC msg=audit(1343656110.659:126): avc: denied { open } for pid=13506 comm="httpd" name="updates" dev="dm-1" ino=278541 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir

Notice the open access, from httpd to the updates dir. I figure the admin mv'd it from his home directory since the content is labeled with he user_home_t type. SELinux is complaining because from its point of view, the web server is trying to read content in the users homedir. This users homedir might contain credit card information, tax returns, password etc, stuff we would want to block a hacked web site from accessing. I am pretty sure the user went in an changed the discretionary ownership/permissions, since the apache user would not be allowed to read a directory owned by the user with the default permissions on a directory created in his homedir.
After fixing these permissions he did not think about SELinux and tried to run apache and got permission denied. Luckily the setroubleshoot tool was installed and the user got an alert that said.

SELinux is preventing /usr/sbin/httpd from open access on the directory /var/www/html/updates.

***** Plugin restorecon (99.5 confidence) suggests *************************

If you want to fix the label.
/var/www/html/updates default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/updates

If you create content in your home dir to be used by a service, it is always a good idea to check all the security attributes of the content after you cp/mv it in place. restorecon is often the correct tool to use. And please read the alerts...

For more information on SELinux and apache, you can read the apache_selinux man page.

man apache_selinux

Paul Moore: Configuration Recipe: MLS System with Multiple Single Label Networks

2012-07-06T21:10:10+00:00

One of the most common complaints I hear about the labeled networking access controls in Linux is that users don't know how to configure them for their given scenario. To help solve that problem I'm going to try and document some basic use cases and the associated labeled networking "configuration recipes".

To start off, I'm going to tackle a fairly common use case: a SELinux system with different MLS/MCS labels connected to multiple, single label networks. Imagine a SELinux based system providing services, e.g. a web server, to multiple different networks, each consisting of label un-aware clients, e.g. Windows desktops, operating at different securit labels. For this example, we will assume that the SELinux system is connected to two single label networks, one labeled at s1:c3,c5 (eth0,10.0.0.0/24) and the other labeled at s2:c4,c6 (eth1,10.0.1.0/24). To complete the example, we will also assume that the SELinux system is running at least one application which needs to connect to the local system (localhost) at different levels.

The first step is to configure NetLabel to label incoming traffic on the unlabeled, single label networks.

# netlabelctl unlbl add interface:eth0 address:0.0.0.0/0 \
  label:system_u:object_r:netlabel_peer_t:s1:c3,c5
# netlabelctl unlbl add interface:eth1 address:0.0.0.0/0 \
  label:system_u:object_r:netlabel_peer_t:s2:c4,c6

In general we don't have to worry about the outbound traffic in this case since NetLabel sends all traffic unlabeled by default, but let's go ahead and assume that isn't the case for the sake of demonstration. The commands below remove the default mapping and instruct NetLabel to send unlabeled traffic to both of the single label networks as well as any networks not explicitly specified (both IPv4 and IPv6).

# netlabelctl map del default
# netlabelctl map add default address:10.0.0.0/24 protocol:unlbl
# netlabelctl map add default address:10.0.1.0/24 protocol:unlbl
# netlabelctl map add default address:0.0.0.0/0 protocol:unlbl
# netlabelctl map add default address:::/0 protocol:unlbl

Next we want to configure the system to send labeled traffic to itself, so we need to tell NetLabel to send CIPSO labeled traffic to all of the system's addresses (in this case that would be 10.0.0.2, 10.0.1.2, and 127.0.0.0/8). However, first we need to configure a CIPSO DOI for this local traffic labeling; in this example we will use DOI #32 and the pass through DOI type with the enumerated (tag #2) and restricted bitmaps (tag #1) tags.

# netlabelctl cipsov4 add pass doi:32 tags:2,1
# netlabelctl map add default address:10.0.0.2 protocol:cipsov4,32
# netlabelctl map add default address:10.0.1.2 protocol:cipsov4,32
# netlabelctl map add default address:127.0.0.0/8 protocol:cipsov4,32

Now we should have all of the labeling configuration in place and it is just a matter of making sure your SELinux configuration/policy is correct for the accesses you want to allow. One important thing to remember is that you likely will want to use the semanage tool to set the SELinux label for the single label interfaces; this will ensure that only traffic labeled as s1:c3,c5 can traverse the eth0 interface and only traffic labeled as s2:c4,c6 can traverse the eth1 interface.

# semanage interface -a -t netif_t -r s1:c3,c5 eth0
# semanage interface -a -t netif_t -r s2:c4,c6 eth1

At this point, if you haven't already, you should double check your SELinux policy as you will most likely need to add some custom policy modules to match your new labeled networking configuration, but thankfully that is something which has gotten much easier the past few years and already has plenty of good documentation available. You may also want to start investigating the xinetd LABELED configuration option as a way of starting server applications at the label of the incoming connection request; it can be a very useful option for systems like this where you have client requests coming in at different levels.

Good luck, and don't hesitate to add any problems or questions you may have in the comments.

KaiGai Kohei: 人生に影響を与えたプレゼンテーション

kaigai — 2012-06-30T05:08:28+00:00

10年近くも技術者をやっていると、他の人のプレゼンテーションを見る機会はちょくちょくある。（別にOSS/Linuxに限った話じゃなくて）
全く印象に残らないものから、発表後にプレゼンターを捕まえて議論が始まるもの、中には自分の考え方や活動に影響を与えたプレゼンテーションというのもあるハズ。

パッと二つ思い浮かんだのでご紹介。
・・・まぁ、他の人はどんなプレゼンテーションを見て心動かされたのか知りたい、という下心もあるんですが。

How to Contribute to the Linux Kernel, and Why it Makes Economic Sense (James Bottomley, Novell; LinuxCon/Japan 2009)

なぜオープンソースへの貢献が重要で、ビジネス上も意義のある事である事なのかを説いたLinuxCon/Japan 2009でのキーノートの一節。
本来、企業が何か"価値"を顧客に届けるには、その価値の源泉であるUnique Innovationの部分と、その前提であるDelivery Support for the innovationの部分に投資をしなければならないが、オープンソースを活用する事で企業はUnique Innovationの部分に注力でき、コミュニティと歩調を合わせて進む（勝手forkをしない）事でDelivery Support for the innovationの部分をShared Cost（そう、freeではなくshared costなのです）に保つ事ができるという趣旨の発表。

確かに自分のケースを振り返ってみても、SE-PostgreSQLを開発するために、その価値の源泉であるSELinuxとの連携モジュールはともかくとして、SQL 構文解析やクエリ最適化、クエリ実行といったRDBMSそれ自身を作るなんてのはあり得ない話。確かに自分も"巨人の肩に乗って"開発しているんだと納得したものだ。

企業がオープンソースの開発に貢献した方が、より低いコストでイノベーションを達成できる事、そして"Free"でなく"Shared cost"である事。この考え方は正に自分の人生に影響を与えたと思う。

Parallel Image Searching Using PostgreSQL and PgOpenCL (Tim Child, 3DMashUp; PGcon2011)

もう一つは、昨年のPGconで聴講したTim ChildのPG/OpenCLの発表。
内容はRDBMSに格納した画像データ（レコード長がかなり大きい）をGPUで高速に処理するというもの。
何が心に刺さったかというと、（一字一句正確ではないかもしれないが）最後のまとめで彼が語った『Database records are ideal data structure for parallel processing（データベースのレコードは理想的な並列処理のデータ構造だ）』という一言。

これを聞いて、なるほどGPUを使ってCPUをオフロードすれば、検索処理を高速に処理できるではないか・・・？という発想でCUDAやOpenCLを調査し、その半年後にできたのがPG-Stromというモジュールだったりする。

さて、他の人に聞いてみたら、どんな『自分の人生に影響を与えたプレゼンテーション』が出てくるのだろう？

Paul Moore: Full SELinux Labels Over Loopback with NetLabel and CIPSO

2012-06-29T22:12:09+00:00

Perhaps one of the largest shortcomings of the CIPSO network labeling protocol when used with SELinux is the fact that it can only convey the SELinux MLS attributes across the network. There are plenty of good reasons for this: strict conformance with protocol specification, limited space in the IPv4 header, interoperability with non-SELinux systems, etc. However, regardless of the reasons why, there will always be use cases where it would be very nice to have the full SELinux label without the performance, scalability and management overhead of labeled IPsec. While I can't say I have solution for all of those use cases, today I am going to let you in on one of NetLabel's best kept secrets: NetLabel and CIPSO can convey the full SELinux label over local connections, and it has been able to do so for years.

Now, before I got into the details of "how", I just want to be clear that what I'm about to tell you isn't really a secret, it just hasn't been very well publicized. After all, I'm not sure how it could be a secret when the code is available for anyone and everyone to review and inspect. Further, the "how" is even documented in the netlabelctl manpage, so if this capability is NetLabel's best kept secret it has clearly been hiding in plain sight.

Enough of the "secret", let's explain how to get this working. First off, if you're going to try this on your own system (any modern Linux distribution that supports SELinux and NetLabel should work), you might want to grab a copy of the getpeercon_server test tool that I've used in the example below; instructions for building the test tool are at the top of the file. Once you've got everything built and you've verified that your SELinux and NetLabel installation is working as you would expect, you need to start off by configuring the CIPSO Domains Of Interpretation (DOI). For this example we are going to create two DOIs, one using the standard, MLS-only passthrough type and the other using the local-connection-only full SELinux type. Don't forget that you can always check the netlabelctl manpage for more information on the commands below.

# netlabelctl cipsov4 add pass doi:1 tags:1
# netlabelctl cipsov4 add local doi:2
# netlabelctl -p cipsov4 list
Configured CIPSOv4 mappings (2)
 DOI value : 1                                                                  
   mapping type : PASS_THROUGH                                                  
 DOI value : 2                                                                  
   mapping type : LOCAL

After you've setup the CIPSO DOI's you need to configure NetLabel to send traffic using these new DOIs. In our example we are going to configure the system such that traffic sent to 127.0.0.1 (localhost) will use DOI #2, the local-only full SELinux label DOI, and traffic sent to 10.250.2.92 (the system's eth0 address) will use DOI #1, the normal MLS-only DOI. Don't forget that we first need to remove the default unlabeled mapping so we can use the address selectors.

# netlabelctl map del default
# netlabelctl map add default address:0.0.0.0/0 protocol:unlbl                                                                          
# netlabelctl map add default address:::/0 protocol:unlbl
# netlabelctl map add default address:127.0.0.1 protocol:cipsov4,2
# netlabelctl map add default address:10.250.2.92 protocol:cipsov4,1
# netlabelctl -p map list
Configured NetLabel domain mappings (1)                                         
 domain: DEFAULT                                                                
   address: 127.0.0.1/32                                                        
    protocol: CIPSOv4, DOI = 2
   address: 10.250.2.92/32
    protocol: CIPSOv4, DOI = 1
   address: 0.0.0.0/0
    protocol: UNLABELED
   address: ::/0
    protocol: UNLABELED

With that we're finished, now it's time to test it out. Testing is quite simple, make sure you have a TCP client like telnet or netcat installed and then start the getpeercon_server test tool you built earlier; in this example getpeercon_server is listening on TCP port 5000.

# ./getpeercon_server 5000
-> running as unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-> creating socket ... ok
-> listening on TCP port 5000 ... ok
-> waiting ... connect(10.250.2.92,system_u:object_r:netlabel_peer_t:s0)
Connected to 10.250.2.92:5000
-> connection closed
-> waiting ... connect(127.0.0.1,unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023)
Connected to 127.0.0.1 5000
-> connection closed
-> waiting ...

It works! When we connected to 10.250.2.92 we saw the familiar "netlabel_peer_t" type, but when we connected to 127.0.0.1 we saw the full SELinux label of our telnet client process, "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023". Go ahead and try it out for yourself, just remember that you can only use the "local" DOI type on network connections that run over the loopback network interface.

Dominick Grift: Hard coded types create hard dependencies on selinux policy

Dominick "domg472" Grift (noreply@blogger.com) — 2012-06-27T09:15:16+00:00

Long time no see. I believe that applications like sandbox (sandbox_web_t) and sshd (chroot_user_t) hard code types. I do not like that but my personal opinion aside; This creates hard dependencies on SELinux policy. If you do not have a policy that provides these types then you will end up with broken functionality. I believe one example is that sandbox does not work in Debian because Debian selinux-policy does not provide the types that sandbox requires. That is all folks.

James Morris: Linux Security Summit 2012 – Schedule Published

jamesm — 2012-06-27T06:22:01+00:00

The schedule for LSS 2012 is now published. See also the email announcement.

As previously mentioned, LSS this year will be a two-day event, co-located with LinuxCon.

On Day 1, we’re privileged to have a keynote by Matthew Garrett. He’s one of the best speakers in the community, and I believe he’ll be discussing secure boot.

Following the keynote, we have eight refereed presentations on new and interesting Linux security development topics.

On Day 2, we’ll have kernel security subsystem updates from maintainers, followed by an afternoon of breakout sessions. The breakout sessions are for deeper dives into specific areas, and may include development discussions and hack sessions. An BoF is planned to discuss an LF Security Workgroup, and attendees may propose more sessions in the leadup to the conference by emailing the program committee.

Thanks to all of the committee members for reviewing the proposals and helping to organize the summit — it’s shaping up as an interesting and productive event!

Russell Coker (security): New SE Linux Policy for Wheezy

etbe — 2012-06-21T14:12:14+00:00

I’ve just uploaded a new SE Linux policy for Debian/Wheezy. It now works correctly with systemd and Chromium, two significant features that I wanted for Wheezy. Now it turns out that we have until the end of the month for Wheezy updates, so I may get another version of the policy uploaded before then. If so it will only be for relatively minor changes, I think that most SE Linux users would be reasonably happy with policy the way it is. Anything that doesn’t work now can probably be solved by local configuration changes.

execmem

The current version of KDE in Debian is 4.8.4, it seems that large parts of the KDE environment depend on execmem access, this includes kwin and plasma-desktop. Basically there is no possibility of having a KDE desktop environment without those programs and therefore KDE depends on execmem access.

Debugging this is difficult as the important programs SEGV when denied execmem access and the KDE crash handler really gets in the way of debugging it – running /usr/bin/plasma-desktop results in the process forking a child and detaching from the gdb session.

The most clear example of an execmem issue in KDE is from the program /usr/lib/kde4/libexec/kwin_opengl_test which gives the following error:
LLVM ERROR: Allocation failed when allocating new memory in the JIT
Can’t allocate RWX Memory: Permission denied

To make this work you run the command “setsebool -P allow_execmem 1” which gives many domains the ability to create writable-executable memory regions.

I raised this issue for discussion on the SE Linux mailing list and Hinnerk van Bruinehsen wrote an informative message in response summarising the situation [1]. It seems that it’s possible to compile some of the programs in question to not use the JIT and therefore not require such access and there is a build option in Gentoo to allow it. But it’s impractically difficult for me to fork KDE in Debian so the only option is to recommend that people enable the allow_execmem boolean for Debian desktop systems running SE Linux.

[1] http://marc.info/?l=selinux&m=134011618909818&w=2

Russell Coker (security): Debian SE Linux Status June 2012

etbe — 2012-06-17T06:48:39+00:00

It’s almost the Wheezy freeze time and I’ve been working frantically to get things working properly.

Policy Status

At the moment I’m preparing an upload of the policy which will support KDE (and probably most desktop environment) logins and many little fixes related to server operations (particularly MTAs). I would like to get another version done before Wheezy is released, but if Wheezy releases with version 2.20110726-6 of the policy that will be OK. It will work well enough for most things that users will be able to use local changes for the things that don’t work.

One significant lack with the current policy is that systemd won’t work. I’ve included most of the policy changes needed, but haven’t done any of the testing and tweaking that is necessary to make it work properly.

I would like to see policy support for systemd in a Wheezy update if I don’t get it done in time for the first release. If I don’t get it done in time for the release and if the release team don’t accept it for an update then I’ll put it in my own repository so anyone who needs it can get it.

/run Labelling

One significant change for Wheezy is to use a tmpfs mounted on /run instead of /var/run. This means that lots of daemon start scripts create subdirectories of /run at boot time which need to have SE Linux labels applied for correct operation. The way things work is that usually the daemon will write to the directory immediately after the init script has created it, so I can’t just have my own script recursively relabel all of /run.

Some packages that need to be patched are x11-common #677831, clamav-daemon #677686, sasl2-bin #677685, dkim-filter #677684, and cups #677580. I am sure that there are others.

[ -x /sbin/restorecon ] && /sbin/restorecon -R $DIR

Generally if you are writing an init script and creating a directory under /run then you need to have some shell code like the above immediately after it’s created. Also the same applies for directories under /tmp and any other significant directories that are created at boot time.

Upgrading

Currently there are some potential problems with the upgrade process, I’m working on them at the moment. Ideally an “apt-get dist-upgrade” would cleanly upgrade everything. But at the moment it seems likely that the upgrade might initially go wrong and then work on the second try. There are some complications such as the selinux-policy-default package owning a config file which is used by mcstransd (which is part of the policycoreutils package), when the config file format changes you get order dependencies for the upgrade.

Kernel Support

My aim when developing a new SE Linux release for Debian is that the policy should work as much as possible with the user-space from the previous release. So if you upgrade from Squeeze to Wheezy you should be able to start the process by upgrading the SE Linux policy (which drags in the utilities and lots of libraries). This means that if you have a server running you don’t have to put it out of action for the entire upgrade, you can get the policy going and then get other things going. I haven’t tested this yet but I don’t expect any problems (apart from all the dependencies).

Also the policy should work with the kernel from the previous release. So if you have a virtual server where it’s not convenient to upgrade the kernel then that shouldn’t stop you from upgrading the user-space and the SE Linux policy. I’ve tested this and found one bug, the sepolgen-ifgen utility that you need to run before audit2allow -R won’t work if the kernel is older than the utilities #677730. I don’t know if it will be possible to get this fixed. Anyway it’s not that important, you can always copy the audit log to another system running the same policy to run audit2allow, it’s not convenient but not THAT difficult either.

The End Result

I think that the result of using SE Linux in Wheezy will be quite good for the people who get the upgrade done and who modify a few init scripts that don’t get the necessary changes in time. I anticipate that someone who doesn’t know much about SE Linux will be able to get a basic workstation or small server installation done in considerably less than an hour if they read the documentation and someone who knows what they are doing will get it done in a matter of minutes (plus download and install time which can be significant on old hardware).

At the moment I’m in the process of upgrading all of my systems to Unstable (currently Testing has versions of some SE Linux packages that are too broken). While doing this I will keep discovering bugs and fix as many of them as possible. But it seems that I’ve already fixed most things that affect common users.

Also BTRFS works well. Not that supporting a new filesystem is a big deal (all that’s needed is XATTR support), but having all the nice new features on one system is a good thing. Now I just need to get systemd working.

Paul Moore: Announcing the libseccomp Project

2012-06-08T15:08:19+00:00

This morning we announced the first release of the libseccomp library, version 0.1.0. The libseccomp library is designed to provide an easy to use, platform independent, interface the Linux's syscall filtering mechanism: seccomp. Linux Weekly News wrote up a nice summary of the project that I would encourage you to read as it provides a basic introduction to seccomp and the libseccomp API. For those of you interested in playing with seccomp/libseccomp, you will need Linux 3.5-rc1 or later, and the libseccomp library which you can download from the links below.

I want to say a special thanks to everyone who has submitted suggestions, provided testing help, and contributed code to the project; your help made it much easier to get to this point.

SourceForge project page: http://sourceforge.net/projects/libseccomp

Direct download: http://downloads.sf.net/project/libseccomp/libseccomp-0.1.0.tar.gz

James Morris: Congratulations to Chris Mason

jamesm — 2012-06-08T04:04:25+00:00

As many of you will know, I started a new role at Oracle earlier in the year, going to work on Chris Mason’s team. He announced this week that he’s moving onto a new position at Fusion-io. His leadership at Oracle will be missed, and I would like to congratulate him on his new role.

Also, just to head off the inevitable internet rumours, I thought I’d post here that I will be taking on many of Chris’s previous responsibilities at Oracle, including leading the mainline kernel development team. We’re actively hiring, by the way, so if you want to hack on the Linux kernel for a great company—remotely, from almost anywhere on the planet—email me :-)

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

jamesm — 2012-05-16T21:45:17+00:00

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 — 2012-05-02T01:57:49+00:00

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 — 2012-04-25T12:37:48+00:00

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 — 2012-04-24T14:12:18+00:00

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 — 2012-04-22T16:00:28+00:00

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!

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

jamesm — 2012-04-12T14:00:09+00:00

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 — 2012-03-30T12:42:29+00:00

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

Dan Walsh: runuser versus su

dwalsh@redhat.com — 2012-03-28T12:40:09+00:00

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 — 2012-03-22T14:19:45+00:00

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 — 2012-03-20T13:30:25+00:00

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 — 2012-03-19T16:06:00+00:00

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 — 2012-03-15T12:50:56+00:00

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 — 2012-03-13T14:47:35+00:00

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

dwalsh@redhat.com — 2012-03-12T15:55:56+00:00

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 — 2012-03-08T16:46:18+00:00

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 — 2012-03-08T04:34:27+00:00

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 — 2012-03-06T16:43:32+00:00

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 — 2012-03-06T06:44:33+00:00

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.

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

dwalsh@redhat.com — 2012-03-02T21:35:09+00:00

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 — 2012-03-01T13:50:07+00:00

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 — 2012-02-29T14:53:13+00:00

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 — 2012-02-28T17:03:55+00:00

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 — 2012-02-27T16:11:34+00:00

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 — 2012-02-24T17:02:20+00:00

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 — 2012-02-23T14:34:28+00:00

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 — 2012-02-20T16:45:00+00:00

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 — 2012-02-13T20:35:38+00:00

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 — 2012-02-10T08:31:45+00:00

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 — 2012-02-07T16:50:33+00:00

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 — 2012-02-06T22:03:25+00:00

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 — 2012-02-06T15:24:04+00:00

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 — 2012-02-03T17:23:11+00:00

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 — 2012-02-02T15:14:21+00:00

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 — 2012-02-01T15:03:43+00:00

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 — 2012-01-31T18:43:57+00:00

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 — 2012-01-25T11:36:31+00:00

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/