Proposal for a Linux kernel modification in order to increase security

Dynamic umask for the access rights of linked objects in Unix file systems

Version 1.0, 28.08.2005, Hauke Laging, hauke@laging.de

the problem

(At least) If applications store data in directories which are write-accessible by other users then symlink attacks become possible. A file is erased and replaced by a symlink. The (buggy) application can be abused if it can read or write the linked-to file but the abusing user cannot. These attacks are mostly denial of service attacks.

The problem could be solved by using the correct access rights for the directory but that is not a valid argument as any such security problem could have been avoided - nonetheless they do occur. This is about a general approach for a second level of security (behind avoiding bugs in the application).

Solution

The kernel should be extended by a function (which can be enabled and disabled) which would solve the problem. The access rights of a symlink are ignored but its creator is stored. The kernel should do additional checks when determining whether a file system object can be accessed in the requested way:

  1. Is the accessed object a symlink?

  2. Has the creator of the symlink got the access rights which the respective process is requesting.

If the situation turns out to be critical then the kernel would deny the respective rights. The process cannot access the file via the symlink though it could have if it had tried to access it directly. The access rights of the symlink creator (through the whole path, not just for the file) would be used as a mask for the applications rights.

Effort

The implementation effort should be little as the normal check procedure would have to be called twice - once for the requesting user id and once for the uid of the symlink creator.

Problems

Hardlinks

This approach does not work when hard links are created instead of soft links but the problem would be restricted to attacked files on the same volume

Changed to the system behaviour are dangerous for the compatibility

Several people have pointed out to this problem but none of them was capable of giving a real world example. Obviously it does not make any sense to create a symlink one cannot use oneself at all.

As this is just a protection against bugs any application could be allowed to disable this behaviour for itself by setting some /proc value.

Alternatives

control the creation of links

A good alternative/extension would be to disallow the creation of (hard) links if the creator does not have certain access rights to the target. A problem is that it is legitimate to create links to files which one can read only but this allows the attack in question. There is a real call for action for hard links only as soft links can be well handled by the approach explained above. As it is generally legitimate to create hard links, too, this limit should be restricted to directories which are not owned by the link creator which seems to be an accepable restriction. In this case an attacker could not put dangerous links into /var/log/buggy_app. The problem is not solved completely though: If there is a directory hierachy with wrong access rights this protection could be circumvented: /var/log/buggy_app/subdir could be replaced if the parent is world-writable.