Planet SELinux

Dan Walsh: A follow up to the Bash Exploit and SELinux.

dwalsh@redhat.com — Fri, 26 Sep 2014 12:58:19 +0000

One of the advantages of a remote exploit is to be able to setup and launch attacks on other machines.

I wondered if it would be possible to setup a bot net attack using the remote attach on an apache server with the bash exploit.

Looking at my rawhide machine's policy

sesearch -A -s httpd_sys_script_t -p name_connect -C | grep -v ^D
Found 24 semantic av rules:
allow nsswitch_domain dns_port_t : tcp_socket { recv_msg send_msg name_connect } ;
allow nsswitch_domain dnssec_port_t : tcp_socket name_connect ;
ET allow nsswitch_domain ldap_port_t : tcp_socket { recv_msg send_msg name_connect } ; [ authlogin_nsswitch_use_ldap ]

The apache script would only be allowed to connect/attack a dns server and an LDAP server. It would not be allowed to become a spam bot (No connection to mail ports) or even attack other web service.

Could an attacker leave a back door to be later connected to even after the bash exploit is fixed?

# sesearch -A -s httpd_sys_script_t -p name_bind -C | grep -v ^D
#

Nope! On my box the httpd_sys_script_t process is not allowed to listen on any network ports.

I guess the crackers will just have to find a machine with SELinux disabled.

Dan Walsh: What does SELinux do to contain the the bash exploit?

dwalsh@redhat.com — Thu, 25 Sep 2014 21:37:39 +0000

Do you have SELinux enabled on your Web Server?

Lots of people are asking me about SELinux and the Bash Exploit.

I did a quick analysis on one reported remote Apache exploit:

http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_remote_code_execution_through_bash/

Shows an example of the bash exploit on an apache server.  It even shows that SELinux was enforcing when the exploit happened.

SELinux does not block the exploit but it would prevent escallation of confined domains.

Why didn't SELinux block it?

SELinux controls processes based on their types, if the process is doing what it was designed to do then SELinux will not block it.

In the defined exploit the apache server is running as httpd_t and it is executing a cgi script which would be labeled httpd_sys_script_exec_t.  

When httpd_t executes a script labeled httpd_sys_script_exec_t SELinux will transition the new process to httpd_sys_script_t.

SELinux policy allowd processes running as httpd_sys_script_t is to write to /tmp, so it was successfull in creating /tmp/aa.

If you did this and looked at the content in /tmp it would be labeled httpd_tmp_t

httpd_tmp_t.

Lets look at which files httpd_sys_script_t is allowed to write to on my Rawhide box.

# sesearch -A -s httpd_sys_script_t -c file -p write -C | grep open | grep -v ^D
   allow httpd_sys_script_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow httpd_sys_script_t anon_inodefs_t : file { ioctl read write getattr lock append open } ; 
   allow httpd_sys_script_t httpd_sys_script_t : file { ioctl read write getattr lock append open } ; 
   allow httpd_sys_script_t httpd_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 

httpd_sys_script_t is a process label which only applies to content in /proc.  This means processes running as httpd_sys_script_t can write to there process data.

anon_inodefs_t is an in memory label, most likely not on your disk.

The only on disk places it can write files labeled httpd_sys_rw_content_t and /tmp.

grep httpd_sys_rw_content_t /etc/selinux/targeted/contexts/files/file_contexts

or on my box

# find /etc -context "*:httpd_sys_rw_content_t:*"
/etc/BackupPC
/etc/BackupPC/config.pl
/etc/BackupPC/hosts
/etc/glpi

With SELinux disabled, this hacked process would be allowed to write any content that is world writable on your system as well as any content owned by the apache user or group.

Lets look at what it can read.

sesearch -A -s httpd_sys_script_t -c file -p read -C | grep open | grep -v ^D | grep -v exec_t
   allow domain locale_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t iso9660_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t httpd_sys_ra_content_t : file { ioctl read create getattr lock append open } ; 
   allow httpd_sys_script_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow httpd_sys_script_t squirrelmail_spool_t : file { ioctl read getattr lock open } ; 
   allow domain ld_so_t : file { ioctl read getattr execute open } ; 
   allow httpd_sys_script_t anon_inodefs_t : file { ioctl read write getattr lock append open } ; 
   allow httpd_sys_script_t sysctl_kernel_t : file { ioctl read getattr lock open } ; 
   allow domain base_ro_file_type : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t httpd_sys_script_t : file { ioctl read write getattr lock append open } ; 
   allow nsswitch_domain cert_t : file { ioctl read getattr lock open } ; 
   allow httpd_script_type etc_runtime_t : file { ioctl read getattr lock open } ; 
   allow httpd_script_type fonts_cache_t : file { ioctl read getattr lock open } ; 
   allow domain mandb_cache_t : file { ioctl read getattr lock open } ; 
   allow domain abrt_t : file { ioctl read getattr lock open } ; 
   allow domain lib_t : file { ioctl read getattr lock execute open } ; 
   allow domain man_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t cifs_t : file { ioctl read getattr lock execute execute_no_trans entrypoint open } ; 
   allow domain sysctl_vm_overcommit_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t nfs_t : file { ioctl read getattr lock execute execute_no_trans entrypoint open } ; 
   allow kernel_system_state_reader proc_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain passwd_file_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain sssd_public_t : file { ioctl read getattr lock open } ; 
   allow domain cpu_online_t : file { ioctl read getattr lock open } ; 
   allow httpd_script_type public_content_rw_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain etc_runtime_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain hostname_etc_t : file { ioctl read getattr lock open } ; 
   allow domain ld_so_cache_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain sssd_var_lib_t : file { ioctl read getattr lock open } ; 
   allow httpd_script_type public_content_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain krb5_conf_t : file { ioctl read getattr lock open } ; 
   allow domain abrt_var_run_t : file { ioctl read getattr lock open } ; 
   allow domain textrel_shlib_t : file { ioctl read getattr execute execmod open } ; 
   allow httpd_sys_script_t httpd_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow domain machineid_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t mysqld_etc_t : file { ioctl read getattr lock open } ; 
   allow domain rpm_script_tmp_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain samba_var_t : file { ioctl read getattr lock open } ; 
   allow domain sysctl_crypto_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain net_conf_t : file { ioctl read getattr lock open } ; 
   allow httpd_script_type etc_t : file { ioctl read getattr execute execute_no_trans open } ; 
   allow httpd_script_type fonts_t : file { ioctl read getattr lock open } ; 
   allow httpd_script_type ld_so_t : file { ioctl read getattr execute execute_no_trans open } ; 
   allow nsswitch_domain file_context_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t httpd_squirrelmail_t : file { ioctl read getattr lock append open } ; 
   allow httpd_script_type base_ro_file_type : file { ioctl read getattr lock execute execute_no_trans open } ; 
   allow httpd_sys_script_t snmpd_var_lib_t : file { ioctl read getattr lock open } ; 
   allow nsswitch_domain samba_etc_t : file { ioctl read getattr lock open } ; 
   allow domain man_cache_t : file { ioctl read getattr lock open } ; 
   allow httpd_script_type bin_t : file { ioctl read getattr lock execute execute_no_trans open } ; 
   allow httpd_script_type lib_t : 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 execute_no_trans entrypoint open } ; 
   allow nsswitch_domain etc_t : file { ioctl read getattr lock open } ; 
ET allow nsswitch_domain cert_t : file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ]
ET allow nsswitch_domain slapd_cert_t : file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ]
ET allow nsswitch_domain net_conf_t : file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ]
ET allow domain sysctl_kernel_t : file { ioctl read getattr lock open } ; [ fips_mode ]

Looks like a lot of types, but most of these are System Types bin_t, lib_t ld_so_t, man_t fonts_t,  most stuff under /usr etc.

It would be allowed to read /etc/passwd (passwd_t) and most content in /etc.  

It can read apache static content, like web page data.

Well what can't it read?

user_home_t - This is where I keep my credit card data
usr_tmp_t where an admin might have left something
Other content in /var
*db_t - No database data.
It can not read most of apache runtime data like apache content in /var/lib or /var/log or /etc/httpd

With SELinux disabled, this process would be allowed to read any content that is world readable on your system as well as any content owned by the apache user our group.

We also need to look at what domains httpd_sys_script_t can transition to?

# sesearch -T -s httpd_sys_script_t -c process -C | grep -v ^D
Found 9 semantic te rules:
   type_transition httpd_sys_script_t httpd_rotatelogs_exec_t : process httpd_rotatelogs_t; 
   type_transition httpd_sys_script_t abrt_helper_exec_t : process abrt_helper_t; 
   type_transition httpd_sys_script_t antivirus_exec_t : process antivirus_t; 
   type_transition httpd_sys_script_t sepgsql_ranged_proc_exec_t : process sepgsql_ranged_proc_t; 
   type_transition httpd_sys_script_t sepgsql_trusted_proc_exec_t : process sepgsql_trusted_proc_t; 

SELinux would also block the process executing a setuid process to raise its capabilities.

Now this is a horrible exploit but as you can see SELinux would probably have protected a lot/most of your valuable data on your machine.  It would buy you time for you to patch your system.

Did you setenforce 1?

Dan Walsh: Confusion with sesearch.

dwalsh@redhat.com — Mon, 15 Sep 2014 11:07:47 +0000

I just saw an email where a user was asking why sesearch is showing access but the access is still getting denied.

I'm running CentOS 6. I've httpd running which accesses a file but it results in access denied with the following --

type=AVC msg=audit(1410680693.979:40): avc: denied { read } for pid=987 comm="httpd" name="README.txt" dev=dm-0 ino=12573 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

However,

sesearch -A | grep 'allow httpd_t' | grep ': file' | grep user_home_t
   allow httpd_t user_home_t : file { ioctl read getattr lock open } ;
   allow httpd_t user_home_t : file { ioctl read getattr lock open } ;

sesearch

sesearch is a great tool that we use all the time. It allows you to analyze and look the the SELInux policy. It is part of the setools-console package. It uses the "Apol" libraries to examine policy, the same libraries we have used to build the new tool set sepolicy.

The problem was that he was using sesearch incorrectly. sesearch -A shows you all possible, allow rules not just the allow rules that are currently in effect.

The user needs to add a -C option to the sesearch. The -C options shows you the booleans required for that access. It also shows a capital E or D indicating whether or not the boolean is enabled or disabled in policy at the beginning of the line.

On my machine, I will use a more complicated command, this command says show the allow rules for a source type of httpd_t, and a target type of user_home_t, permission=read on a class=file.

sesearch -A -C -s httpd_t -t user_home_t -p read -c file
Found 1 semantic av rules:
DT allow httpd_t user_home_type : file { ioctl read getattr lock open } ; [ httpd_read_user_content ]

As you can see on my machine the boolean is disabled, so Apache is not allowed to read general content in my homedir, which I assume was true for the user.   If the user wants to allow httpd_t to read all general content in the users homedir you can turn on the httpd_read_user_content boolean.

If you want to allow it to read just a certain directories/files, recommended, you should change the label on the directory. BTW ~/public_html and ~/www already have the correct labeling.

matchpathcon ~/public_html ~/www
/home/dwalsh/public_html    staff_u:object_r:httpd_user_content_t:s0
/home/dwalsh/www    staff_u:object_r:httpd_user_content_t:s0

I would not want to let the apache process read general content in my homedir, since I might be storing critical stuff like credit card data, passwords, and unflattering pictures of me in there. :^)

Dan Walsh: What is this new unconfined_service_t type I see on Fedora 21 and RHEL7?

dwalsh@redhat.com — Wed, 10 Sep 2014 20:18:36 +0000

Everyone that has ever used SELinux knows that the unconfined_t domain is a process label that is not confined. But this is not the only unconfined domain on a SELinux system. It is actually the default domain of a user that logs onto a system. In a lot of ways we should have used the type unconfined_user_t rather then unconfined_t.

By default in an SELinux Targeted system there are lots of other unconfined domains. We have these so that users can run programs/services without SELinux interfering if SELinux does not know about them. You can list the unconfined domains on your system using the following command.

seinfo -aunconfined_domain_type -x

In RHEL6 and older versions of Fedora, we used to run system services as initrc_t by default. Unless someone has written a policy for them. initrc_t is an unconfined domain by default, unless you disabled the unconfined.pp module. Running unknown serivices as initrc_t allows administrators to run an application service, even if no policy has never been written for it.

In RHEL6 we have these rules:

init_t @initrc_exec_t -> initrc_t

init_t @bin_t -> initrc_t

If an administrator added an executable service to /usr/sbin or /usr/bin, the init system would run the service as initrc_t.

We found this to be problematic, though.

The problem was that we have lots of transition rules out of initrc_t. If a program we did not know about was running as initrc_t and executed a program like rsync to copy data between servers, SELinux would transition the program to rsync_t and it would blow up. SELinux mistakenly would think that rsync was set up in server mode, not client mode. Other transition rules could also cause breakage.

We decided we needed a new unconfined domain to run services with, that would have no transition rules. We introduced the unconfined_service_t domain. Now we have:

init_t @bin_t -> unconfined_service_t

A process running as unconfined_service_t is allowed to execute any confined program, but stays in the unconfined_service_t domain. SELinux will not block any access. This means by default, if you install a service that does not have policy written for it, it should work without SELinux getting in the way.

