Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Jun 2017 10:42:35 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Solar Designer <solar@...nwall.com>, "kernel-hardening@...ts.openwall.com"
	<kernel-hardening@...ts.openwall.com>
CC: Kees Cook <keescook@...omium.org>
Subject: RE: hard link restrictions

> Kees, all -
> 
> My renewed interest in hard link restrictions was in context of crontab
> vs. crond privsep:
> 
> http://www.openwall.com/lists/oss-security/2017/06/08/3
> 
> Under that threat model (mostly overlooked/neglected so far?), any
> hard link to another user's (or root's) file is risky.  Even a file the
> linking user could readily read and write.  For crond specifically, this
> is not the case because it will refuse to process files with extra write
> permissions.  But for other services not yet hardened like this, e.g.
> mode 666 files hard-linked into their queue, etc. directories could be
> usable for attacks.
> 
> Another subtle scenario where a hard link to another user's writable
> file could help the attacker is preserving one's ability to bypass disk
> quota via that file, even after the original owner would have deleted
> their original link to the file.  Similarly, it'd allow for keeping the
> other user's disk quota consumption even until after that user would
> have deleted their original link and wanted the quota usage reclaimed.
> 
> Because those hard link restrictions were so non-standard back
> when they were new, we applied them only to files the user could not
> readily read and write, plus to SUIDs/SGIDs for the "pinning" concern.
> We tried to minimize breakage of programs relying on being able to hard
> link to arbitrary files.

I remember that we looked a while back on all issues possible using hardlinks
and while I don't remember the details anymore (it was more than 5 years ago), 
the conclusion at that time was that hardlinks are really scary from security POV
and best to be fully disabled if you have a custom enough distro that can survive without them. 

I guess for current Linux the full disablement won't fly, but I would greatly support
the idea of limiting them even further like in your proposal below.  

Best Regards,
Elena.

> 
> Maybe now is the time to introduce a stricter mode, perhaps enabled with
> "fs.protected_hardlinks = 2", where any hard links to other users' files
> would be disallowed, except when the invoking process has CAP_FOWNER?
> 
> In code, this would be skipping the "|| safe_hardlink_source(inode)" in:
> 
> 	/* Source inode owner (or CAP_FOWNER) can hardlink all they like,
> 	 * otherwise, it must be a safe source.
> 	 */
> 	if (inode_owner_or_capable(inode) ||
> safe_hardlink_source(inode))
> 		return 0;
> 
> While we're at it, doesn't the above code unnecessarily set PF_SUPERPRIV
> (which is then reported via BSD process accounting) when the CAP_FOWNER
> check inside inode_owner_or_capable() is reached and passed, but
> safe_hardlink_source() later returns false?
> 
> In fact, inode_owner_or_capable() itself might also be problematic in
> this respect in that it'd set PF_SUPERPRIV even if kuid_has_mapping()
> later fails:
> 
>         if (ns_capable(ns, CAP_FOWNER) && kuid_has_mapping(ns, inode->i_uid))
>                 return true;
> 
> Or has the kernel gave up on being careful not to set PF_SUPERPRIV
> unnecessarily?  Sometimes it's a conflicting goal to minimizing the
> attack surface and improving performance in case of request flood DoS
> attacks, where it's best to stop processing the request sooner ("you
> would not be capable anyway") than later (after expensive other checks).
> 
> Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.