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.

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