Sometimes applications are installed in fairly random directories under /usr or /opt (Or in oracle's case /u01), which end up with the label of usr_t, therefore we added these transition rules to policy.

# sesearch -T -s init_t | grep unconfined_service_t

type_transition init_t bin_t : process unconfined_service_t;

type_transition init_t usr_t : process unconfined_service_t;

You can see it in Fedora21.

Bottom Line

Hopefully unconfined_service_t will make leaving SELinux enabled easier on systems that have to run third party services, and protect the other services that run on your system.

Note:
Thanks to Simon Sekidde and Miroslav Grepl for helping to write this blog.

Dan Walsh: Interview on Docker Security on SDTimes.com

dwalsh@redhat.com — Mon, 08 Sep 2014 18:44:54 +0000

http://sdtimes.com/red-hat-open-source-community-fortifying-docker

Dan Walsh: Think before you just blindly audit2allow -M mydomain

dwalsh@redhat.com — Fri, 05 Sep 2014 12:35:01 +0000

Don't Allow Domains to write Base SELinux Types

A few years ago I wrote a blog and paper on the four causes of SELinux errors.

The first two most common causes were labeling issues and SELinux needs to know.

Easiest way to explain this is a daemon wants to write to a certain file and SELinux blocks
the application from writing. In SELinux terms the Process DOMAIN (httpd_t) wants to write to the file type (var_lib_t)
and it is blocked. Users have potentially three ways of fixing this.

Change the type of the file being written.
- The object might be mislabeled and restorecon of the object fixes the issue
- Change the label to httpd_var_lib_t using semanage and restorecon

There might be a boolean available to allow the Process Domain to write to the file type

Modify policy using audit2allow

Sadly the third option is the least recommended and the most often used.

The problem is it requires no thought and gets SELinux to just shut up.

In RHEL7 and latest Fedoras, the audit2allow tools will suggest a boolean when you run the AVC's through it. And setroubleshoot has been doing this for years. setroubleshoot even will suggest potential types that you could change the destination object to use.

The thing we really want to stop is domains writing to BASE types. If I allow a confined domain to write to a BASE type like etc_t or usr_t, then a hacked system can attack other domains, since almost all other domains need to read some etc_t or usr_t content.

BASE TYPES

One other feature we have added in RHEL7 and Fedora is a list of base types. SELinux has a mechanism for grouping types based on an attribute.
We have to new attributes base_ro_file_type and base_file_type. You can see the objects associated with these attributes using the seinfo command.

seinfo -abase_ro_file_type -x
   base_ro_file_type
      etc_runtime_t
      etc_t
      src_t
      shell_exec_t
      system_db_t
      bin_t
      boot_t
      lib_t
      usr_t
      system_conf_t
      textrel_shlib_t

$ seinfo -abase_file_type -x
   base_file_type
      etc_runtime_t
      unlabeled_t
      device_t
      etc_t
      src_t
      shell_exec_t
      home_root_t
      system_db_t
      var_lock_t
      bin_t
      boot_t
      lib_t
      mnt_t
      root_t
      tmp_t
      usr_t
      var_t
      system_conf_t
      textrel_shlib_t
      lost_found_t
      var_spool_t
      default_t
      var_lib_t
      var_run_t

If you use audit2allow to add a rule to allow a domain to write to one of the base types:

Most likely you are WRONG

If you have a domain that is attempting to write to one of these base types, then you most likely need to change the type of the destination object using the semanage/restorecon commands mentioned above.
The difficult thing for the users to figure out; "What type should I change the object to?"

We have added new man pages that show you the types that you program is allowed to write

man httpd_selinux

Look for writable types?

If your domain httpd_t is attempting to write to var_lib_t then look for httpd_var_lib_t. "sepolicy gui" is a new gui tool to help you understand the types also.

Call to arms:
If an enterprising hacker wanted to write some code, it would be nice to build this knowledge into audit2allow. Masters Thesis anyone???

James Morris: New GPG Key

jamesm — Thu, 04 Sep 2014 21:38:18 +0000

Just an FYI, I lost my GPG key a few months back during an upgrade, and have created a new one. This was signed by folk at LinuxCon/KS last month.

The new key ID / fingerprint is: D950053C / 8327 23D0 EF9D D46D 9AC9 C03C AD98 4BBF D950 053C

Please use this key and not the old one!

James Morris: Linux Security Summit 2014 Schedule Published

jamesm — Tue, 15 Jul 2014 23:00:31 +0000

The schedule for the 2014 Linux Security Summit (LSS2014) is now published.

The event will be held over two days (18th & 19th August), starting with James Bottomley as the keynote speaker. The keynote will be followed by referred talks, group discussions, kernel security subsystem updates, and break-out sessions.

The refereed talks are:

Verified Component Firmware – Kees Cook, Google
Protecting the Android TCB with SELinux – Stephen Smalley, NSA
Tizen, Security and the Internet of Things – Casey Schaufler, Intel
Capsicum on Linux – David Drysdale, Google
Quantifying and Reducing the Kernel Attack Surface - Anil Kurmus, IBM
Extending the Linux Integrity Subsystem for TCB Protection – David Safford & Mimi Zohar, IBM
Application Confinement with User Namespaces – Serge Hallyn & Stéphane Graber, Canonical

Discussion session topics include Trusted Kernel Lock-down Patch Series, led by Kees Cook; and EXT4 Encryption, led by Michael Halcrow & Ted Ts’o. There’ll be kernel security subsystem updates from the SELinux, AppArmor, Smack, and Integrity maintainers. The break-out sessions are open format and a good opportunity to collaborate face-to-face on outstanding or emerging issues.

See the schedule for more details.

LSS2014 is open to all registered attendees of LinuxCon. Note that discounted registration is available until the 18th of July (end of this week).

See you in Chicago!

Russell Coker (security): Fixing Strange Directory Write Access

etbe — Wed, 25 Jun 2014 02:40:42 +0000

type=AVC msg=audit(1403622580.061:96): avc: denied { write } for pid=1331 comm="mysqld_safe" name="/" dev="dm-0" ino=256 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
type=SYSCALL msg=audit(1403622580.061:96): arch=c000003e syscall=269 success=yes exit=0 a0=ffffffffffffff9c a1=7f5e09bfe798 a2=2 a3=2 items=0 ppid=1109 pid=1331 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mysqld_safe" exe="/bin/dash" subj=system_u:system_r:mysqld_safe_t:s0 key=(null)

For a long time (probably years) I’ve been seeing messages like the above in the log from auditd (/var/log/audit/audit.log) when starting mysqld. I haven’t fixed it because the amount of work exceeded the benefit, it’s just a couple of lines logged at every system boot. But today I decided to fix it.

The first step was to find out what was going on, I ran a test system in permissive mode and noticed that there were no attempts to create a file (that would have been easy to fix). Then I needed to discover which system call was triggering this. The syscall number is 269, the file linux/x86_64/syscallent.h in the strace source shows that 269 is the system call faccessat. faccessat(2) and access(2) are annoying cases, they do all the permission checks for access but don’t involve doing the operation so when a program uses those system calls but for some reason doesn’t perform the operation in question (in this case writing to the root directory) then we just get a log entry but nothing happening to examine.

A quick look at the shell script didn’t make the problem obvious, note that this is probably obvious to people who are more skilled at shell scripting than me – but it’s probably good for me to describe how to solve these problems every step of the way. So the next step was to use gdb. Here is the start of my gdb session:

# gdb /bin/sh
[skipped]
Reading symbols from /bin/dash…(no debugging symbols found)…done.
(gdb) b faccessat
Breakpoint 1 at 0×3960
(gdb) r -x /usr/bin/mysqld_safe
[lots skipped]
+ test -r /usr/my.cnf
Breakpoint 1, 0x00007ffff7b0c7e0 in faccessat ()
from /lib/x86_64-linux-gnu/libc.so.6

After running gdb on /bin/sh (which is a symlink to /bin/dash) I used the “b” command to set a breakpoint on the function faccessat (which is a library call from glibc that calls the system call sys_faccessat()). A breakpoint means that program execution will stop when the function is called. I run the shell script with “-x” as the first parameter to instruct the shell to show me the shell commands that are run so I can match shell commands to system calls. The above output shows the first call to faccessat() which isn’t interesting (it’s testing for read access).

I then ran the “c” command in gdb to continue execution and did so a few times until I found something interesting.

+ test -w / -o root = root
Breakpoint 1, 0x00007ffff7b0c7e0 in faccessat ()
from /lib/x86_64-linux-gnu/libc.so.6

Above is the interesting part of the gdb output. It shows that the offending shell command is “test -w /“.

I filed Debian bug #752593 [1] with a patch to fix this problem.

I also filed a wishlist bug against strace asking for an easier way to discover the name of a syscall [2].

Dan Walsh: pam_mkhomedir versus SELinux -- Use pam_oddjob_mkhomedir

dwalsh@redhat.com — Wed, 04 Jun 2014 15:24:33 +0000

SELinux is all about separation of powers, minamal privs or reasonable privs.

If you can break a program into several separate applications, then you can use SELinux to control what each application is allowed. Then SELinux could prevent a hacked application from doing more then expected.

The pam stack was invented a long time ago to allow customizations of the login process. One problem with the pam_stack is it allowed programmers to slowly hack it up to give the programs more and more access. I have seen pam modules that do some crazy stuff.

Since we confine login applications with SELinux, we sometimes come in conflict with some of the more powerful pam modules.
We in the SELinux world want to control what login programs can do. For example we want to stop login programs like sshd from reading/writing all content in your homedir.

Why is this important?

Over the years it has been shown that login programs have had bugs that led to information leakage without the users ever being able to login to a system.

One use case of pam, was the requirement of creating a homedir, the first time a user logs into a system. Usually colleges and universities use this for students logging into a shared service. But many companies use it also.

man pam_mkhomedir
The pam_mkhomedir PAM module will create a users home directory if it does not exist when the session begins. This allows    users to be present in central database (such as NIS, kerberos or LDAP) without using a distributed file system or pre-creating a large number of directories. The skeleton directory (usually /etc/skel/) is used to copy default files and also sets a umask for the creation.

This means with pam_mkhomedir, login programs have to be allowed to create/read/write all content in your homedir. This means we would have to allow sshd or xdm to read the content even if the user was not able to login, meaning a bug in one of these apps could allow content to be read or modified without the attacker ever logging into the machine.

man pam_oddjob_mkhomedir
       The pam_oddjob_mkhomedir.so module checks if the user's home directory exists, and if it does not, it invokes the mkhomedirfor method of the com.redhat.oddjob_mkhomedir service for the PAM_USER if the module is running with superuser privileges. Otherwise, it invokes the mkmyhome‐dir method.
       The location of the skeleton directory and the default umask are deter‐mined by the configuration for the corresponding service in oddjobd-mkhomedir.conf, so they can not be specified as arguments to this module.
       If D-Bus has not been configured to allow the calling application to invoke these methods provided as part of the com.redhat.oddjob_mkhome‐dir interface of the / object provided by the com.redhat.oddjob_mkhome‐dir service, then oddjobd will not receive the request and an error will be returned by D-Bus.

Nalin Dahyabhai wrote pam_oddjob_mkhomedir many years ago to separate out the ability to create a home directory and all of the content from the login programs. Basically the pam module sends a dbus signal to a dbus service oddjob, which launches a tool to create the homedir and its content. SELinux policy is written to allow this application to succeed.   We end up with much less access required for the login programs.

If you want the home directory created at login time if it does not exist. Use pam_oddjob_mkhomedir instead of pam_mkhomedir.

Dan Walsh: DAC_READ_SEARCH/DAC_OVERRIDE - common SELinux issue that people handle badly.

dwalsh@redhat.com — Mon, 12 May 2014 18:02:57 +0000

MYTH: ROOT is all powerful.

Root is all powerful is a common misconception by administrators and users of Unix/Linux systems. Many years ago the Linux kernel tried to break the power of root down into a series of capabilities. Originally there were 32 capabilities, but recently that grew to 64. Capabilities allowed programmers to code application in such a way that the ping command can create rawip-sockets or httpd can bind to a port less then 1024 and then drop all of the other capabilities of root.

SELinux also controls the access to all of the capabilities for a process.    A common bugzilla is for a process requiring the DAC_READ_SEARCH or DAC_OVERRIDE capability. DAC stands for Discretionary Access Control. DAC Means standard Linux Ownership/permission flags. Lets look at the power of the capabilities.

more /usr/include/linux/capability.h
...
/* Override all DAC access, including ACL execute access if
   [_POSIX_ACL] is defined. Excluding DAC access covered by
   CAP_LINUX_IMMUTABLE. */

#define CAP_DAC_OVERRIDE     1

/* Overrides all DAC restrictions regarding read and search on files
   and directories, including ACL restrictions if [_POSIX_ACL] is
   defined. Excluding DAC access covered by CAP_LINUX_IMMUTABLE. */

#define CAP_DAC_READ_SEARCH 2

If you read the descriptions these basically say a process running as UID=0 with DAC_READ_SEARCH can read any file on the system, even if the permission flags would not allow a root process to read it. Similarly DAC_OVERRIDE, means the process can ignore all permission/ownerships of all files on the system. Usually when I see AVC messages that require this access, I take a look at the process UID, and almost always I see the process is running as uid=0.

What users often do when they see this access denial is to add the permissions, which is almost always wrong. These AVC's indicate to me that you have permission flags to tight on a file. Usually a config file.

Imagine the httpd process needs to read /var/lib/myweb/content which is owned by the httpd user and has permissions 600 set on it.

ls -l /var/lib/myweb/content
-rw-------. 1 apache apache 0 May 12 13:50 /var/lib/myweb/content

If for some reason the httpd process needs to read this file while it is running as UID=0, the system will deny access and generate a DAC_* AVC. A simple fix would be to change the permission on the file to be 644.

# chmod 644 /var/lib/myweb/content
# ls -l /var/lib/myweb/content
-rw-r--r--. 1 apache apache 0 May 12 13:50 /var/lib/myweb/content

Which would now allow a root process to read the file using the "other" permissions.

Another option would be to change the group to root and change the permissions to 640.

# chmod 640 /var/lib/myweb/content
# chgrp root /var/lib/myweb/content
# ls -l /var/lib/myweb/content
-rw-r-----. 1 apache root 0 May 12 13:50 /var/lib/myweb/content

Now root can read the file based on the group permissions. but others can not read it. You could also use ACLs to provide access.    Bottom line this is probably not an SELinux issue, and not something you want to loosen SELinux security around.

One problem with SELinux system here is the capabilities AVC message does not tell you which object on the file system blocked the access by default. The reason for this is performance as I explained in previous blog.

Why doen't SELinux give me the full path in an error message?

If you turn on full auditing and regenerate the AVC, you will get the path of the object with the bad DAC Controls, as I explained in the blog.

Dan Walsh: Writing custom policy for an Apache Application.

dwalsh@redhat.com — Tue, 06 May 2014 12:42:51 +0000

Received the following email this week:

I've a PHP application that sends data to a USB tty device e.g. /dev/usbDataCollector

Unfortunately selinux is blocking this action. When set to permissive, the alert browser suggests the command:

setsebool -P daemons_use_tty 1

The documentation says Allow all daemons the ability to use unallocated ttys. This naturally doesn't sound like a good idea although admittedly it probably won't hurt in this particular installation. However, I thought it would be good to find the 'correct' solution to this.

But I am unable to find a more fine grain SELinux control for this, Fedora 20 has no documentation and the only vaguely relevant one I could find elsewhere is httpd_tty_com which appears unrelated as it is about allow httpd to communicate with terminal.

So the question is whether there is any way to do this or is allowing all daemons the only option?

My Answer

Simplest would be to just use

# grep usbDataCollector /var/log/audit/audit.log | audit2allow -M myhttp
# semodule -i myhttp.pp

This would allow all httpd_t processes the ability to use usb_device_t, of course if you had other usb_device_t devices on your system, your apache processes would also gain access to them.

Tighter Controls

SELinux is a labeling system, so you can manipulate the labels on the system to get tighter controls.

If you really wanted to tighten it up, you could build a custom policy that put a different label on /dev/usbDataCollector and allow httpd_t processes access to this label.

Something like

# cat myhttp.te
policy_module(myhttp, 1.0)
gen_require(`
type httpd_t;
')

type httpd_device_t;
dev_node(httpd_device_t)

allow httpd_t httpd_device_t:chr_file rw_chr_file_perms;

Note that I am create a new type httpd_device_t, and I define it as a device node, which gives it attributes to allow domains that manage devices to manage this new device. Then I allow the apache process type, httpd_t, to be able to read/write chr_files with this label.

# cat myhttpd.fc
/dev/usbDataCollector -c
gen_context(system_u:object_r:httpd_device_t,s0)

I also want to put the label on the device automatically so I add a file context file with the /dev/usbDataCollector labeled as httpd_device_t.

# make -f /usr/share/selinux/devel/Makefile
# semodule -i myhttpd.pp
# restorecon -v /dev/usbDataCollector

Finally I compile the myhttpd.te an myhttpd.fc file into a myhttpd.pp policy package, and install it on the system. Since the device is probably already created I need to run restorecon on it to fix the label. udev will set the label automatically on the next reboot.

Now httpd_t processes would only be able to use the /dev/usbDataCollector chr_file and not other usb devices on the system.
</div>

James Morris: Linux Security Summit 2014 (Chicago) -– Call for Participation

jamesm — Tue, 29 Apr 2014 11:41:10 +0000

The CFP for the 2014 Linux Security Summit is announced.

LSS 2014 will be co-located with LinuxCon North America in Chicago, on the 18th and 19th of August. We’ll also be co-located with the Kernel Summit this year.

Note that, as always, we’re looking for participation from the general Linux community — not just kernel people, and not just developers. We’re interested in hearing about feedback from users, and discussing what kinds of security problems we need to be addressing into the future.

This year, we’re looking for discussion topics as well as paper presentations, so if you have anything interesting to talk about, send in a proposal.

The CFP closes on 6th June 21st June.

Russell Coker (security): Replacement Credit Cards and Bank Failings

etbe — Sat, 12 Apr 2014 00:25:39 +0000

I just read an interesting article by Brian Krebs about the difficulty in replacing credit cards [1].

The main reason that credit cards need to be replaced is that they have a single set of numbers that is used for all transactions. If credit cards were designed properly for modern use (IE since 2000 or so) they would act as a smart-card as the recommended way of payment in store. Currently I have a Mastercard and an Amex card, the Mastercard (issued about a year ago) has no smart-card feature and as Amex is rejected by most stores I’ve never had a chance to use the smart-card part of a credit card. If all American credit cards had a smart card feature which was recommended by store staff then the problems that Brian documents would never have happened, the attacks on Target and other companies would have got very few card numbers and the companies that make cards wouldn’t have a backlog of orders.

If a bank was to buy USB smart-card readers for all their customers then they would be very cheap (the hardware is simple and therefore the unit price would be low if purchasing a few million). As banks are greedy they could make customers pay for the readers and even make a profit on them. Then for online banking at home the user could use a code that’s generated for the transaction in question and thus avoid most forms of online banking fraud – the only possible form of fraud would be to make a $10 payment to a legitimate company become a $1000 payment to a fraudster but that’s a lot more work and a lot less money than other forms of credit card fraud.

A significant portion of all credit card transactions performed over the phone are made from the customer’s home. Of the ones that aren’t made from home a significant portion would be done from a hotel, office, or other place where a smart-card reader might be conveniently used to generate a one-time code for the transaction.

The main remaining problem seems to be the use of raised numbers. Many years ago it used to be common for credit card purchases to involve using some form of “carbon paper” and the raised numbers made an impression on the credit card transfer form. I don’t recall ever using a credit card in that way, I’ve only had credit cards for about 18 years and my memories of the raised numbers on credit cards being used to make an impression on paper only involve watching my parents pay when I was young. It seems likely that someone who likes paying by credit card and does so at small companies might have some recent experience of “carbon paper” payment, but anyone who prefers EFTPOS and cash probably wouldn’t.

If the credit card number (used for phone and Internet transactions in situations where a smart card reader isn’t available) wasn’t raised then it could be changed by posting a sticker with a new number that the customer could apply to their card. The customer wouldn’t even need to wait for the post before their card could be used again as the smart card part would never be invalid. The magnetic stripe on the card could be changed at any bank and there’s no reason why an ATM couldn’t identify a card by it’s smart-card and then write a new magnetic stripe automatically.

These problems aren’t difficult to solve. The amounts of effort and money involved in solving them are tiny compared to the costs of cleaning up the mess from a major breach such as the recent Target one, the main thing that needs to be done to implement my ideas is widespread support of smart-card readers and that seems to have been done already. It seems to me that the main problem is the incompetence of financial institutions. I think the fact that there’s no serious competitor to Paypal is one of the many obvious proofs of the incompetence of financial companies.

The effective operation of banks is essential to the economy and the savings of individuals are guaranteed by the government (so when a bank fails a lot of tax money will be used). It seems to me that we need to have national banks run by governments with the aim of financial security. Even if banks were good at their business (and they obviously aren’t) I don’t think that they can be trusted with it, an organisation that’s “too big to fail” is too big to lack accountability to the citizens.

[1] http://tinyurl.com/msfby5q

Dan Walsh: DAC check before MAC check. SELinux will stop wine'ing.

dwalsh@redhat.com — Wed, 05 Mar 2014 13:53:10 +0000

When it comes to SELinux, one of the most aggravating bugs we see are when the kernel does a MAC check before a DAC Check.

This means SELinux checks happen before normal ownership/permission checks. I always prefer to have the DAC check happen first. This is important because code that is attempting the denied access usually will handle the EPERM silently and go down a different code path. But if a MAC Failure happens, SELinux writes an AVC to the audit log, and setroubleshoot reports it to the user.

One of the biggest offenders of this was the mmap_zero check. Every time a process tries to map low kernel memory, the kernel denies it, in both DAC and MAC. Wine applications are notorious for this. We block mmap_zero because it can potentially trigger kernel bugs which can lead to privilege escalation.

Eric Paris explains the vulnerability here.

Since the MAC check was done before the DAC check, the wine applications tend to work correctly. When the wine application attempts to mmap low memory, it gets denied, and then reattempts the mmap with a higher memory value. On an SELinux system the kernel generates AVC. The user sees something like:

SELinux is preventing /usr/bin/wine-preloader from 'mmap_zero' accesses on the memprotect.

Reading about the mmap_zero, scares the user and they think their machine is vulnerable. The only thing SELinux policy writers can do is write a dontaudit rule or allow the access, which defeats the purpose of the check.

We still want to block this access if a privileged confined process got it and report the SELinux violation. If an confined application running as root, attempts a mmap_zero access, SELinux should block it and report the AVC. If a normal unprivileged process triggered the access check, we would prefer to allow DAC to handle it, and not print the message.

To give you an idea of how often people have seen this; Google "SELinux mmap_zero" and you will get more then 13,000 hits.

Today the upstream kernel has been fixed to report check for mmap_zero for MAC AFTER DAC.

Thanks to Eric Paris and Paul Moore for fixing this issue.

Dan Walsh: SELinux Transitions do not happen on mountpoints mounted with nosuid.

dwalsh@redhat.com — Fri, 28 Feb 2014 18:43:37 +0000

Today one of our customers was trying to run openshift enterprise and it was blowing up because of SELinux.
Openshift sets up the Apache daemon to run /var/www/openshift/broker/script/broker_ruby.

When looked at the log, it was stating that Apache was not allowed to execute broker_ruby permission denied.

ls -lZ /var/www/openshift/broker/script/broker_ruby
Shows that broker_ruby is labeled as httpd_sys_content_t

I went and looked at policy, I saw.

sesearch -A -s httpd_t -t httpd_sys_content_t -p execute -C
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 shows that the httpd_t (Apache) process is allowed to execute the broker_ruby script if all of the following booleans are enabled.
httpd_enable_cgi, httpd_unified, httpd_builtin_scripting

Turns out the were. I then went back and looked at the AVC.

type=AVC msg=audit(28/02/14 13:56:52.702:24992) : avc: denied { execute_no_trans } for pid=6031 comm=PassengerHelper path=/var/www/openshift/broker/script/broker_ruby dev=dm-3 ino=817 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file

This AVC means that the Apache daemon (httpd_t) is not allowed to execute the broker_ruby application (httpd_sys_content_t) without a transition, meaning in the current label (httpd_t).

Which I understood, since when the above booleans are turned on httpd_t is supposed to transition to httpd_sys_script_t when executing httpd_sys_content_t. This sesearch command shows the transition rule.

sesearch -T -s httpd_t -t httpd_sys_content_t -c process -C
DT type_transition httpd_t httpd_sys_content_t : process httpd_sys_script_t; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]

Why wasn't the process transitioning?

Then I remembered that SELinux transitions do not happen on mounted partitions that are mounted with the nosuid flag.

man mount
...
nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.)

SELinux designers feel that a transition can be a potential privilege escalation similar to a suid root application. Therefore if an administrator has told the system that no suid apps should be allowed on a mount point, then it also means no SELinux transitions will happen.

Removing the nosuid flag from the mount point fixes the problem.

James Morris: Save the Date: 2014 Linux Security Summit in Chicago

jamesm — Thu, 13 Feb 2014 13:55:38 +0000

The 2014 Linux Security Summit will be held on the 18th and 19th of August, co-located with LinuxCon in Chicago, IL, USA. The Kernel Summit and several other events will also be co-located there this year.

The Call for Participation will be announced later via the LSM mailing list.

Russell Coker (security): Fingerprints and Authentication

etbe — Mon, 10 Feb 2014 05:07:12 +0000

Dustin Kirkland wrote an interesting post about fingerprint authentication [1]. He suggests using fingerprints for identifying users (NOT authentication) and gives an example of a married couple sharing a tablet and using fingerprints to determine who’s apps are loaded.

In response Tollef Fog Heen suggests using fingerprints for lightweight authentication, such as resuming a session after a toilet break [2].

I think that one of the best comments on the issue of authentication for different tasks is in XKCD comic 1200 [3]. It seems obvious that the division between administrator (who installs new device drivers etc) and user (who does everything from playing games to online banking with the same privileges) isn’t working, and never could work well – particularly when the user in question installs their own software.

I think that one thing which is worth considering is the uses of a signature. A signature can be easily forged in many ways and they often aren’t checked well. It seems that there are two broad cases of using a signature, one is to enter into legally binding serious contract such as a mortgage (where wanting to sign is the relevant issue) and the other is cases where the issue doesn’t matter so much (EG signing off on a credit card purchase where the parties at risk can afford to lose money on occasion for efficient transactions). Signing is relatively easy but that’s because it either doesn’t matter much or because it’s just a legal issue which isn’t connected to authentication. The possibility of serious damage (sending life savings or incriminating pictures to criminals in another jurisdiction) being done instantly never applied to signatures. It seems to me that in many ways signatures are comparable to fingerprints and both of them aren’t particularly good for authentication to a computer.

In regard to Tollef’s ideas about “lightweight” authentication I think that the first thing that would be required is direct user control over the authentication required to unlock a system. I have read about some Microsoft research into a computer monitoring the office environment to better facilitate the user’s requests, an obvious extension to such research would be to have greater unlock requirements if there are more unknown people in the area or if the device is in a known unsafe location. But apart from that sort of future development it seems that having the user request a greater or lesser authentication check either at the time they lock their session or by policy would make sense. Generally users have a reasonable idea about the risk of another user trying to login with their terminal so user should be able to decide that a toilet break when at home only requires a fingerprint (enough to keep out other family members) while a toilet break at the office requires greater authentication. Mobile devices could use GPS location to determine unlock requirements, GPS can be forged, but if your attacker is willing and able to do that then you have a greater risk than most users.

Some users turn off authentication on their phone because it’s too inconvenient. If they had the option of using a fingerprint most of the time and a password for the times when a fingerprint can’t be read then it would give an overall increase in security.

Finally it should be possible to unlock only certain applications. Recent versions of Android support widgets on the lock screen so you can perform basic tasks such as checking the weather forecast without unlocking your phone. But it should be possible to have different authentication requirements for various applications. Using a fingerprint scan to allow playing games or reading email in the mailing list folder would be more than adequate security. But reading the important email and using SMS probably needs greater authentication. This takes us back to the XKCD cartoon.

Dan Walsh: Containers your time is now. Lets look at Namespaces.

dwalsh@redhat.com — Fri, 31 Jan 2014 16:44:17 +0000

Lately I have been spending a lot of time working on Containers. Containers are a mechanism for controlling what a process does on a system.

Resource Constraints can be considered a form of containerment.

In Fedora and RHEL we use cgroups for this, and with the new systemd controls in Fedora and RHEL7, managing cgroups has gotten a lot easier. Out of the box all of your processes are put into a cgroup based on whether they are a user, system service or a Machine (VMs). These processes are grouped at the unit level, meaning two users logged into a system will get and "Fair Share" of the system, even if one user forks off thousands of processes. Similarly if you run an httpd service and a mariadb service, they each get an equal share of the system, meaning that httpd can not fork 1000 process while mariadb only runs three, the httpd 1000 processes can not dominate the machine leaving no memory of cpu for mariadb. Of course you can go into the unit files for httpd or mariadb and add a couple of simple resource constraints to further limit them

Adding

MemoryLimit: 500m

to httpd.service unit file

For example will limit the service to only use 500 megabytes to httpd processes.

Security Containment

Some could say I have been working on containers for years since SELinux is a container technology for controlling what a process does on the system. I will talk about SELinux and advanced containers in my next blog.

Process Separation Containment

The last component of containers is Namespaces. The linux kernel implements a few namespaces for process separation. There are currently 6 namespaces.

Namespaces can be used to Isolate processes. They can create a new environment where changes to the process are not reflected in other namespace.
Once set up, namespaces are transparent for processes.

Red Hat Enterprise Linux and Fedora currently support 5 namespace

ipc namespace allows you to have shared memory, semaphores with only processes within the namespace.

pid namespace eliminates the view of other processes on the system and restarts pids at pid 1.

mnt namespace allows processes within the container to mount file systemd over existing files/directories without affecting file systems outside the namespace

net namespace creates network devices that can have IP Addresses assigned to them, and even configure iptables rules and routing tables

uts namespace allows you to assign a different hostname to processes within the container. Often useful with the network namespace

Rawhide also supports the user namespace. We hope to add the user namespace support to a future Red Hat Enterprise Linux 7.

User namespace allows you to map real user ids on the host to container uids. For example you can map UID 5000-5100 to 0-100 within the container. This means you could have uid=0 with rights to manipulate other namespaces within the container. You could for example set the IP Address on the network namespaced ethernet device. Outside of the container your process would be treated as a non privileged process. User namespace is fairly young and people are just starting to use it.

I have put together a video showing namespaces in Red Hat Enterprise Linux 7.

https://www.youtube.com/watch?v=e4NXJ5nM-_M&feature=youtu.be

Dan Walsh: file_t we hardly new you...

dwalsh@redhat.com — Mon, 13 Jan 2014 15:01:24 +0000

file_t disappeared as a file type in Rawhide today. It is one of the oldest types in SELinux policy. It has been aliased to unlabeled_t.

Why did we remove it?

Let's look at the comments written in the policy source to describe file_t.

# file_t is the default type of a file that has not yet been
# assigned an extended attribute (EA) value (when using a filesystem
# that supports EAs).

Now lets look at the description of unlabeled_t

# unlabeled_t is the type of unlabeled objects.
# Objects that have no known labeling information or that
# have labels that are no longer valid are treated as having this type.

Notice the conflict.

If a file object does not have a labeled assigned to it, then it would be labeled unlabeled_t. Unless it is on a file system that supports extended attributes then it would be file_t?

I always hated explaining this, and we have finally removed the conflict for future Fedora's. Sadly this change has not been made in RHEL7 or any older RHELs or Fedoras.

We also added a type alias for unlabeled_t to file_t.

Note: Seandroid made this change when the policy was first being written.

One other conflict I would like to fix is that a file with a label that the kernel does not understand, is labeled unlabeled_t. (IE It has a label but it is invalid.) I have argued for having the kernel differentiate the two situations.

No label -> unlabeled_t

Invalid Label -> invalid_t.

Upstream has pointed out from a practical/security point of view you really need to treat them both as the same thing. Confined domains are not allowed to use unlabeled_t objects. And if it is a file system object you should run restorecon on it. Putting a legitimate label on the object. Probably I will not get this change, but I can always hope.

Russell Coker (security): Dr Suelette Dreyfus LCA Keynote

etbe — Wed, 08 Jan 2014 00:37:20 +0000

Dr Suelette Dreyfus gave an interesting LCA keynote speech on Monday (it’s online now for people who aren’t attending LCA [1]). One of the interesting points she made was regarding the greater support for privacy protection in Germany, this is apparently due to so many German citizens having read their own Stasi files.

The section of her talk about the technology that is being used against us today was very concerning. I wonder whether we should plan to move away from using any hardware or closed source software from the US, China, and probably most countries other than Germany.

We really need to consider these issues at election time. I have previously blogged some rough ideas about having organisations such as Linux Australia poll parties to determine how well they represent the interests of citizens who use Linux [2]. I think that such things are even more important now. Steven Levy wrote an interesting summary of the situation for Wired [3].

At the end of her talk Suelette suggested that Aspies might be more likely to be whistle-blowers due to being unable to recognise the social signals about such things (IE managers say that they won’t punish people for speaking out but most people recognise that to be lies). It’s a plausible theory but I’m worried that managers might decide to avoid hiring Aspies because of this. I wonder how many managers plan to have illegal activity as an option. But I guess that having criminals refuse to hire me wouldn’t be such a bad thing.

Dan Walsh: How come somethings get blocked by SELinux in permissive mode?

dwalsh@redhat.com — Thu, 02 Jan 2014 15:33:11 +0000

SELinux can be setup to run in three modes.

* Enforcing (My favorite)
* Permissive
* Disabled

Often permissive is described as the same as enforcing except everything is allowed and logged.

For the most part this is true, except when their are bugs or a "Access Control Manager" does not respect the permissive flag.

Most of SELinux is written where the kernel control's access, and it would be very strange for the kernel to block an access in permissive mode.

But there are several situations where we want to check access outside the kernel. For example.

Can an application connect to a particular dbus daemon?

Can a service start a particular systemd daemon?

Can a root process change the password of something?

Will sshd allow dwalsh to login as unconfined_t?

All of these checks are not seen by the kernel. We implement SELinux checks in places like dbus daemon, systemd, X Server, sshd, passwd ... When one of these services denies access you will see a USER_AVC generated rather then an AVC. If these SELinux checks are not written correctly to check the permissive flag when an access is denied, you could get a real denial in permissive mode.

Usually we see these as bugs, but in certain situations the upstream does not want to accept patches to check the permissive flag.

If you know of a situation where this happens, open a bugzilla on it and we can work with the packager to fix the problem.

When you see an AVC or USER_AVC that is generated in permissive mode, you should see a flag that states "success=yes" in the AVC record, this indicates that the AVC was generated but still allowed. If it says "success=no" in permissive mode then that should be considered a bug.

Dan Walsh: Awesome new coreutils with improved SELinux support

dwalsh@redhat.com — Wed, 18 Dec 2013 13:19:06 +0000

When I first started working on SELinux over 10 years ago, one of the first packages I worked on was coreutils.    We were adding SELinux support to insure proper handling of labeling. After that we did not touch it for several years.

Last year, I decided to investigate if I could improve coreutils handling of labels on initial content creation.   Well it took a while but my patches were finally accepted, with lots of fixes from the upstream, and coreutils-8.22 just showed up today in Rawhide.

I am very excited about this release. I believe it can allow Administrators to fix one of the biggest problems users have with SELinux, objects getting created with the incorrect context.

My patches basically standardized "-Z" with no options to indicate you wanted the target directory to get the "default" label.

Example:

# touch /tmp/foobar
# mv /tmp/foobar /etc
# ls -lZ /etc/foobar
# -rw-r--r--. root root staff_u:object_r:user_tmp_t:s0   /etc/foobar

As opposed to:

# touch /tmp/foobar
# mv -Z /tmp/foobar /etc
# ls -lZ /etc/foobar
# -rw-r--r--. root root staff_u:object_r:etc_t:s0   /etc/foobar

The traditional use of a command like mv was to maintain the "Security" of an object you are moving. mv command would maintain the ownership, permissions, and SELinux Labels. The problem with this is users/administrators would not expect this, by adding the "-Z" to the mv command, the administrator guarantees that the object will get he correct label based on the destination path, which over the years, I believe is what the administrator would expect. The "-Z" option in coreutils now indicates the equivalent of running restorecon on the target, except in most cases the label is correct on creation of the content.

"mv -Z /tmp/foobar /etc/foobar" == "mv /tmp/foobar /etc/foobar; restorecon /tmp/foobar"

One of the reasons we did not do this sooner, was the speed of reading in the labeling database. The latest SELinux toolchain loads the labeling database in a fraction of the previous time, allowing us to make these changes.

Setting up coreutils alias

I would even suggest that it would be a good idea to alias

alias mv='mv -Z'

for most users.

A common mistake is to mv content around in the homedir. A mistake I have made in the past was to an html file to a my account on people.fedoraproject.org and then to ssh into the machine and then mv it to the public_html directory. ~/public_html is labeled httpd_user_content_t which is readable by default from the apache server, while the default label of my homedir is not, user_home_t.

mv ~/content.html ~/public_html/

This command would end up with the ~/public_html/content.html being labeled user_home_t, and the page would not show up on the web site. Users would not know why, and would probably not no about SELinux. But if the admistrator changed the alias for the mv command, everything would just work.

Other Commands

Similarly the -Z option has been implemented for all of the commands that create content in coreutils.

mknod -Z, mkdir -Z, mkfifo -Z, install -Z

Currently in init scripts we have lots of code that does; \

mkdir /run/myapp; restorecon /run/myapp

Which can be replaced with

mkdir -Z /run/myapp

What about Disabled Machines, or machines that do not support SELinux?

On an SELinux disabled system, the -Z option will be ignored.

Conclusion

Getting the Label correct at file creation has been improved greatly in the current Fedora's with the introduction of file name transitions. Fixing coreutils to allow administrators to change the default of standard tools to set default labels on object creation is nice.

alias mv='mv -iZ'
alias cp='cp -iZ'
alias mkdir='mkdir -Z"
alias mknod='mknod -Z"
alias install='install -Z"

I hope to get this new coreutils backported into RHEL7...

Security

One thing to remember about this from a security point of view. A calling confined domain would still be prevented from creating content with the default label, if it was not allowed by SELinux policy to create content with that label. The change to coreutils, just allows the process to attempt to create the content with the correct label.

Thanks to coreutils upstream for working on these patches with us.

Dan Walsh: golang support for libselinux in Rawhide.

dwalsh@redhat.com — Tue, 17 Dec 2013 16:26:33 +0000

Every so often I get to spend a couple of days working on a new computer language, but it has been a while.

I am working on a project to bring SELinux support to docker.

The basic idea is to launch containers with a specific SELinux type and Random MCS label. Using pretty much the same technology as we use with sVirt. We do this using libvirt and virt-sandbox-service in Fedora now, but we want to implement similar support for docker.

One problem I had when I first starting working on this project was that docker is written in the go programming language. I did not know the go language and there were no libselinux bindings for go.

Luckily go is fairly easy to bind to the C Language using cgo. After a couple of weeks work, I put together selinux.go which implements all of the functions that I needed to get containers running with SELinux labels. Going forward it would be nice to hook up all of the libselinux functions. (Patches welcomed).

Package will show up in libselinux-2.2.1-3.fc21

/usr/share/gocode/selinux/selinux.go

Any input for improvements to go code would be welcome.

Dominick Grift: finding file context files that do not end with a newline

Dominick "domg472" Grift (noreply@blogger.com) — Sun, 15 Dec 2013 11:04:03 +0000

file context files not ending with a newline cause annoying situations.

 #!/bin/bash --  
 #  
 # This script looks for file context files  
 # that do not end with a newline  
 #  
 REF_PATH="/home/dominick/Git/refpolicy"  
 for i in $(/bin/find $(printf "%s" "$REF_PATH") -type f -name "*.fc") ; do  
     [[ "$(/bin/tail -c 1 $i | /bin/tr -dc '\n' | /bin/wc -c)" -ne 1 ]] && printf "%s\n" "Fix me: $i"  
 done  
 exit $?  
 #EOF

Dominick Grift: quick script to check for unsupported device nodes by SELinux

Dominick "domg472" Grift (noreply@blogger.com) — Wed, 11 Dec 2013 08:18:37 +0000

 #!/bin/bash --  
 #  
 # This script checks for device nodes that are unsupported by SELinux  
 # Unsupported device nodes fall back to the device_t generic type identifier for content in /dev   
 # The script just finds all chars and blocks, then looks if any of them as associated with the device_t type identifier  
 # If any device node is associated with device_t sid then the script uses matchpathcon to determine if SELinux is aware of the device node  
 # If matchpathcon thinks the device node should be associated with the device_t type then the device node is unsupported by SELinux one way or another  
 #  
 IFS=$'\n'  
 recurse_char() {  
  for i in "$1"/*;do  
   if [ -d "$i" ];then  
     recurse_char "$i"  
   elif [ -c "$i" -a ! -L "$i" ]; then  
     echo "$(ls -alZ "$i")"  
   fi  
  done  
 }  
 recurse_block() {  
  for i in "$1"/*;do  
   if [ -d "$i" ];then  
     recurse_block "$i"  
   elif [ -b "$i" -a ! -L "$i" ]; then  
     echo "$(ls -alZ "$i")"  
   fi  
  done  
 }  
 for s in $(recurse_char /dev); do  
      if [ "$(echo $s | /usr/bin/awk -F " " '{ print $4 }' | /usr/bin/awk -F ":" '{ print $3 }')" == "device_t" ] ; then  
           IFS=" "  
           read -r bits owner group context char <<< "$s"  
           mpc=$(/usr/sbin/matchpathcon "$char")  
           if [ "$(echo $mpc | /usr/bin/awk -F " " '{ print $2 }' | /usr/bin/awk -F ":" '{ print $3 }')" == "device_t" ] ; then  
                echo "unsupported char device: $char"  
           fi  
      fi  
 done  
 for s in $(recurse_block /dev); do  
      if [ "$(echo $s | /usr/bin/awk -F " " '{ print $4 }' | /usr/bin/awk -F ":" '{ print $3 }')" == "device_t" ] ; then  
           IFS=" "  
           read -r bits owner group context block <<< "$s"  
           mpc=$(/usr/sbin/matchpathcon "$block")  
           if [ "$(echo $mpc | /usr/bin/awk -F " " '{ print $2 }' | /usr/bin/awk -F ":" '{ print $3 }')" == "device_t" ] ; then  
                echo "unsupported block device: $block"  
           fi  
      fi  
 done  
 exit 0;  
 #EOF

Dominick Grift: Another idea

Dominick "domg472" Grift (noreply@blogger.com) — Mon, 09 Dec 2013 08:39:18 +0000

We have the sepolicy tool that has functionality that aims to make policy development easier. One great benefit is the single point of failure aspect it provides. By using the tool for policy development you reduce risk of typo's and syntax errors. If you have to type everything yourself manually then much can go wrong.

The tool also has it's drawback because you are bound to the functionality the tool provides but nothing stops you from manually editing the generated policy, and so that is pretty much a non-issue.

For some reason typo's and syntax errors are a pretty common thing for many policy developers, and so from that perspective it is probably a good idea to use the tool more often.

Anyhow, The reference policy provides a api "mechanism", and api's make life easier. The issue is that these api's are not checked until they are actually called or until a tool like sepolgen-ifgen is run on them. So if one writes api's manually then those api's might not work due to some stupid typos, but the typos are often not identified until some one calls the api's.

Back earlier we had this policy of not adding api's unless they are actually used. However the point was made that audit2allow cannot suggest an api to use if its not available and so we agreed that it is probably better to add various api's even if they are not used.

So adding api's that aren't used, and that might be written manually thus contain typos and syntax errors. That means that api's that have typo's in them might not work and we don't know about it because we do not use them.

He/She who fits the shoes wears them. I make typos in unused api's often. Just a few days ago i fixed two typos in admin interfaces that i made myself, and it annoys me. Because i am the type of person that likes to manually write his policy rather than depend on a tool (even though i know the tools purpose and i appreciate the issues it solves) I guess i am just stubborn sometimes.

To keep a long story short: It might be a good idea to create an api test script. Again not an all-inclusive test but just to determine whether it can be called or not. The sepolgen-ifgen tool might be able to help identifying issues as well.

Basically a script that just calls interfaces, templates, patterns etc to see if they build.

Api's are our calling cards. It's how callers see us. If we provide broken interfaces then that leaves a bad impression. That is why i think they deserve more attention because they are not there just for us but also for others.

Dominick Grift: How I think distribution maintainers can enhance quality assurance

Dominick "domg472" Grift (noreply@blogger.com) — Thu, 05 Dec 2013 03:28:29 +0000

Here is a list with things distribution maintainers can do to enhance quality assurance

1. Do proof reading.

This enhancement applies to some distributions more than others. Lets define those "active" distribution and "passive" distributions.

An active distribution is one that is constantly changing. Whereas a passive distribution is mostly "stale", and changes less frequent.

A property of active distributions is their activity. Fast development where Security policy must constantly be adapted to support these fast developments.

Maintaining policy for such scenarios is just hard work often. Things must be "fixed" quick and often. This is a recipe for human error.

Because often in the rush one tends to make assumptions, plain types and syntax errors, or other relatively simple mistakes.

Proof reading commits, and a fresh pair of eyes can save time here. By just spending a little day each day reviewing new commits such errors can be identified and fixed quickly.

Some of this proof reading requires humans for example identifying mistakes due to assumptions. Other proof reading can be automated, for example typos and syntax errors.

These human mistakes are often relatively harmless but sometimes they are harmful. The point i am trying to make is that this can be easily prevented.

For the record, i am not suggesting that this proof reading is for identifying complex issues. Because that is a but more complicated and probably takes a little more time

No instead i am suggesting that this method can filter out obvious errors. I can tell you from experience that this pay's off. Besides how hard is it to spend a little time regularly running a couple scripts on new commits to spot typos, syntax errors, and to spend five minutes a day reviewing yesterdays commits.

2. Test you policy for all common scenarios.

Policy can be built with various options. Distributions often do not use all these options. Problems can arise when you do not test building the policy with all options. This might be irrelevant in the short term because i head distribution maintainers think, if it works for us then why bother?

There are two reasons for that:

A. Your priorities might not align with the priorities of upstream, and for your own sake it is better to work with upstream. The more you divert the harder it gets to maintain your project. Merging new upstream releases becomes harder and take more time. By just making sure things work for all scenarios you increase chances of your changes being applied upstream. If you policy only works with a subset of options than upstream has little choice than to refuse the patch. To waste your time, upstreams time. its inefficient.

B. Besides. We know what SELinux is right. What defines SELinux. Its the flexibility and configurability. That's why i use SELinux as opposed to any of the other LSM-Based MAC systems. So as a distro maintainer i would actually advertise these properties. One obvious and easy way to do that is to make sure you project builds and installs in all common scenarios.

Sure there are limits to what you can support. Lets just use the same limits are upstream since we depend on eachother.

So, every once in a while. build your policy with different sets op options, to make sure that it builds. Also You might want to every onces in a while install it with various options that way you can identify bugs in the user space component.

Because this is not only an issue with policy, its also an issue with user space. User space must support all common policy and all its options.

3. Make sure that what you target at least works in common configurations.

If you target a daemon then it might be good to write a simple test for some of the common configurations. I am not suggesting all-inclusive tests. Just some default test to make sure the most obvious functionality works. It obviously requires some investments, at least initially but it might just mean the difference between a good or a bad impression.

4. Test your security goals.

Good, the processes you target can function and you have a way to verify that. But what about security? thats what we do all this for. Simple changes to the policy can have huge effects. By defining your security goals, and crucial properties of your security identifiers, you make it possible to verify that they meet your requirements over time. Run simple tests. We have great tools for that.
This can be automated perfectly

5. Other processes and SELinux

In essence SELinux is transparent to the user space. However user space components can be made aware of SELinux or can even be expected to manage parts of SELinux. For example setting security contexts on files. These programs are often written by parties that might not understand SELinux principles and concepts as well as some of us do.

This can affect the SELinux experience as a whole so its in our interest that these processes make the right decisions. One common mistakes is processes hardcoding security identifiers. Generally harmless but it harms experience and it can easily be prevented by loading a bare (dummy) policy and then checking dmesg or whatever to see if some processes are trying to use identifiers that do not exist. There are more conceivable tests imaginable.

These are just some ways distribution maintained can enhance quality assurance. Many of these point apply to both the security policy component as well as the user space component

Dominick Grift: Can SELinux be made simpler?

Dominick "domg472" Grift (noreply@blogger.com) — Thu, 05 Dec 2013 02:46:43 +0000

Disclaimer: this is just my opinion

This must be a trick question. There is no easy answer for this.

First we should define SELinux to be able to put the question into a context

SELinux has three components: The LSM-Based system in the kernel, the tools and libraries, and lastly security policy

We also need to determine what defines SELinux in compared to other LSM-Based systems in the kernel

The answer to the latter question is Flexibility and configurability. Thats what defines SELinux. It a main property of SELinux. There are other LSM-Based system with other properties for example SMAC (simple mandatory access control) That system is defined by simplicity (but needless to say it lacks flexibility/configurability, at least compared to SELinux)

It is easy to translate flexibility to complexity but the end result does not always have to be relatively complex

Another thing to consider are constraints, with that i mean that for example SELinux must be optional, additional. It must be an add-on to the existing Linux DAC framework

This prerequisite brings some more "complexity", There 3 more of those prerequisites (one of them is not optional for SELinux to work). To enforce mandatory integrity processes must be able to change type (role base access control).

The other two prerequisites are optional (must be able to compartmentalise, must be able to enforce confidentiality) (multi category security/multi level security)

Back to the question. We now have most considerations briefly explained.

I Believe The core of SELinux (the LSM-Based System) cannot be made simpler. It is already as simple as can be considering all the requirrments.
Can the tools and libraries make the experience simpler? Maybe a bit, but the main concepts and principles will still apply there is little one can do about that.

The last component is what most people experience: the security policy

So Lets look at the state of that. The policy can be build with the minimal set of requirements (e.g. only enforce integrity optionally/additionally e.g. by complementing traditional DAC)

So we already can exclude some complexity and we do. We have different policy models for different requirements. For example if you have confidentiality requirements, which adds complexity, then you need the mls policy model.

Lets look at a operating system: Fedora currently is a single distro that can basically considered general purpose. You can use it as a workstation, server, or your use case can be even more specific.
But a vendor does not know beforehand how you are going to use it, and so every scenario must be supported.

Here is the dilemma: security is never general. If you want to implement mandatory integrity/confidentiality in a flexible/configurable way by complementing traditional DAC on a general purpose system then you have a complex challenge on your hand which requires complex policy.

So compromises were made: Lets not enforce mandatory integrity on the whole system, but only a part of it. Its give and take. Fine now things are a bit simpler but its not cheap. Now user sessions by default are not contained. To me this is already a great compromise because it basically says, were leaving workstation scenarios out in the cold with regard to mandatory integrity in the user space

fortunately some level of mandatory integrity in the user space is still optionally available, but its a compromise and it does not get the attention that i think it deserves

So its all about compromises. We have some ability to make things "simpler" and we already apply it.

So how to make things (a bit) simpler and actually achieve security goals?

We could create "profiles". For example Fedora webs erver edition. is a profile for a web server. web servers have (relatively) specific properties. So that from a security perspective enables us to implement a relatively specific security policy for that profile. We just target the web server. This makes the policy "simpler"

Fedora Desktop edition has a policy that targets the user space.

Does this solve anything? Not really if you still end up focussing on specific cases. it might help a bit but its still a compromise. Unless of course you really commit to all the profules you defined.

There are more (less obvious) options but its all give and take, and its all with regard to the security policy implemented. The core of SELinux cannot be simplified ( with any significance) without SELinux losing its identity.

So what about setroubleshoot? That is a great success story when it comes to simplifying SELinux?! Not really. Its just a buffed audit2why with a lot of bloat. (no offence) Is still a program that cannot make security decisions for you. All it can do is parse. reference and make it easy to report issues. It does not know when to transition or not.

That is not because its a bad piece of software. its just that security policy is not something that is fixed so you cant hard-code solutions. and to put things into context and determine the security requirements and act on it requires a huge base of logic. Is it even worth trying to create that?

Think about it from a security perspective: do you easily trust a third party with security decisions that affect your lively hood? Do you trust some code to make security decisions for you?

And even if you do, youll miss out on the good still: configurability/flexibility.

Why not instead focus on learning the core principles/concepts, and enable people to implement mandatory integrity that is tailored to their specific requirement?

So how do you do that? CIL is a abstraction language/ compiler that aims to make this easier. Its is relatively simple and it can be used as a layer between a policy management program and the SElinux policy language. It makes things less pain full but still wont change the core principles and concepts.

What it does do is optimise. Optimization can, i guess, in some ways be translated to making things more pleasurable and there by perceivably simpler.

You ask me the question can SELinux be made simpler. my answer is no. but things can be improved and optimized. compromises can also be made

But it does not change anything to the core principles and concepts.

If you want (relatively) simple: look into Simple mandatory access control. You want "flexibility/configurability" embrace selinux

For example on the one hand we make things "simpler" by by default not targeting user sessions, But on the other hand we enable an optional security model that adds a layer of complexity to achieve compartmentalization.

Its all a matter of priorities

KaiGai Kohei: さらばドイツ

kaigai — Sun, 01 Dec 2013 07:54:44 +0000

2011年2月にドイツへ赴任し、以降2年10ヵ月間、SAP社とのアライアンス業務に携わっていたわけですが、11月末で任地での業務を終了し日本へと戻る事になりました。

振り返れば、初めてフランクフルトの空港に到着した後、一歩外へ出たら氷点下の世界（注：ドイツの2月です）で『こりゃトンデモない場所に来たもんだ』と思ったものですが、まぁ、住めば都で何とかなるもんですな。

オフィスはドイツ南西のWalldorf市（SAP本社がある）。住むには少し規模が小さな街なので、隣のHeidelberg市の旧市街のマンションを借り、1月遅れで嫁さんも日本からやってきました。

お仕事的には、2011年前後というのはちょうどSAP社がSUSE LinuxベースのインメモリDB製品 "SAP HANA" をぶち上げ始めた頃で、主に技術面でSAPやSUSEとの折衝や、HANA認定取得の実作業というのが駐在中のメインのお仕事でした。

■ NEC　SAP HANA向けアプライアンスサーバを販売開始
http://www.nec.co.jp/press/ja/1203/0901.html

その他にも、NECのHA製品CLUSTERPROで、SAP NW～HA製品間で連携するためのインターフェース認証を取得したりとか。

■ NEC、「SAP HA Interface Certification」認定を取得した「CLUSTERPRO X 3.1 for SAP NetWeaver」を発売
http://jpn.nec.com/press/201210/20121002_01.html

この手の "○○認証" という仕事が多かったのですが、SAPの認定プログラムはちょくちょくおかしくて、例えば SAP Linux 認証プログラムは80コア/160HTのNECサーバの認定を通すために、SAPの認定プログラムの方を手直しして認定を通したりとか。

一方、OSS活動は工数の20%～30%を充当して良いという事を条件に赴任したので、まだ中途であるSE-PostgreSQLの開発も継続する事ができた。これは会社に感謝。ただ、OSS活動に専従という訳ではないので、MLでの反応が遅れたりと、コミュニティに対して少し申し訳ない。
ドイツに居る間に新たに開発してみたのが PG-Strom というモジュールで、クリスマス休暇の間にCUDAを使ってプロトタイプの実装を行ってみた。これがもう一つ、自分にとって軸となるソフトウェアになるかもしれない。
http://kaigai.hatenablog.com/entry/20120106/1325852100

これをプラハでのPGconf.EUで発表した際に、非常に大きな反響があった事は"コレは行けるんじゃないか？"という確信に繋がった。これはNECに限った事なのか分からないけども、自分の組織の外に対して何かを発表し、フィードバックを得るという機会が極端に少ない、あるいはナイーブになっているような気がする。
そうすると、自分の提案したい事が第三者の視点から見て価値ある事なのか、そうでないのか確信できないので、上司にちょっとダメ出しされただけで萎縮してしまうという事に繋がらないか。
先日、晴れて四捨五入したらオッサン年代に突入したので偉そうな事を書くと、若い人は公式非公式を問わず、自分のアイデアを社外で発表する機会を持った方がよい。そうすると、上司のダメ出しが的を得ているのか、的外れなのか、自分の判断基準を持てるようになるから。

この辺SAPが偉いなと思うのが、SCN(SAP Community Network)という仕組みを用意し、Wikiやブログを通して開発者やパートナー企業とエンドユーザが直接意見交換できる仕組みが機能している事。例えば製品の変な使い方やプロトタイプ的に作ってみた機能（当然公式にはサポート外）をオープンにして、それに対するフィードバックを受けられるようにしている。
もちろん、これはSAPのように非常に強力なパートナー網、顧客網というエコシステムを持っているからこそできる事。同じ事ができる企業は非常に限られている。
ただ、エコシステムの主催者でなくともコントリビュータとして社外の意見フィードバックを活用するというのは可能。まさにOSSコミュニティが日常的に行っている事で、だからこそイノベーションがそこにある。

仕事環境で言うとドイツ人が偉いのは、きっかり時間通りに仕事を切り上げる事。
2011～2013シーズンはBaden-Hillsカーリングクラブでプレーしていたのだけども、毎週火曜日19:30～のリーグ戦に皆きっちり集まるのがすごい。日本のカルチャーでは難しい所もあるけど、ぜひ見習いたい。目前の業務にばかり時間を費やして、別の領域にアンテナを張る時間や余暇の時間がなければ新しい発想なんて生まれないし、それが中長期的には組織を徐々に蝕んでいく事になるんじゃないかと思った。

その他、生活面では嫁さんが考えて日本食を作ってくれたので、病気をする事もなくきっちり職務を遂行する事ができた。感謝。結婚してからの３年間、風邪をひく事すら無くなった。
ヨーロッパに住んでいる事で、なかなか日本からは行きにくい場所を旅行できた事は役得だけど、書き出すとキリがないのでないのでこれはまた別の機会に。

日本に帰った後は、SAPから離れて再びOSSの仕事に戻ります。
自分で手を動かしてコードを書くと同時に、それをお金に換えていく方法をデザインする事が求められているので、タフな仕事だけども、一つのロールモデルとして後進に示せれば良いかなと。

それでは明日、ドイツを発ちます。

Dan Walsh: SELinux Halloween Release

dwalsh@redhat.com — Fri, 01 Nov 2013 12:39:42 +0000

Red Hat had the famous Halloween Release.

Coincidentally a major release of SELinux tool chain went out yesterday. It should be showing up in the Rawhide mirrors now. Most of these code was already in Fedora, and RHEL7, but we were able to upstream some very large patches, and I just thought I would point out the changes that went into this release. The last release of the tool chain April 4, 2013. We still have some small patches in Fedora but most of our code is now upstream.    The change logs below give you some idea of what changes have been made.

libsepol
2.2 2013-10-30
    * Allow constraint denial cause to be determined from Richard Haines.
      - Add kernel policy version 29.
      - Add modular policy version 17.
      - Add sepol_compute_av_reason_buffer(), sepol_string_to_security_class(), sepol_string_to_av_perm().
    * Support overriding Makefile RANLIB from Sven Vermeulen.
    * Fix man pages from Laurent Bigonville.

Checkpolicy
2.2 2013-10-30
    * Fix hyphen usage in man pages from Laurent Bigonville.
    * handle-unknown / -U required argument fix from Laurent Bigonville.
    * Support overriding Makefile PATH and LIBDIR from Laurent Bigonville.
    * Support space and : in filenames from Red Hat.

sepolgen
    * Return additional constraint information.
    * Fix bug in calls to attributes from Red Hat.
    * Add support for filename transitions from Red Hat.
    * Fix sepolgen tests from Red Hat.

libselinux
2.2 2013-10-30
    * Fix avc_has_perm() returns -1 even when SELinux is in permissive mode.
    * Support overriding Makefile RANLIB from Sven Vermeulen.
    * Update pkgconfig definition from Sven Vermeulen.
    * Mount sysfs before trying to mount selinuxfs from Sven Vermeulen.
    * Fix man pages from Laurent Bigonville.
    * Support overriding PATH and LIBBASE in Makefiles from Laurent Bigonville.
    * Fix LDFLAGS usage from Laurent Bigonville
    * Avoid shadowing stat in load_mmap from Joe MacDonald.
    * Support building on older PCRE libraries from Joe MacDonald.
    * Fix handling of temporary file in sefcontext_compile from Red Hat.
    * Fix procattr cache from Red Hat.
    * Define python constants for getenforce result from Red Hat.
    * Fix label substitution handling of / from Red Hat.
    * Add selinux_current_policy_path from Red Hat.
    * Change get_context_list to only return good matches from Red Hat.
    * Support udev-197 and higher from Sven Vermeulen and Red Hat.
    * Add support for local substitutions from Red Hat.
    * Change setfilecon to not return ENOSUP if context is already correct from Red Hat.
    * Python wrapper leak fixes from Red Hat.
    * Export SELINUX_TRANS_DIR definition in selinux.h from Red Hat.
    * Add selinux_systemd_contexts_path from Red Hat.
    * Add selinux_set_policy_root from Red Hat.
    * Add man page for sefcontext_compile from Red Hat.

libsemanage

2.2 2013-10-30
    * Avoid duplicate list entries from Red Hat.
    * Add audit support to libsemanage from Red Hat.
    * Remove policy.kern and replace with symlink from Red Hat.
    * Apply a MAX_UID check for genhomedircon from Laurent Bigonville.
    * Fix man pages from Laurent Bigonville.

policycoreutils
2.2 2013-10-30
    * Properly build the swig exception file from Laurent Bigonville.
    * Fix man pages from Laurent Bigonville.
    * Support overriding PATH and INITDIR in Makefile from Laurent Bigonville.
    * Fix LDFLAGS usage from Laurent Bigonville.
    * Fix init_policy warning from Laurent Bigonville.
    * Fix semanage logging from Laurent Bigonville.
    * Open newrole stdin as read/write from Sven Vermeulen.
    * Fix sepolicy transition from Sven Vermeulen.
    * Support overriding CFLAGS from Simon Ruderich.
    * Create correct man directory for run_init from Russell Coker.
    * restorecon GLOB_BRACE change from Michal Trunecka.
    * Extend audit2why to report additional constraint information.
    * Catch IOError errors within audit2allow from Red Hat.
    * semanage export/import fixes from Red Hat.
    * Improve setfiles progress reporting from Red Hat.
    * Document setfiles -o option in usage from Red Hat.
    * Change setfiles to always return -1 on failure from Red Hat.
    * Improve setsebool error r eporting from Red Hat.
    * Major overhaul of gui from Red Hat.
    * Fix sepolicy handling of non-MLS policy from Red Hat.
    * Support returning type aliases from Red Hat.
    * Add sepolicy tests from Red Hat.
    * Add org.selinux.config.policy from Red Hat.
    * Improve range and user input checking by semanage from Red Hat.
    * Prevent source or target arguments that end with / for substitutions from Red Hat.
    * Allow use of <<none>> for semanage fcontext from Red Hat.
    * Report customized user levels from Red Hat.
    * Support deleteall for restoring disabled modules from Red Hat.
    * Improve semanage error reporting from Red Hat.
    * Only list disabled modules for module locallist from Red Hat.
    * Fix logging from Red Hat.
    * Define new constants for file type character codes from Red Hat.
    * Improve bash completions from Red Hat.
    * Convert semanage to argparse from Red Hat (originally by Dave Quigley).
    * Add semanage tests from Red Hat.
    * Split semanage man pages from Red Hat.
    * Move bash completion scripts from Red Hat.
    * Replace genhomedircon script with a link to semodule from Red Hat.
    * Fix fixfiles from Red Hat.
    * Add support for systemd service for restorecon from Red Hat.
    * Spelling corrections from Red Hat.
    * Improve sandbox support for home dir symlinks and file caps from Red Hat.
    * Switch sandbox to openbox window manager from Red Hat.
    * Coalesce audit2why and audit2allow from Red Hat.
    * Change audit2allow to append to output file from Red Hat.
    * Update translations from Red Hat.
    * Change audit2why to use selinux_current_policy_path from Red Hat.

Dan Walsh: Mistaking a Process label type for a File label type.

dwalsh@redhat.com — Sat, 19 Oct 2013 10:10:26 +0000

Yesterday there was an email from an administrator complaining about semanage.

The administrator was attempting to setup a new directory with a label for cgi scripts.

# semanage fcontext -a -t httpd_sys_script_t "///cgi-bin/.*\.cgi"
ValueError: Type httpd_sys_script_t is invalid, must be a file or device type.

The tool told the administrator that he had made a mistake and attempted to assign a type to a file that was neither a file or device type.

This is a fairly common mistake with SELinux. httpd_sys_script_t is a process label, and SELinux prevents process labels from being placed on files systems. His valid complaint was it is not easy to know whether a particular type was a process type or a file type.

He then suggested that we should have coded something in the name of the type to indicate the type of the type. For example httpd_sys_script_p_t and httpd_sys_script_exec_f_t. This might not be a bad idea, and should be brought up for discussion on the SELinux Policy list.

I looked at semanage code and saw that the tool was checking a list of valid file types against the type field on the command. I saw a fairly easy enhancement would be to strip the "_t" off the type and search the list of "file types" that matched the prefix.

This change would at least help the administrator a little.

# semanage fcontext -a -t httpd_sys_script_t "///cgi-bin/.*\.cgi"
ValueError: Type httpd_sys_script_t is invalid, must be a file or device type.
Alternative: httpd_sys_script_exec_t.

Another example.

# semanage fcontext -a -t apcupsd_t /etc/dan
ValueError: Type apcupsd_t is invalid, must be a file or device type.
Alternatives: apcupsd_var_run_t, apcupsd_initrc_exec_t, apcupsd_log_t, apcupsd_exec_t, apcupsd_lock_t, apcupsd_unit_file_t, apcupsd_tmp_t.

One problem with this change would be Apache (httpd_t), which comes out with 146 matches. :^(

The new semanage will show up in Rawhide and will be back ported to RHEL7 and Fedora 20.

The seinfo command from the setools-cmdline package can list all file types on a system using the file_type attribute and all process types using the domain attribute.

> seinfo -afile_type -x | wc -l
2603

> seinfo -adomain -x | wc -l
743

File System Equivalance

The administrator could have made a better labeling decision by using file equivalence labeling.

# semanage fcontext -a -e /var/www "/<pathtowebsite>/<website>"

Which would have told SELinux to label everything under "/<pathtowebsite>/<website>" as if it was under /var/www

Dan Walsh: Difference between a Confined User (staff_u) and a Confined Administrator.

dwalsh@redhat.com — Fri, 18 Oct 2013 14:05:32 +0000

Confined users have been around for a while, and several people have used them. I use the staff_u user for my logins.

staff_u:staff_r:staff_t:s0-s0:c0.c1023

One common mistake people make when they use confined users is they expect them to work when running as root.

Which of course the don't!!! They are CONFINED.

The idea of a confined user is to control the access is available to a logged in user. If the user needs to do administrative tasks as root, he needs to become a Confined Administrator.

This means if you are logged in as a confined user SELinux will prevent you from running most programs that will make you root including "su".

In SELinux we have the concept of a process transition. When we use confined users we like to transition the Confined User process to a Confined Administrator when the process needs to run as root. Another way to look at this is Roles Based Access Control (RBAC). Which means that when I log into a machine I have one Role, but if I want to administrate the machine I need to switch to a different Role.

In SELinux we currently have two different ways to change Roles, or to switch from a Confined User to a Confined Administrator.

newrole - This command can be executed by a user and will request to the SELinux Kernel to change its role, if allowed by policy. The problem with this tool is you still need to change to root, via su or sudo.

sudo - We allow you to change both your SELinux Role/Type in sudo as well as become root.

In my case I run my login as staff_u:staff_r:staff_t:s0-s0:c0.c1023, and when I execute a command through sudo, sudo transitions my process to staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023. If you want to run with a slightly confined administrator you could setup a transition to staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023, which I like to call the drunken unconfined_t, it can do everything unconfined_t can do, but stumbles around alot.

We also have a few other confined administrators like:

webadm_t, which can only administrate apache types.

dbadm_t which can administrate types associated with mysql and postgresql.

logadm_t which can administrate types associated with syslog and auditlog

secadm_t which can only administrate SELinux controls

auditadm_t which can only administrate the audit subsystem.

It is fairly easy to add additional confined administrator types using sepolicy/sepolgen.

To configure an Confined User/Confined Administrator pair, you need to do a few steps.

Note: You could skip the first two steps and just use staff_u

Step 1: Create a Brand New SELinux User Definition confined_u

# semanage user -a -r s0-s0:c0.c1023 -R "staff_r unconfined_r webadm_r sysadm_r system_r" confined_u

Note: I added roles staff_r which will be the role of the confined user when he logs in. The other roles are potential roles that the user will use when he is an administrator. Only one of these roles is required "unconfined_r webadm_r sysadm_r " but I added them all to give you options. system_r is in there to allow you to restart system services. You would not need this on a systemd system, or if you were going to user run_init. But if you want to just use "service restart foobar" on a system V system like RHEL6 you need to have this role.

Step 2: We need to setup the default context file to tell programs like sshd or xdm which one of the roles/types we would like to use by default. We are simply going to copy the staff_u context file. You could also use IPA to override this selection.

# cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/confined_u

Step 3: Now we want to configure our Linux Account to use the SELinux User
# semanage login -a -s confined_u -rs0:c0.c1023 dwalsh

Note: In stead of using a user name you could use a linux group like wheel, by specifying %wheel. Also if you want to modify the default for all users that are not specified you could use the name __default__.

Step 4: Now you need to configure sudo to transition your Confined User process to a Confined Administrator
You can either modify the /etc/sudoers file with a line like the following.

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

Or add a file to /etc/sudoers.d

echo "dwalsh ALL=(ALL) TYPE=webadm_t ROLE=webadm_r /bin/sh " > /etc/sudoers.d/dwalsh

It would not hurt to relabel your homedir at this point.

# restorecon -R -v /home/dwalsh

Now if you were already logged in as you user account, you were probably running processes as unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023, so you might want to reboot to make sure everything is cleaned up.

After reboot, when you login you should see your processes running as

> id -Z
confined_u:staff_r:staff_t:s0-s0:c0.c1023

Now you should not be allowed to run the su command (unless you newrole to an admin role), but if you execute

> sudo -i
# id -Z
confined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Dan Walsh: Setroubleshoot does a nice job nowadays but do people read it?

dwalsh@redhat.com — Sat, 07 Sep 2013 10:58:05 +0000

<whine>
Frustrating:
Getting a bugzillas with an setroubleshoot alert mesage that tells the user user exactly 
what the problem and solution is, and yet the user goes through the GUI looking for the 
Report the Bug button.  

I call this the Bug Dan Walsh Button, although I guess I could call it the Bug Miroslav Grepl 
Button now. 

Then the user waits for a response from a human saying to say 

"Did you read the alert?  It told you what to do." Bugzilla Closed NotABug

All the time the user sits with a broken tool or in permissive mode, when the user could 
have fixed the problem in seconds.  Lots of bugzillas say, XYZ is mislabeled just run restorecon XYZ  :^(

</whine>

Setroubleshoot did a great job of diagnosing this problem.  

It gave the user two good solutions, and one fall back.

Bottom Line, Please read the alert information before reporting a bugzilla.

Of course the tooling in NetworkManager should have done this automatically, but we have a 
bugzilla open for that.

Description of problem:
Upon trying to activate the VPN interface, I received the pop-up advising me that it was blocked. 
SELinux is preventing /usr/sbin/openvpn from 'open' accesses on the file /home/dwalsh/personalVPN/CN00318823.crt.

*****  Plugin openvpn (47.5 confidence) suggests  ****************************

If you want to mv CN00318823.crt to standard location so that openvpn can have open access
Then you must move the cert file to the ~/.cert directory
Do
# mv /home/dwalsh/personalVPN/CN00318823.crt ~/.cert
# restorecon -R -v ~/.cert


*****  Plugin openvpn (47.5 confidence) suggests  ****************************

If you want to modify the label on CN00318823.crt so that openvpn can have open access on it
Then you must fix the labels.
Do
# semanage fcontext -a -t home_cert_t /home/dwalsh/personalVPN/CN00318823.crt
# restorecon -R -v /home/dwalsh/personalVPN/CN00318823.crt


*****  Plugin catchall (6.38 confidence) suggests  ***************************

If you believe that openvpn should be allowed open access on the CN00318823.crt file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep openvpn /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:openvpn_t:s0
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                /home/dwalsh/personalVPN/CN00318823.crt [ file ]
Source                        openvpn
Source Path                   /usr/sbin/openvpn
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           openvpn-2.3.2-1.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-73.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.10.10-200.fc19.x86_64 #1 SMP Thu
                              Aug 29 19:05:45 UTC 2013 x86_64 x86_64
Alert Count                   2
First Seen                    2013-09-03 16:46:59 EDT
Last Seen                     2013-09-05 17:57:28 EDT
Local ID                      f008846c-ad32-4676-925c-4a86a1b87a2b

Raw Audit Messages
type=AVC msg=audit(1378418248.924:702): avc:  denied  { open } for  pid=1996 comm="openvpn" path="/home/dwalsh/personalVPN/CN00318823.crt" dev="dm-2" ino=11141302 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file


type=SYSCALL msg=audit(1378418248.924:702): arch=x86_64 syscall=open success=no exit=EACCES a0=7fffcf992f0e a1=0 a2=1b6 a3=7fffcf990410 items=0 ppid=1992 pid=1996 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=openvpn exe=/usr/sbin/openvpn subj=system_u:system_r:openvpn_t:s0 key=(null)

Hash: openvpn,openvpn_t,user_home_t,file,open

KaiGai Kohei: Custom Executor 試作版

kaigai — Sat, 31 Aug 2013 15:07:50 +0000

現状、PostgreSQLのエグゼキュータを拡張するにはいくつか方法が考えられる。

Executor(Start|Run|End)_hookを使う
- エグゼキュータ全体を乗っ取る。逆に言えば、一部の処理（例えば集約演算）だけを俺様実装にしたい時には、本体側のコードをコピーするなりしないとダメ。
Foreign Data Wrapperを使う
- 特定のテーブルスキャンに限定すればアリ。しかし、集約演算やJOIN、ソートといった処理を俺様実装にする用途には使用できない。
ブランチして俺様パッチを当てる
- まぁ、これならどうにでもできますがね…。

しかし、あまり使い勝手がよろしくない。
例えば、GPUを使って集約演算を1000倍早くしたいと考えても、それを実装するために、モジュール側でエグゼキュータ全体のお守りをしなければならないというのは、全く嬉しくない。
という訳で、プラン木の一部を差し替えて、特定のエグゼキュータ・ノードだけをモジュール側で実装したコードで実行できるよう機能拡張にトライしてみた。名称は Custom Executor Node で、名付け主はRobert Haasなり。

イメージとしては以下の通り。

planner_hookを利用して、PostgreSQLのプラナーがPlannedStmtを作成した"後"でモジュールがプラン木の一部を書き換え、CustomExecノードを追加する、あるいはCustomExecノードで既存のエグゼキュータ・ノードを差し替える。

で、クエリ実行の開始、一行取り出し、クエリ実行の終了時にそれぞれモジュール側で実装されたコードが呼び出されるというワケだ。

APIは以下の通り。機能的に似ているのでFDWのAPIに似ておる。

void BeginCustomExec(CustomExecState *cestate, int eflags);
TupleTableSlot *GetNextCustomExec(CustomExecState *node);
void ReScanCustomExec(CustomExecState *node);
void EndCustomExec(CustomExecState *node);
void ExplainCustomExec(CustomExecState *node, ExplainState *es);

PoCとして、クエリ実行に要した時間を出力する xtime という拡張を自作してみた。
Custom Executorとして本体からコールバックを受けるには、予め自分自身を登録しておく必要がある。これがRegisterCustomExec()関数で、ここでは一連のコールバックの組に対して"xtime"という名前を付けている。

void
_PG_init(void)
{
    CustomExecRoutine   routine;
        :
    /*
     * Registration of custom executor provider
     */
    strcpy(routine.CustomExecName, "xtime");
    routine.BeginCustomExec   = xtime_begin;
    routine.GetNextCustomExec = xtime_getnext;
    routine.ReScanCustomExec  = xtime_rescan;
    routine.EndCustomExec     = xtime_end;
    routine.ExplainCustomExec = xtime_explain;
    RegisterCustomExec(&routine);
        :
}

そして、プラン木に"xtime"のCustomExecノードを挿入するのがplanner_hookでの処理。標準のプラナーが生成したPlannedStmtに手を加えてCustomExecノードを追加する。（ここでは再帰的にプラン木を捜査して、各ノードの頭にCustomExecノードを追加している）

static PlannedStmt *
xtime_planner(Query *parse,
              int cursorOptions,
              ParamListInfo boundParams)
{
    PlannedStmt *result;

    if (original_planner_hook)
        result = original_planner_hook(parse, cursorOptions,
                                       boundParams);
    else
        result = standard_planner(parse, cursorOptions,
                                  boundParams);

    /* walk on underlying plan tree to inject custom-exec node */
    result->planTree = xtime_subplan_walker(result->planTree, 0);

    return result;
}

これによって、クエリ実行計画はどのように修正されるのか。
例えば以下のようなクエリを実行するとする。

postgres=# EXPLAIN (costs off)
           SELECT * FROM t1 JOIN t2 ON t1.a = t2.x
                    WHERE a < 5000 LIMIT 100;
                    QUERY PLAN
--------------------------------------------------
 Limit
   ->  Hash Join
         Hash Cond: (t2.x = t1.a)
         ->  Seq Scan on t2
         ->  Hash
               ->  Index Scan using t1_pkey on t1
                     Index Cond: (a < 5000)
(7 rows)

これが、xtimeモジュールにより以下のように書き換えられる。

postgres=# LOAD '$libdir/xtime';
LOAD
postgres=# EXPLAIN (costs off)
           SELECT * FROM t1 JOIN t2 ON t1.a = t2.x
                    WHERE a < 5000 LIMIT 100;
                             QUERY PLAN
--------------------------------------------------------------------
 CustomExec:xtime
   ->  Limit
         ->  CustomExec:xtime
               ->  Hash Join
                     Hash Cond: (x = t1.a)
                     ->  CustomExec:xtime on t2
                     ->  Hash
                           ->  CustomExec:xtime
                                 ->  Index Scan using t1_pkey on t1
                                       Index Cond: (a < 5000)
(10 rows)

数ヶ所にCustomExecノードが挿入されている。t2へのSeqScanが消えているのは、SeqScanの場合にはxtimeモジュールが自力でテーブルをスキャンするため（コードサンプルとして使う事を想定しているので）。

で、このクエリを実行すると以下のように表示される。CustomExecノードをプラン木の間に挟み込み、下位ノードの実行に要した時間を記録しているのである。

postgres=# \timing
Timing is on.
postgres=# SELECT * FROM t1 JOIN t2 ON t1.a = t2.x WHERE a < 5000 LIMIT 100;
INFO:  execution time of Limit:  9.517 ms
INFO:   execution time of Hash Join:  9.487 ms
INFO:    execution time of CustomExec:xtime on t2:  0.047 ms
INFO:     execution time of Index Scan on t1:  4.947 ms
        ：
     （省略）
        ：
Time: 12.935 ms

ひとまず、CommitFest:Sepまでにちゃんと提案できるブツを作れてよかった。
あとはドキュメントとソースコードコメントをちゃんと書いて投稿である。

Dan Walsh: New MLS videos at access.redhat.com

dwalsh@redhat.com — Thu, 29 Aug 2013 13:30:21 +0000

We no how much you like SELinux!!!

Well if you really want to turn up the enjoyment, why not try Multi Level Security (MLS) policy?

Well you probably only want to do this if you need to store data on a machine that is truly multi level.

MLS Policy (selinux-policy-mls)

We have been shipping MLS policy since RHEL5, and Fedora 6.

RHEL5 and RHEL6 have achieved a government certification of EAL4+/LSPP. This certification basically says that these Operating Systems are able to store and handle data that has different Security levels, like Top Secret/Secret/Unclassified. It is the same certification that Trusted Solaris achieved. Bottom line is the Defense Organisations are using SELinux MLS on RHEL5 and RHEL6 in the most sensitive places. If you are an administrator of these types of machines, you need to see some new videos on access.redhat.com.

Dave Egts is at it again.

I absolutely loved Dave's videos on confined users. Whenever I teach SELinux Roles Based Access Control (RBAC), I show the videos.

They are Must See TV

Dave does a great job of explaining complex technology in short easy to consume videos.

Now Dave and the folks who build the content on access.redhat.com have put together 8 MLS Videos.

Multilevel Security with Red Hat Enterprise Linux and SELinux

Check it out.

KaiGai Kohei: 単体型GPUへのDMA転送コストを考える

kaigai — Sun, 25 Aug 2013 10:09:08 +0000

PostgreSQLの検索処理（特にスキャン周り）をGPUにオフロードするにあたって、できるだけCPU処理の負荷を軽減したい。というのも、PostgreSQLは基本シングルスレッドなので、GPUがバリバリ並列計算しようとしてもデバイスへのデータ供給が追い付かなければ計算機を遊ばせてしまう事になる。

大雑把に言うと、PG-Stromは以下のような構造を持ち、PostgreSQLバックエンドがデータベースファイルから読み込んだデータを、共有メモリを介してOpenCL Serverが見える所に置いてあげる。OpenCL ServerはデータをDMA転送してGPU Kernel関数を起動、計算結果をまたPostgreSQLバックエンドに戻してやる。

もう少し細かく仕事を分割すると、以下の通り。

ストレージからデータをロード（共有バッファに載ってなければ）
共有バッファからタプルを取り出す。この時、Snapshotとの比較でタプルの可視不可視チェックも。
タプルを展開し、長大な配列としてデータを並べ替える。元々カラム指向なデータ構造で持っているので、配列への展開は"すごく重い"という訳ではない。
DMA転送でこの配列をGPUデバイスへコピー。
転送されたデータを使って、GPU側で計算を実行。

現状の実装だと、(1)～(3)までがPostgreSQLバックエンドの仕事、(4)がOpenCL Serverで、(5)がGPUデバイスとなる。

ただ、これだとCPU側での処理がかさんでしまうので、理想としては以下のようにPostgreSQLの共有バッファから直接GPUデバイスにDMA転送、そこでタプルからのデータ取り出しを行えれば、CPU負荷は下がる事になる。

しかし、問題が２つ。

タプルの可視性判定はIFブロックの鬼なのでGPUで実行したくない。その上、不可視なタプルをGPUに転送するコストは完全に無駄
PostgreSQLの共有バッファのブロック長は8KB（設定により最大32KB）なので、細切れのDMAを大量に発行する必要が出てくる。

後者に関しては、簡単に性能を計測できるのでやってみた。

128MBのブロックを1回のDMAで転送した場合。理論上、これが最も性能の出るパターン。

[kaigai@iwashi gpuinfo]$ ./gpudma -m async
DMA send/recv test result
device:         GeForce GT 640
size:           128MB
chunks:         128MB x 1
ntrials:        100
total_size:     12800MB
time:           4.18s
speed:          3063.97MB/s
mode:           async

一方、128MBのブロックを8KBx16384個のチャンクに分けて転送した場合だと、転送性能は1/3程度に。うーん、これはちょっとヨロシクナイ…。

[kaigai@iwashi gpuinfo]$ ./gpudma -m async -c 8
DMA send/recv test result
device:         GeForce GT 640
size:           128MB
chunks:         8KB x 16384
ntrials:        100
total_size:     12800MB
time:           12.36s
speed:          1035.97MB/s
mode:           async

当然、ブロック長が長くなればなるほどDMA発行の手間が減るので性能的には有利。PostgreSQLのコンフィグで変更可能な32KB相当のDMA単位にすると、本来の性能の85%程度は出てくれる。それでも結構痛いが。

[kaigai@iwashi gpuinfo]$ ./gpudma -m async -c 32
DMA send/recv test result
device:         GeForce GT 640
size:           128MB
chunks:         32KB x 4096
ntrials:        100
total_size:     12800MB
time:           5.06s
speed:          2531.70MB/s
mode:           async

なかなか悩ましいところではあるが、8KBのチャンクを直接GPUにDMA転送するコストの高さを考えれば、CPU側である程度まとまった大きさに集約してからガツンとDMAを発行した方が効率はよさそう。その一方で、シングルスレッドのPostgreSQLバックエンドを酷使するのも考え物なので、ベストミックスとしては、マルチスレッドで動作可能なOpenCL Serverにタプルの取り出しとDMAバッファへの展開を行わせても良さそう。
あと、現状ではDMAバッファへの展開時に圧縮データの展開を行っているけども、CPUの処理負荷を下げるだけでなく、PCI-Eの帯域を節約するという観点からも、GPU側で圧縮データの伸長を行った方が良いのかもしれない。

Dan Walsh: What would happen if an OpenShift gear became root?

dwalsh@redhat.com — Mon, 05 Aug 2013 20:18:50 +0000

Here is a video I put together for the Red Hat Summit.

The video shows how SELinux would control an openshift gear if it somehow it got a privilege escalation and actually became root.

Dan Walsh: New Security Feature in Fedora 20 Part 1: Setroubleshoot - Journald integration

dwalsh@redhat.com — Fri, 02 Aug 2013 12:54:06 +0000

A little early to start this series, but I am pretty excited about all the new features coming in Fedora 20.

A while ago a fellow worker Máirín Duffy was very proud of herself for figuring out an SELinux issue. Basically she had a problem that is fairly common struggle people have with SELinux. She had created some content for her web server in her home directory, and then mv'd it into a /var/www subdir and tried to look at it in here web browser and got a screen like the following.

When she went to look at the /var/log/httpd/error_log, she saw something like:

# tail /var/log/httpd/error_log
[Fri Aug 02 08:05:43.347080 2013] [core:error] [pid 10556] (13)Permission denied: [client ::1:38045] AH00132: file permissions deny server access: /var/www/html/index.html

Instead of thinking there was a problem with Ownership or Permission flags, she thought of SELinux and figured their might be problem with the labels, so she ran:

# restorecon -R -v /var/www
restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0

Well if she had continued to investigate she would have seen the following in other logs.

In the /var/log/audit/audit.log the kernel had reported an AVC message like the following.

# ausearch -m avc -ts recent -i
type=PATH msg=audit(08/02/2013 08:05:43.346:1197) : item=0 name=/var/www/html/index.html inode=3145858 dev=08:03 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_home_t:s0
type=CWD msg=audit(08/02/2013 08:05:43.346:1197) : cwd=/
type=SYSCALL msg=audit(08/02/2013 08:05:43.346:1197) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x7f476595da40 a1=O_RDONLY|O_CLOEXEC a2=0x0 a3=0x7fffe27e11b0 items=1 ppid=10552 pid=10556 auid=unset uid=apache gid=apache euid=apache suid=apache fsuid=apache egid=apache sgid=apache fsgid=apache ses=unset tty=(none) comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(08/02/2013 08:05:43.346:1197) : avc: denied { read } for pid=10556 comm=httpd name=index.html dev="sda3" ino=3145858 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

SETroubleshoot received this message and reported in /var/log/messages.

# grep setroubleshoot /var/log/messages
Aug 2 08:01:46 redsox setroubleshoot: SELinux is preventing /usr/sbin/httpd from read access on the file /var/www/html/index.html. For complete SELinux messages. run sealert -l fd6b9022-1ced-4065-905a-8f0e884f9915

If she finally ran this sealert command specified in the log file she would have found setroubleshoot had written its analysis in /var/lib/setroubleshoot/setroubleshoot_database.xml

# sealert -l fd6b9022-1ced-4065-905a-8f0e884f9915

SELinux is preventing /usr/sbin/httpd from read access on the file /var/www/html/index.html.

***** Plugin restorecon (92.2 confidence) suggests *************************

If you want to fix the label.
/var/www/html/index.html default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/index.html
...

Nice that Máirín figured out her problem so quickly, but as you see the system had scattered little clues all over the system to help her. And who says SELinux is not easy.

Ok Dan get to the point?

If you have been following the Fedora-devel list their has been a large discussion going on about whether or not to enable syslog (rsyslog) in the default install. The idea is to consolidate logging into journald which I talked about in a previous blog. And get log analysis tools to start relying on its data rather then scanning /var/log/messages.

SETroubleshot integration with journald.

Back in Fedora 18 or 19 we started dumping setroubleshoot data into the journal. The problem with this data is that it was setroubleshoot reporting on the httpd process, but there was no way for journald/systemd to know this. I asked the journald team to add a mechanism for a privileged application to specify a Process ID (PID) to which the log message pertained. Well systemd/journald has added this in systemd-206-1. I added the functionality to setroubleshoot-3.2.11-1.fc20.x86_64

Now if Máirín had simply checked the status of the httpd service, she would see a message like:

# systemctl status httpd
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
   Active: active (running) since Fri 2013-08-02 08:01:35 EDT; 30min ago
Main PID: 10552 (httpd)
   Status: "Total requests: 4; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service
           ├─10552 /usr/sbin/httpd -DFOREGROUND
           ├─10553 /usr/libexec/nss_pcache 196611 off /etc/httpd/alias
           ├─10554 /usr/sbin/httpd -DFOREGROUND
           ├─10555 /usr/sbin/httpd -DFOREGROUND
           ├─10556 /usr/sbin/httpd -DFOREGROUND
           ├─10557 /usr/sbin/httpd -DFOREGROUND
           ├─10558 /usr/sbin/httpd -DFOREGROUND
           └─10569 /usr/sbin/httpd -DFOREGROUND

Aug 02 08:01:35 redsox.boston.devel.redhat.com systemd[1]: Started The Apache HTTP Server.
Aug 02 08:01:46 redsox.boston.devel.redhat.com python[10564]: SELinux is preventing /usr/sbin/httpd from read access on the file /va...html.

                                                              ***** Plugin restorecon (

Then if she used the journalctl command she could see the full analysis.

# journalctl -r -o verbose -u httpd.service

-- Logs begin at Tue 2013-04-09 15:19:05 EDT, end at Fri 2013-08-02 08:32:35 EDT. --
Fri 2013-08-02 08:05:45 EDT [s=3087834a63d74580811c9e1088ac7fdf;i=1195d;b=71667fa0d7074a3f8bdf1c0da22fe234;m=22b877728;t=4e2f5c7552cb6;x=908
    _UID=0
    _GID=0
    _BOOT_ID=71667fa0d7074a3f8bdf1c0da22fe234
    _MACHINE_ID=8835be49c83449d3b4581853df82eafa
    _HOSTNAME=redsox.boston.devel.redhat.com
    _TRANSPORT=journal
    _CAP_EFFECTIVE=3fffffffff
    _SYSTEMD_CGROUP=/system.slice/dbus.service
    _SYSTEMD_UNIT=dbus.service
    _EXE=/usr/bin/python2.7
    _COMM=setroubleshootd
    _CMDLINE=/usr/bin/python -Es /usr/sbin/setroubleshootd -f
    _SELINUX_CONTEXT=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023
    MESSAGE=SELinux is preventing /usr/sbin/httpd from read access on the file /var/www/html/index.html.

            ***** Plugin restorecon (92.2 confidence) suggests *************************

            If you want to fix the label.
            /var/www/html/index.html default label should be httpd_sys_content_t.
            Then you can run restorecon.
            Do
            # /sbin/restorecon -v /var/www/html/index.html

            ***** Plugin catchall_boolean (7.83 confidence) suggests *******************

            If you want to allow httpd to read user content
            Then you must tell SELinux about this by enabling the 'httpd_read_user_content' boolean.
            You can read 'user_selinux' man page for more details.
            Do
            setsebool -P httpd_read_user_content 1

            ***** Plugin catchall (1.41 confidence) suggests ***************************

            If you believe that httpd should be allowed read access on the index.html file by default.
            Then you should report this as a bug.
            You can generate a local policy module to allow this access.
            Do
            allow this access for now by executing:
            # grep httpd /var/log/audit/audit.log | audit2allow -M mypol
            # semodule -i mypol.pp

    CODE_FILE=/usr/lib64/python2.7/site-packages/setroubleshoot/server.py
    CODE_LINE=196
    CODE_FUNC=report_problem
    SYSLOG_IDENTIFIER=python
    OBJECT_UID=48
    OBJECT_GID=48
    OBJECT_COMM=httpd
    OBJECT_EXE=/usr/sbin/httpd

Pretty cool!

All of the information is now consolidated into a single tool chain, and if administrators start using systemct status foobar, they will get important SELinux information in the main log, making SELinux easier to use and thus getting more people to keep it enabled.

BTW, this feature will be in Red Hat Enterprise 7.

Future:

I hope to work with the systemd/journald team to allow systemctl status to provide extended information, so the entire message could have been shown in that screen, eliminating the need the next step, but this is a huge step forward in usability.

In the coming fedora's I hope to eliminate the setroubleshoot database totally and just use journald as its information database.

And I still want to push the kernel team forward on the Friendly EPERM.

James Morris: Linux Security Summit 2013 – Schedule Published!

jamesm — Fri, 02 Aug 2013 06:15:51 +0000

The schedule for this year’s Linux Security Summit in New Orleans is now published!

The keynote will be presented by Ted Ts’o.

Refereed talks include:

Embedded Linux Security (David Safford, IBM)
Extending AppArmor Mediation into the Userspace (John Johansen, Canonical)
Multiple Concurrent Security Models? Really? (Casey Schaufler, Intel)
Linux Kernel ASLR (Kees Cook, Google)
The AppArmor Labeling Model (John Johansen, Canonical)

It looks like there’s been quite a lot happening in AppArmor. There’ll also be general project updates for SELinux, Smack, AppArmor and the Integrity subsystem, as well as a discussion on kernel coding anti-patterns led by Kees Cook.

There’ll be break-out sessions on the second day, details of which will be posted on the schedule as they’re known. If you’ll be at LSS (or LinuxCon/Plumbers generally) and would like to schedule a break-out session, contact the program committee per the details at the wiki page.

See everyone on the 19th and 20th of September in New Orleans!

Russell Coker (security): Security is Impossible

etbe — Tue, 23 Jul 2013 04:34:01 +0000

The Scope of the Problem

Security is inherently complex because of the large number of ways of circumventing it. For example Internet facing servers have been successfully attacked based on vulnerabilities in the OS, the server application, public key generation, DNS, SSL key certificates (and many other programs and algorithms in use), as well as the infrastructure and employees of all companies in the chain. When all those layers work reasonably well (not perfectly but well enough to not obviously be the weakest link) there are attacks on the end user systems that access the servers (such as the trojan horse programs used to attack PCs used for online banking).

My Area of Interest

The area of security that interests me is Linux software development. There are many related areas such as documentation and default configurations to make it easier for people to secure their systems (instead of insecure systems being the default option) which are all important.

There are also many related fields such as ensuring that all people with relevant access are trustworthy. There are many interesting problems to solve in such areas most of which aren’t a good match for my skills or just require more time than I have available.

I sometimes write blog posts commenting on random security problems in other areas. Sometimes I hope to inspire people to new research, sometimes I hope to just inform users who can consider the issues when implementing solutions to security problems.

Bugs

In the software development side there are ongoing problems of bugs in code that weaken security. The fact that the main area of concern for people who are interested in securing systems is fixing bugs is an indication that the problem of software quality needs a lot of work at the moment.

The other area that gets a reasonable amount of obvious work is in access control. Again it’s an area that needs a lot of work, but the fact that we’re not done with that is an indication of how far there is to go in generally improving computer security.

Authenticating Software Releases

There have been cases where source code repositories have been compromised to introduce trojan horse code, the ones I’ve read about have been discovered reasonably quickly with little harm done – but there could be some which weren’t discovered. Of course it’s likely that such attacks will be discovered because someone will have the original and the copies can be compared.

Repositories of binaries are a bigger problem, it’s not always possible to recompile a program and get a binary which checks out as being identical (larger programs often include the build time in the binary). Even for build processes which don’t include such data it can be very difficult to determine the integrity of a build process. For example programs compiled with different versions of libraries, header files, or compilers will usually differ slightly.

As most developers frequently change the versions of such software they will often be unable to verify their own binaries and any automated verification of such binaries will be impossible for anyone else. So if a developer’s workstation was compromised without their knowledge it might be impossible for them to later check whether they released trojan binaries – without just running the binaries in question and looking for undesired behavior.

The problem of verifying past binaries is solvable for large software companies, Linux distributions, and all other organisations that have the resources to keep old versions of all binaries and libraries used to build software. For proprietary software companies the verification process would have to start with faith in the vendor of their OS and compiler doing the right thing. For Linux distributions and other organisations based on free software it would start by having the source to everything which can then be verified in theory – although in practice verifying all source for compilers, the OS, and libraries would be a huge undertaking.

Espionage

There is a well documented history of military espionage, people who are sworn to secrecy have been subverted by money, blackmail, and by having political beliefs which don’t agree with their government. The history of corporate espionage is less well documented but as corporations perform less stringent background checks than military organisations I think it’s safe to assume that corporate espionage is much more common.

Presumably any government organisation that can have any success at subverting employees of a foreign government can be much more successful in subverting programmers (either in companies such as Microsoft or in the FOSS community). One factor that makes it easier to launch such attacks is the global nature of software development. Government jobs that involve access to secret data have requirements about where the applicant was born and has lived, corporate jobs and volunteer positions in free software development don’t have such requirements.

The effort involved in subverting an existing employee of a software company or contributor to free software or the effort involved in getting an agent accepted in such a project would be quite small when compared to a nuclear weapons program. Therefore I think we should assume that every country which is capable of developing nuclear weapons (even North Korea) can do such things if they wish.

Would the government of such a country want to subvert a major software project that is used by hundreds of millions of people? I can imagine ways that such things could benefit a government and while there would be costs for such actions (both in local politics and international relations) it seems most likely that some governments would consider it to be worth the risk – and North Korea doesn’t seem to have much to lose.

Conclusion

We would like every computer to be like a castle with a strong wall separating them from the bad things which can’t be breached in ways that aren’t obvious. But the way things are progressing with increasingly complex systems depending on more people and other systems it’s becoming more like biology than engineering. We can think of important government systems as being comparable to the way people with compromised immune systems are isolated from any risk of catching a disease, the consequences of an infection are worse so greater isolation measures are required.

For regular desktop PCs getting infected by a trojan is often regarded as being similar to getting a cold in winter. People just accept that their PC will be infected on occasion and don’t bother making any serious effort to prevent it. After an infection is discovered the user (or their management for a corporate PC) tend not to be particularly worried about data loss in spite of some high profile data leaks from companies that do security work and the ongoing attacks against online banking and webcam spying on home PCs. I don’t know what it will take for users to start taking security risks seriously.

I think that a secure boot is a good step in the right direction, but it’s a long way from being able to magically solve all security problems. I’ve previously described some of the ways that secure boot won’t save you [1].

The problems of subverting developers don’t seem to be an immediate concern (although we should consider the possibility that it might be happening already without anyone noticing). The ongoing trend is that the value of computers in society is steadily increasing which therefore increases the rewards for criminals and spy agencies who can compromise them. Therefore it seems that we will definitely face the problems of subverted developers if we can adequately address the current technical problems related to flaws in software and inadequate access control. We just need to fix some of the problems which are exploited more easily to force the attackers to use the more difficult and expensive attacks. Note that it is a really good thing to make attacks more difficult, that decreases the number of organisations that are capable of attack even though it won’t stop determined attackers.

For end user systems the major problem seems to be related to running random programs from the Internet without a security model that adequately protects the system. Both Android and iOS make good efforts at protecting a system in the face of random hostile applications, but they have both been shown to fail in practice (it might be a good idea to have a phone for games that is separate from the phone used for phone calls etc). More research into OS security is needed to address this. But in the mean time users need to refrain from playing games and viewing porn on systems that are used for work, Internet banking, and other important things. While PCs are small and cheap enough that having separate PCs for important and unimportant tasks is practical it seems that most users don’t regard the problems as being serious enough to be worth the effort.

[1] http://etbe.coker.com.au/2011/12/28/secure-boot-protecting-against-root/

Joshua Brindle: SE for Android on the GS4 Google Play Edition

Mon, 08 Jul 2013 05:00:00 +0000

GS4 Google Play Edition != Nexus

Caveat: Everything here is based on the leaked images floating around and are not necessarilly represenative of what the final, released version will look like. That said, it is probably partially useful and my curiousity got the best of me...

As you probably know by now the GS4 Google Play Edition is not a Nexus device. It does not get updates from Google and does not have only Google provided code. It was developed by Samsung but removes all of the TouchWiz features. However, it is an updated version of Android (4.3) and has some things that the standard GS4 does not.

Since the standard GS4 SE for Android controls are Samsung-specific, and deeply embedded in the Knox libraries Google had to provide something else.

Rather than using the management system proposed by the SE for Android community they invented another, third, system.

It is a good bet that the interfaces I'll talk about here will show up in AOSP when 4.3 is released so getting a head start can't be a bad idea

State of SE for Android on the GS4 GPE

As you can see in screenshots released SELinux is present and set to permissive in the Settings app. The policy looks very similar to that of the standard GS4, including components that have been removed from this version:

$ cat seapp_contexts | grep samsung
user=_app seinfo=samsung domain=samsung_app type=app_data_file
user=_app seinfo=samsung name=com.sec.android.app.samsungapps domain=samsung_app type=app_data_file
user=_app seinfo=untrusted name=com.vlingo.midas domain=samsung_app type=app_data_file
user=_app seinfo=untrusted name=tv.peel.samsung.app domain=samsung_app type=app_data_file
user=_app seinfo=untrusted name=tv.peel.samsung.widget domain=samsung_app type=app_data_file

So, since this is basically the same policy hopefully enforcing mode will work fine, as it does on the standard version:

# setenforce 1

Oh! The screen froze, I can't hit any buttons or even get back to home.

# setenforce 0

Doesn't fix it! Well... obviously this policy needs some work. Too bad the AVC messages are still removed from the kernel messages and no auditing is present... sigh

Let's move on to the management API.

Managing SE for Android on the GS4 GPE

As I already said, the Knox components have been removed so the previous client I posted won't work. Looking at the code there is a new interface. It is in the services framework and is triggered by an Intent:

Intent i = new Intent("android.intent.action.UPDATE_SEPOLICY");
i.putExtra("CONTENT_PATH", bundle_file_path);
i.putExtra("REQUIRED_HASH", "NONE");
i.putExtra("SIGNATURE", "...");
i.putExtra("VERSION", "1");

The Intent can be triggered from anywhere, so a third party app can call it, a separate permission is not even required. The REQUIRED_HASH you see above short circuits the check against the previous policy and the VERSION must be higher than the last update (though can be 1 the first time you call it). The signature is the sticking point. The bundle (I'll get to that in a bit) has to be signed by the update certificate. The update certificate is stored in the Settings provider, though, and with root we can update that (you need to add sqlite3 to your system partition to do this):

# cd /data/data/com.android.providers.settings/databases
# sqlite3 settings.db "INSERT into secure (name, value) VALUES('config_update_certificate','<your public DER cert>');"

Once you've done that can you sign the bundle, put it on the system where services can read it (/cache works well) and call the intent. Viola.

Except not. After getting this to succeed (the certificate and signing stuff in here is really finicky) the policy was placed in /data/security/contexts with 'current' symlinked to it.. Strangely, none of the rest of the code appears to look there. Indeed the policy doesn't appear to be loaded either when the Intent is called or at boot time. Doh!

Since this doesn't currently work I didn't see much value in posting code. I'll keep it up to date and when I get a real released version I'll post it if it works (or maybe if it doesn't)

Enforcing mode is set with a global setting (selinux_status), and appears to be persistent, but since enforcing does not work it is not a good idea to set it.

The Bundle

So, Google made a new file format for bundling components of the policy, seapp_contexts, property_contexts, file_contexts, and the binary policy, in that order. Sadly mac_permissions.xml is not in the bundle, nor does there appear any way to update it.

The bundle is simple, 4 32-bit (big endian!) integers representing the size of the policy component and then the components, base64 encoded.

The Signature

The signature isn't a standard openssl signature but it can be created in Java, using the standard API's:

Signature signer = Signature.getInstance("SHA512withRSA");
signer.initSign(privKey);
signer.update(bundle);
signer.update(Long.toString(version).getBytes());
signer.update(prevHash.getBytes());
byte [] signature = signer.sign();

You'll note that the signature includes the hash of the bundle itself, and also the version number and hash sent in the intent. This is likely to prevent downgrading by sending the intent with a lower version and different hash.

Conclusion

So, my high hopes were dashed (I didn't really have high hopes... I've learned to have low expectations for these things).

Enforcing mode doesn't work, auditing is still not present, the update API's are non-functional and even if they were functional, they can only be used by the person with the update certificate, which is the vendor. Once again, we have a device that does not allow its owner to protect themselves using mandatory access control, nor change the policy to meet different use cases than the vendor expected. It is very unfortunate that the best technology available for protecting our mobile devices has been locked away from us.

Joshua Brindle: SE for Android GS4 howto and exploit demo

Fri, 28 Jun 2013 05:00:00 +0000

The client

I've uploaded my changes to the SEAdmin client to bitbucket (be sure to check out the samsung-API branch) for brave souls who want to experiment with this. I also have an apk for those who don't want to build their own. This must be installed to the system partition in order to work. It is also crazy hacked together so don't blame me if your phone blows up.

After rooting your phone with something like motochopper put the apk onto /system:

$ adb push SEAndroidAdminActivity.apk /sdcard/
2146 KB/s (758399 bytes in 0.345s)

$ adb shell
shell@android:/ $ su
su
root@android:/ # mount -orw,remount /system
mount -orw,remount /system
root@android:/ # cp /sdcard/SEAndroidAdminActivity.apk /system/app

If it doesn't show up in your app list go ahead and reboot.

root@android:/ # reboot

Run it and enable it as a device administrator by sliding the top slider and hitting activate. It isn't technically a device admin anymore but I didn't disable that code.

After that go to SELinux Administration:

Before you click on enforce it is a good idea to get an adb shell running as system so that you don't have to continually reboot your device:

$ adb shell
shell@android:/ $ su
su
root@android:/ # runcon u:r:system:s0 sh
runcon u:r:system:s0 sh
root@android:/ # id -Z
id -Z
uid=0(root) gid=0(root) context=u:r:system:s0

We are all set, go ahead and click enforce:

It will be checked now, unfortunately if you leave this screen and come back it won't be checked. This is due to the app not having permission to check enforcing status. You can always check whether you are enforcing by going to settings->More->About Device and scrolling to the bottom:

The exploit

Now, lets try to run motochopper on an phone in enforcing:

$ ./run.sh 
<snip>
[*] 
[*] Waiting for device...
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[*] Device found.
[*] Pushing exploit...
4382 KB/s (1283460 bytes in 0.286s)
[*] Pushing root tools...
5119 KB/s (366952 bytes in 0.070s)
4373 KB/s (1867568 bytes in 0.417s)
        pkg: /data/local/tmp/Superuser.apk
Success
4520 KB/s (1578585 bytes in 0.341s)
[*] Rooting phone...
[+] This may take a few minutes.
[-] Failure.
[*] Cleaning up...
[*] Exploit complete. Press enter to reboot and exit.
Press any key to continue . . .

As you can see it failed.

Howto

You can continue running it with the default policy but apps that require root will not work. If you are interested in working on the policy you can use adb to pull it:

$ adb pull /sepolicy
3379 KB/s (134977 bytes in 0.039s)

And then use the policy injector to add rules. Afterward you'll need to reload the policy manually:

$ adb push sepolicy /sdcard/
3138 KB/s (134977 bytes in 0.042s)

Then on your system shell (you did keep a system shell handy, right?)

# cd /data/security
# cp /sdcard/sepolicy .
# setprop selinux.reload_policy 1

The system shell can also toggle enforcing and permissive (I know, that would have been easier than using a client but I wanted to see what real support there was first)

root@android:/ # setenforce 0
setenforce 0
root@android:/ # getenforce
getenforce
Permissive
root@android:/ # setenforce 1
setenforce 1
root@android:/ # getenforce
getenforce
Enforcing

Without denials working on the policy will be quite tedious. Hopefully I'll be able to post a modified kernel soon to turn auditing back on. In the mean time, have fun.

Joshua Brindle: Using SE for Android on the Samsung Galaxy S4

Thu, 27 Jun 2013 05:00:00 +0000

So, you want to secure your Galaxy S4?

After my last blog post I really wanted to get my hands on a Galaxy S4 to see what we could do with it, from an SE for Android perspective. Well, I got one yesterday and the answer is, unfortunately, not a whole lot, but not nothing, either.

First, I wanted to try turning on enforcing from an MDM app without rooting the device. Turns out the APIs for working with SE for Android aren't part of the Samsung MDM API (nor do they have the upstream MDM API present). Instead they are calls to a service that require the calling app to either be signed by the platform certificate or on the system image. Doh.

So now, time to root. I adapted the SEAdmin app from upstream SE for Android to use the Samsung APIs instead and put it on the system image. After some kajiggering I got the app to set enforcing (yay!). Fun fact: you have to set the logging level all the way up for it to work... hrm...

So, now let's set it back to permissive. Oh, there isn't an API for that; can't use JNI either, since the app isn't running as system. Well, I guess that is more secure anyway. Too bad it makes development very difficult.

Speaking of making development very difficult, fun fact #2 is that the audit logs for SELinux are turned off in the kernel so you can't get denials if you plan on doing policy development. Guess I'll have to rebuild the kernel when I get to that stage.

Time for a demo:

shell@android:/ $ getenforce
getenforce
Permissive

Here's where I hit the button to go into enforcing

shell@android:/ $ getenforce
getenforce
Could not get enforcing status:  Permission denied

So far, so good; to get out of enforcing just reboot. Fun fact #3, there is no way to keep enforcing persistent across reboots. I guess I'll have to write a service or something that runs at boot.

So, what can we do?

Okay, I found an interface that lets me load a new policy... at least I thought I did.

I updated the admin app and tried pushing policy, "success" it says... how do I test though? Pushing a random policy and going into enforcing is likely to cause all manners of breakage so I spent a couple hours writing a rule injector.

Run that baby:

joshua@QuarkZilla:~/sepolicy-inject$ sesearch -A -s shell -t selinuxfs -c file sepolicy                                    
Found 1 semantic av rules:
   allow appdomain fs_type : file getattr ; 

joshua@QuarkZilla:~/sepolicy-inject$ ./sepolicy-inject -s shell -t selinuxfs -c file -p open -P sepolicy -o sepolicy2      
joshua@QuarkZilla:~/sepolicy-inject$ ./sepolicy-inject -s shell -t selinuxfs -c file -p read -P sepolicy2 -o sepolicy

joshua@QuarkZilla:~/sepolicy-inject$ sesearch -A -s shell -t selinuxfs -c file sepolicy                              
Found 2 semantic av rules:
   allow shell selinuxfs : file { read open } ; 
   allow appdomain fs_type : file getattr ;

woohoo!

Let's test this out. Push the policy with the interface and test it out. Fail. Hrm...

shell@android:/ $ getenforce
getenforce
Could not get enforcing status:  Permission denied

Well, we don't have denials so this is tricky. Let's manually load the policy. The policy was put in /data/security by the interface, it just wasn't loaded:

root@android:/ # setprop selinux.reload_policy 1

How about now?

shell@android:/ $ getenforce
getenforce
Enforcing

Success. Well, at least I know my tool works :)

There are other interfaces to push down other policy files, such as seapp_contexts (fun fact #4: that interface actually misnames the target file as "seapps_context" ... sigh) but since they aren't reloaded there isn't much value there. Libselinux will read a properly named seapp_contexts from /data/security at boot time so you can put one there manually. ~~mac_permissions.xml does not get read from /data/security, so adding signatures won't work there. Luckily that file is on /system which we are already committed to modifying.~~

Correction: mac_permissions.xml does get read from /data/security at boot time. MMAC is not in enforcing by default but can be put into enforcing mode:

adb shell su -c "setprop persist.mmac.enforce 1"
adb reboot

Summary

Here's the bottom line:

The Good:

SE for Android is present
SE for Android can be turned to enforcing and the phone doesn't catch on fire
There are APIs for updating policies and setting enforcing

The Bad:

Enforcing not on by default
APIs don't actually work
Setting enforcing does not persist across reboots
No denials
No way to set back to permissive programatically
Strange side effects like requiring max log level
Root required to do anything with SE for Android
No way to get or set SELinux booleans

The Ugly:

These APIs are actually not public, meaning they can go away or change at any point
Without vulnerabilities available users won't be able to secure their devices...
Real SE for Android development on the GS4 means rerolling the kernel and boot image
If the management APIs are any indication the SE for Android support is still half-baked on the GS4
SE for Android isn't actually a supported feature on standard GS4's, technically it is a Knox feature, and we don't have Knox yet

Dan Walsh: New Security Feature in Fedora 19 Part 5: gssproxy

dwalsh@redhat.com — Mon, 03 Jun 2013 13:53:28 +0000

On Friday, I was asked to quickly write policy for the new gssproxy daemon which was added to Fedora 19. Investigating it, I found I had a new security feature blog, I had to write.

Fedora 19 is adding the gssproxy daemon. gssproxy will be replacing rpc.svcgssd.

gssproxy is a a proxy daemon for the GSS-API, which is a higher level API used mainly in Kerberized applications.

File systems services like CIFS, (samba), NFS and AFS make lots of kerberos encryption calls within the kernel, using keying material handed into the kernel. But the initialization and creation, renewing and cleaning up of credential caches, really should be handled in user space. gssproxy is the daemon to handle this.

A useful feature of gssproxy will eliminate the need to daemons that use kerberos keytabs from needing to read them directly. Currently if you set up an Apache server with kerberos, it needs full read access to the keytab file, allowing it to see the keying material. If Apache gets hacked, the hacker would get full access to the secrets. With gssproxy developers could setup Apache to talk to gssproxy and allow it to handle the keytab file, eliminating this need. This will allow my team to alter the SELinux policy and prevent the Apache daemon from being able to read keying information directly and force it to talk to the daemon.

Another cool feature, explained to me by Simo Sorce, is to take an application that needs kerberos access to a nfs share, but does not know anything about kerberos or the gssapi. Currently the way you handle this is to wrap an init scripts with things like k5start so the application has a keytab and a credential cache regularly refreshed. Then rpc.gssd would have to look in /tmp for a ccache to use for the application user and allow the application authenticated access to the secure nfs share.

With gssproxy you will not longer need to do this. All you need to do is drop a keytab in /var/lib/gssproxy/clients/<id>.keytab and the gssproxy will automatically initiate a connection when nfs client needs it. Advantages of this method:
1. No more wrapping of init scripts
2. Privilege separation, the app has no access to the keytab
3. Initiate on request, if the app never needs nfs we never initiate or renew tickets unnecessarily

gssproxy can be setup to renew Kerberos Tickets from keytabs for long running jobs, eliminating a lot of previous hacks.

Dan Walsh: New Security Feature in Fedora 19 Part 4: openssh 6.2 better support for multi-factor authentication

dwalsh@redhat.com — Sat, 01 Jun 2013 09:51:10 +0000

We are beginning to see the end of passwords as the only means of authenticating yourself to a system, hopefully.

Fedora 19 will be our first release of Openssh 6.2, which has introduced the AuthenticationMethods setting.

This feature allows you to require multiple different types of authorization to get into a system. For example it is very easy to require both an ssh public key and a password to login. If you don't have the public key, you will never get to the password prompt.

In previous Fedora releases, there were some tricky ways to do multi-factor using pam but this allows for more combinations, and easier setup.

I found this blog that does a great job of describing the feature.

https://blog.flameeyes.eu/2013/03/openssh-6-2-adds-support-for-two-factor-authentication

Bottom line if you have a critical server, you want a user to prove multiple ways that he is worthy to get on the system.

Dan Walsh: How do I tell what would be allowed by a boolean?

dwalsh@redhat.com — Tue, 28 May 2013 15:50:39 +0000

I received and Email today that asked the following question:

I still fail to understand the difference between httpd_can_network_connect_db and httpd_can_network_connect. Some people say the former allows connections to known database ports. My question are:

What are these ports? Where are the corresponding policy defined? I found many .pp files deeply under /etc/selinux, and I feel sorry that they are binary which are almost impossible to interpret, so where can I find the the source files for the compiled policy, and what is the language to define policies?

You could use the semanage command for how the booleans are described.

> semanage boolean -l | grep httpd_can_network_connect
httpd_can_network_connect_db   (off , off) Allow HTTPD scripts and modules to connect to databases over the network.
httpd_can_network_connect      (off , off) Allow HTTPD scripts and modules to connect to the network using TCP.

The best answer to this is to look at the sesearch and seinfo tools and on newer (Fedora/RHEL7) systems sepolicy command. Also look at the man pages that have been generated.

man httpd_selinux

sesearch and seinfo are available in the setools-cmdline package. sepolicy is in policycoreutils-python package.

httpd_can_network_connect_db

sesearch -A -s httpd_t -b httpd_can_network_connect_db -p name_connect
   allow httpd_t postgresql_port_t : tcp_socket { recv_msg send_msg name_connect } ;
   allow httpd_t mssql_port_t : tcp_socket name_connect ;
   allow httpd_t oracle_port_t : tcp_socket name_connect ;
   allow httpd_t mysqld_port_t : tcp_socket { recv_msg send_msg name_connect } ;
   allow httpd_t gds_db_port_t : tcp_socket name_connect ;

The command above reads in the policy and prints out what happens when you enable the httpd_can_network_connect_db boolean. We further restrict the search to see how it affects the httpd_t, apache, process type with the name_connect access.     sesearch tells us that turning on httpd_can_network_connect_db would allow the httpd_t domain to connect to tcp ports labeled postgresql_port_t, mssql_port_t, oracle_port_t, mysqld_port_t, gds_db_port_t. You can use seinfo to turn these port types into port definitions. semanage port -l would also work.

> seinfo --port | grep -e postgresql_port_t -e mysqld_port_t -e oracle_port_t -e gds_db_port_t | grep tcp
   portcon tcp 3050 system_u:object_r:gds_db_port_t:s0
   portcon tcp 1186 system_u:object_r:mysqld_port_t:s0
   portcon tcp 3306 system_u:object_r:mysqld_port_t:s0
   portcon tcp 63132-63164 system_u:object_r:mysqld_port_t:s0
   portcon tcp 1521 system_u:object_r:oracle_port_t:s0
   portcon tcp 2483 system_u:object_r:oracle_port_t:s0
   portcon tcp 2484 system_u:object_r:oracle_port_t:s0
   portcon tcp 5432 system_u:object_r:postgresql_port_t:s0

> sepolicy network -t postgresql_port_t
postgresql_port_t: tcp: 5432

httpd_can_network_connect

> sesearch -A -s httpd_t -b httpd_can_network_connect -p name_connect
Found 1 semantic av rules:
   allow httpd_t port_type : tcp_socket name_connect ;

The above command shows that httpd_can_network_connect allows httpd_t to connect to all tcp socket types that have the port_type attribute.

> seinfo -aport_type -x | wc -l
245

Using seinfo above would show you that port_type is the attribute of all port types, meaning that turning on the httpd_can_network_connect boolean, allows the httpd_t domain to connect to ALL tcp network ports.

Bottom Line httpd_can_network_connect_db allows httpd_t to connect to an additional 10 ports while httpd_can_network_connect adds thousands.

Dan Walsh: sandbox -X in Fedora 19 is resizeable, finally!

dwalsh@redhat.com — Sun, 26 May 2013 11:18:55 +0000

Thomas Liu worked as an intern for me a few years ago and wrote a patch for Xephyr to allow a Xepher window to be resizeable.

We shipped this patch in RHEL6 and waited for it to get upstream so we could pull it in Fedora. Well as of today a Xephr

 xorg-x11-server-1.14.1-2.fc19 has been pushed into Fedora 19, and we have support for resizing sandbox in Fedora.

Now rumors have it Labelled NFS may finally reach upstream, that would truly be remarkable...

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

dwalsh@redhat.com — Wed, 22 May 2013 17:42:52 +0000

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 — Mon, 20 May 2013 13:03:01 +0000

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 — Mon, 13 May 2013 11:14:29 +0000

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 — Mon, 06 May 2013 09:59:59 +0000

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

Tue, 30 Apr 2013 05:00:00 +0000

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 — Tue, 23 Apr 2013 20:52:39 +0000

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 — Tue, 23 Apr 2013 14:56:21 +0000

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 — Wed, 17 Apr 2013 15:40:16 +0000

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 — Wed, 17 Apr 2013 13:11:55 +0000

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

Fri, 12 Apr 2013 05:00:00 +0000

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 — Thu, 11 Apr 2013 14:17:49 +0000

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)

Thu, 11 Apr 2013 05:00:00 +0000

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 — Wed, 10 Apr 2013 13:04:24 +0000

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

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

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 — Fri, 15 Mar 2013 14:59:02 +0000

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 — Thu, 14 Mar 2013 18:35:27 +0000

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 — Thu, 07 Mar 2013 23:00:00 +0000

最近、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)

Mon, 11 Feb 2013 06:00:00 +0000

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

Wed, 06 Feb 2013 06:00:00 +0000

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 — Mon, 04 Feb 2013 04:38:37 +0000

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 — Wed, 30 Jan 2013 21:16:33 +0000

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 — Mon, 28 Jan 2013 02:56:30 +0000

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 — Fri, 18 Jan 2013 14:37:20 +0000

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 — Mon, 07 Jan 2013 16:28:59 +0000

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 — Sun, 23 Dec 2012 01:08:49 +0000

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 — Thu, 06 Dec 2012 05:26:19 +0000

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) — Sat, 01 Dec 2012 10:17:35 +0000

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 — Thu, 01 Nov 2012 17:42:31 +0000

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 — Wed, 31 Oct 2012 18:23:56 +0000

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 — Mon, 29 Oct 2012 13:26:28 +0000

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 — Sat, 27 Oct 2012 11:57:24 +0000

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 — Fri, 26 Oct 2012 12:05:56 +0000

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 — Fri, 26 Oct 2012 11:27:36 +0000

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 — Fri, 26 Oct 2012 10:33:34 +0000

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 — Thu, 18 Oct 2012 19:00:26 +0000

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 — Thu, 18 Oct 2012 15:54:24 +0000

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 — Mon, 15 Oct 2012 18:50:06 +0000

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 — Tue, 09 Oct 2012 14:14:05 +0000

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 — Tue, 09 Oct 2012 13:03:46 +0000

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) — Mon, 08 Oct 2012 06:21:59 +0000

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 — Thu, 04 Oct 2012 14:32:16 +0000

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

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

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 — Mon, 01 Oct 2012 15:45:30 +0000

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) — Sun, 30 Sep 2012 12:07:20 +0000

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 — Fri, 28 Sep 2012 12:40:43 +0000

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 — Thu, 27 Sep 2012 13:21:17 +0000

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

Wed, 12 Sep 2012 22:00:29 +0000

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 — Mon, 10 Sep 2012 14:40:40 +0000

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 — Wed, 05 Sep 2012 19:31:27 +0000

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) — Mon, 03 Sep 2012 03:59:56 +0000

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 — Wed, 29 Aug 2012 04:41:52 +0000

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 — Fri, 17 Aug 2012 20:53:30 +0000

前回の記事では、現在の 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 — Sat, 11 Aug 2012 06:52:26 +0000

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 — Sat, 04 Aug 2012 11:52:22 +0000

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.