funsec mailing list archives
Re: symlink creation (and sudo)
From: der Mouse <mouse () rodents-montreal org>
Date: Thu, 27 May 2010 13:20:30 -0400 (EDT)
[...] we were surprised to find the following:
% ln -s /etc/sudoers bob % sudoedit bob
The shocking part isn't the 'sudoedit bob', but that my user is allowed to create the symlink in the first place. sudoers is 0440, and I'm not in its group, so I'd have expected this to fail.
Why? You can symlink to any string you please. % ln -s 'any%old!string/I_happen-to~want' bob % Whether the string names a file, and if so what file, is totally irrelevant at symlink() time. Indeed, I've seen multiple things that use symlinks as, effectively, tiny files which can be read with one syscall (readlink) rather than three (open, read, close) and without needing a file descriptor.
I could have sworn that I'd be unable to symlink to a file to which I have no read access, and my co-workers felt the same way.
Not only can you do that, you can *hard*link to a file you have no read access to, on at least some systems (I just now tried it as an ordinary user and I could hardlink to an rw------- root file just fine).
Is this behaviour not tunable? Is there some knob somewhere I can twiddle to not allow symlink creation to files to which the user has no read access?
Probably not. Symlinks don't point to files; they point to paths. It is really very hard to do what you want here. Cnsider: % pwd /home/mouse % mkdir -p foo/bar % cd foo/bar % mkdir etc % echo hello > etc/passwd % mkdir -p home/mouse/king % ln -s ../../../etc/passwd home/mouse/king/bob So far, everything has been totally sane: all my own files and directories, all perfectly reasonable. But now: % mv home/mouse/king ~ Suddenly the file the bob symlink - now accessible as king/bob from my homedir - points to is the real /etc/passwd.
But perhaps more importantly, I don't understand why I'd be allowed to do this in the first place. Why should a generic user be allowed to create symlinks to protected system files?
Because symlinks aren't to files; they're to strings. Permissions checking is performed at the time the of access, as for any other file access; the symlink is just a redirection taking place during the path walk, affecting what file is found but nothing more. You could equally well "ln -s /etc bob" and then poke at "bob/sudoers". Or, quite possibly, just use something like "../../etc/sudoers" in the first place and forget about the symlink altogether. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse () rodents-montreal org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Current thread:
- symlink creation (and sudo) Damian Gerow (May 27)
- Re: symlink creation (and sudo) Bill Weiss (May 27)
- Re: symlink creation (and sudo) Valdis . Kletnieks (May 27)
- Re: symlink creation (and sudo) Damian Gerow (May 27)
- Re: symlink creation (and sudo) Valdis . Kletnieks (May 27)
- Re: symlink creation (and sudo) Damian Gerow (May 27)
- Re: symlink creation (and sudo) der Mouse (May 27)
- Re: symlink creation (and sudo) Damian Gerow (May 27)