| |||||||||||||
Standards, the kernel, and PostfixStandards, the kernel, and PostfixPosted Aug 20, 2008 21:41 UTC (Wed) by jengelh (subscriber, #33263)In reply to: Standards, the kernel, and Postfix by jzbiciak Parent article: Standards, the kernel, and Postfix
>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.
(Log in to post comments)
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).
|
|||||||||||||