8
% 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
  • 910
  • 9
  • 22

3 Answers3

4

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
  • 7,981
  • 4
  • 39
  • 48
  • 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 Feb 28 '12 at 18:29
4

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
  • 31,057
  • 6
  • 55
  • 80
  • 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 Feb 28 '12 at 18:34
  • 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 Feb 28 '12 at 18:49
3

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
  • 910
  • 9
  • 22
  • 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 Feb 28 '12 at 18:30
  • @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 Feb 28 '12 at 18:39
  • 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 Feb 28 '12 at 18:49