Re: any user can make hard links in Unix

[eilert () INFORMATIK UNI-BREMEN DE (Eilert Brinkmann)]

Benjamin Elijah Griffin <bgriffin () CDDB COM> wrote:
> Basically any user can make a hard link to any file IF
>
>   A) the user knows the file exists
>   B) has enough access to cd into the directory it is in
>   C) has write access to any directory on the same volume
>
> What does this gain you?
>
>   1) If the user has read access to the writable directory, s/he
>      can now stat the inode even if the original location did not
>      offer read access.

No gain. Read access to a directory is not needed to stat files inside
it. Provided A) and B) you can already stat the file's inode.

>   2) The user can change the ctime of the inode (fun with tripwire).

AFAIK the only way to prevent this is to ensure that no directory on
the same partitions as the watched files is writable by normal users.

>   3) Some suid programs that just checked for sym-links can perhaps
>      be duped into opening or writing to files they shouldn't.

Possible. But generally it's a good idea for suid programs to operate
only on files in "secure" directories (to use the absolute path of a
directory in which only authorized users have write permission) or on
files the user executing the command has access to.

>   4) Social hacks involving 'chown -R' or the like.

A normal user would still not be able to chown the file. This might be
an issue if the superuser does `chown -R' on the writable
directory. However, such an action is not a good idea in general. The
superuser should not blindly chown files in world writable
directories.

>   5) Screw with the quota of other users and other ways to make it
>      hard to delete files that should be deleted (eg large logs in
>      /var)

IMHO this is the hardest to solve problem. Even if a user notices the
increased link count (and most (if not all) users will not) before
deleting a file he will probably not be able to locate and delete the
other hard link without the superuser's help. And filling up the /var
filesystem might end up in a denial of service or the loss of log
messages. The latter could be used to cover other attacks.

> Possibly other things.

What about this situation: A user creates a hard link to a suid root
program. Now let's say a security hole in this program is discovered
and the administrator updates the program. If this update replaces the
original link rather than overwriting the file, the user has still a
link to the original, vulnerable version of the program. (Even without
this problem it's a good idea to check the whole system for unwanted
suid programs on a regularly basis.)

It may be a good idea to permit only the owner of a file to hard link
it. I don't know if this change will break anything, but in the moment
I don't see any reason why users should be able to create hard links
to files they don't own. Usually symlinks should do it. However, this
would require a change in the kernel (should be easy to do).

Eilert

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik
eilert () informatik uni-bremen de - eilert () tzi org - eilert () linuxfreak com
              http://www.informatik.uni-bremen.de/~eilert/