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.

1. You have a labeling problem.


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


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


4. You have been hacked.

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

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


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


3. Is their an SELinux Boolean that would allow the access?


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


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


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


7. Am I being hacked?

• s0


• s0:c1


• s0:c2


• s0:c1,c2

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

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

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

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

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

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

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.

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

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.

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.

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.

<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

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


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

1. webadm_t, which can only administrate apache types.


2. dbadm_t which can administrate types associated with mysql and postgresql.


3. logadm_t which can administrate types associated with syslog and auditlog


4. secadm_t which can only administrate SELinux controls


5. auditadm_t which can only administrate the audit subsystem.