Are world-readable/writable/executable links in /usr/bin security holes?

% ls -l /usr/bin/edit                                                                                                
lrwxrwxrwx 1 root root 3 Jan 10 05:54 /usr/bin/edit -> vim*

This seems to apply to many binaries in update-alternatives, at least on Suse and perhaps other Linux distributions. Doesn't this mean that any compromised account on Suse could modify the symlink, tricking the user into executing anything? If so, why are these the default permissions?

user76871

Posted 2012-02-28T18:02:55.087

Reputation: 791

Migrate to ITSecurity possibly? – cutrightjm – 2012-02-28T18:10:22.603

Answers

From the Wikipedia entry for Symbolic link:

The file system permissions of a symbolic link usually have relevance only to rename or removal operations of the link itself, not to the access modes of the target file which are controlled by the target file's own permissions.

Because that symlink is owned by root, only he can change it. E.g.

# ln -s /bin/ls blah
# ls -la blah
lrwxrwxrwx 1 root root 7 Fev 28 15:07 blah -> /bin/ls
$ rm blah
rm: cannot remove `blah': Operation not permitted
$ ln -s blah /bin/true
ln: failed to create symbolic link `/bin/true': File exists

Renan

Posted 2012-02-28T18:02:55.087

Reputation: 7 463

Thank you. But while useful, this is misleading and does not give the correct answer to the question. I was able to realize on my own why it was not a security hole, so wrote an answer below. Nevertheless thank you for attempting to answer the question. – user76871 – 2012-02-28T18:29:55.990

answering own question after figuring it out:

I have figured this out. This would be a security hole, except for the fact that /usr/bin is owned by root and not world-writable, and thus you cannot modify the link. If /usr/bin was world-writable, you could replace the link with your own link, but that is not the case.

As a proof of concept:

% cd
% sudo touch rootfile
% sudo ln -s rootfile rootfile_link
% touch evilfile
% ln -s evilfile evilfile_link

# works, but only if directory permissions are correct:
% cp evilfile_link rootfile_link

However if there was a way to edit the actual symlink file (it's just a short snippet of text I think), it would be possible to be evil.

Thus I will actually hold off on accepting any answer until someone can come up with strong evidence that a symlink can/can't be modified, or replaced-with-permissions-intact, and accept that answer.

user76871

Posted 2012-02-28T18:02:55.087

Reputation: 791

yep :) Good job on figuring it out yourself. symlinks are meant to be invisible, and 777 perms help to keep it that way. – Rich Homolka – 2012-02-28T18:30:00.493

@RichHomolka: 'invisible' as in 'people dereferencing the link don't notice'? If that's what you mean, that totally makes sense as to why they're 777. Thank you. – user76871 – 2012-02-28T18:39:26.367

A symlink (on a modern filesystem) isn't a text file at all, it's a filesystem-level link (contrast with OS X aliases and Windows shortcuts). – Wooble – 2012-02-28T18:49:42.360

In a word, no.

The kernel just uses the symlink to find the file/directory that the link points to.

Take the example view => vim (a common symlink in /usr/bin, call vim by the name view and it will open the text file read only).

The kernel will 'open' view, see it is a pointer to vim, close view and then open vim. As it opens/exec's vim, it uses all the security checks on vim. So vim is still opened with the permissions on vim, which is what you expect.

Ah ha! But a symlink iss a file, and if it's writeable, I can open it, edit it, and change the target! /usr/bin/view becomes a pointer to /tmp/myevilexec. In a word, no. It's a special file, you can not open the symlink 'file' and edit it this way. You can only replace the symlink, and then the perms on the symlink are irrelevant - directory perms determine whether you can delete files/create new files.

In short, 777 for symlinks is not a security hole, and it makes perms of the symlink 'invisible' and perms in effect are the target file, which is what you expect.

Rich Homolka

Posted 2012-02-28T18:02:55.087

Reputation: 27 121

Thank you, this is exactly what I figured, unfortunately at the same time you finished posting your answer. =) I tried to find a way to edit a symlink, but could not find one. If you have a reference to "It's a special file, you can not open the symlink 'file' and edit it this way." I would love to hear it. – user76871 – 2012-02-28T18:34:24.970

1@user76871 I just checked 'ln -s -f ' and it calls the symlink syscall, which respects the dir perms, which is what you'd expect. My guess is that you'd have to dive into kernel filesystem stuff to truly prove you can't 'open' a symlink, and i don't have time for that now. Look up 'vfs symlink' on google, see where that takes you. – Rich Homolka – 2012-02-28T18:49:43.867