User: Password:
|
|
Subscribe / Log in / New account

Standards, the kernel, and Postfix

Standards, the kernel, and Postfix

Posted Aug 20, 2008 21:21 UTC (Wed) by jzbiciak (subscriber, #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:

  • Suppose /etc/inittab is a symlink to /etc/inittab.thishost.
  • Now suppose an attacker hard-links /etc/inittab to /home/attacker/maildir/somefile.
  • Next, the attacker mails himself a specially formatted email containing inittab records.

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 (subscriber, #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 (subscriber, #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]

  • Suppose /etc/inittab is a symlink to /etc/inittab.thishost.
  • Now suppose an attacker hard-links /etc/inittab to /home/attacker/maildir/somefile.
  • Next, the attacker mails himself a specially formatted email containing inittab records.

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?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds