| |||||||||||||
Standards, the kernel, and PostfixStandards, the kernel, and PostfixPosted Aug 20, 2008 21:21 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)In reply to: Standards, the kernel, and Postfix by Thalience Parent article: Standards, the kernel, and Postfix
Here's the scenario, as I understand it:
The attacker can't modify the symlink in /etc because that directory is not owned or writable by the attacker. The attacker can make a hard link1, though, and that's where the hole is. To my eyes, the real problem is that it's possible to deliver mail for user $FOO to a file that user $FOO doesn't have write permission on. If you're reading mail via a local mail spool, and the user has control over where it's written, it seems as though some setfsuid is in order when writing it? 1 Hard links tend not to be able to span filesystem boundaries, though, so if /etc and /home are in different filesystems, you may be ok. I don't think anything guarantees or requires that, but it's a common feature of all the *nix filesystems I've worked with, which is admittedly a narrow set.
(Log in to post comments)
Standards, the kernel, and Postfix Posted Aug 20, 2008 21:41 UTC (Wed) by jengelh (subscriber, #33263) [Link] >The attacker can make a hard link, though, and that's where the hole is. And grsec has had a kernel patch that addresses exactly this problem for a long time denying hardlinks to files in directories not owned or writable (one or the other, don't remember) by the actor.
Standards, the kernel, and Postfix Posted Aug 20, 2008 21:58 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Hmmm... Seems like "not writable by" might be more likely than "not owned by." While I can't think of a specific instance, I imagine that disallowing hard links in /tmp might confuse a couple things. (But think of all the race conditions we might close! Oh, wait, that's mostly symlinks.)
Standards, the kernel, and Postfix Posted Aug 20, 2008 22:29 UTC (Wed) by jengelh (subscriber, #33263) [Link] Yes it does confuse a few things. Not in /tmp, but surprisingly, in /var/spool/atjobs! I solved it by augmenting the batch to allow an exception for system UIDs (uid < 1000, or whatever you specified as an exception).
Standards, the kernel, and Postfix Posted Aug 21, 2008 1:50 UTC (Thu) by Thalience (subscriber, #4217) [Link] Ah. Because you can't unlink the original name of the root-owned symlink (in the case of an important file in /etc at leats), you can't get the same effect. And I can't think of a root-owned file that would live in a dir a regular user can write to...
Standards, the kernel, and Postfix Posted Aug 21, 2008 15:28 UTC (Thu) by iabervon (subscriber, #722) [Link] I don't think it's possible for hard links to span filesystems. The point of a hard link is that the two names have the same inode, and a dentry pointing to an inode on a different filesystem either wouldn't work at all (since the dentry doesn't include enough information to specify the inode completely) or wouldn't be really a separate filesystem. I suppose, however, you could have a single filesystem that you'd carved up and arranged with bind mounts to look like multiple filesystems, and the OS wouldn't necessarily block creating the hard links (although, IIRC, Linux presently does).
Standards, the kernel, and Postfix Posted Aug 21, 2008 23:19 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] That's my understanding as well. I was pretty sure traditional *nix filesystems worked this way. What I wasn't sure of is whether union mounts, or one of the newer filesystems supported something fancier. I know if I state unequivocally that it can't be done, the odds are against me someone will demonstrate I'm wrong. ;-)
Standards, the kernel, and Postfix Posted Aug 23, 2008 0:23 UTC (Sat) by giraffedata (subscriber, #1954) [Link]
I'm guessing from the clues in the article that there's more to it: The above would ordinarily fail because Postfix sets the process permissions to attacker's before writing the mail file and attacker doesn't have write permission to /etc/inittab.thishost. But Postfix, I'm guessing, notices that /home/atacker/maildir/somefile is a symbolic link owned by root, assumes that the only way that could get there is that root created it there, and therefore feels safe in using root's permissions or even DAC_OVERRIDE privilege to write through it. I can see that might be a useful feature.
Standards, the kernel, and Postfix Posted Aug 25, 2008 20:54 UTC (Mon) by ceplm (subscriber, #41334) [Link]
Is this case covered by SELinux?
|
|||||||||||||