From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E7195138330 for ; Wed, 10 Jan 2018 01:19:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7948EE0C15; Wed, 10 Jan 2018 01:19:35 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2C1B7E0C0C for ; Wed, 10 Jan 2018 01:19:34 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id AC5C7335C38 for ; Wed, 10 Jan 2018 01:19:32 +0000 (UTC) Subject: Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue To: gentoo-dev@lists.gentoo.org References: <20180110000741.GA3995@whubbs1.gaikai.biz> From: Michael Orlitzky Message-ID: <14e5af26-fdb7-802c-e6d2-7a69c5115e0d@gentoo.org> Date: Tue, 9 Jan 2018 20:19:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20180110000741.GA3995@whubbs1.gaikai.biz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: b8fa0be6-18bf-47a6-950f-47087990ebcf X-Archives-Hash: c76422c0463205712c7d3d4c3860d3f5 On 01/09/2018 07:07 PM, William Hubbs wrote > > However, I'm not sure how to deal with the hard link issue in a way that > will not break service scripts. > Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by default, but they have the liberty of requiring a relatively new Linux kernel. The larger problem there is that, unless you have some kernel protection built-in, the "Z" type in the tmpfiles.d spec is always going to be exploitable: * https://github.com/OpenRC/opentmpfiles/issues/3 * https://github.com/systemd/systemd/issues/7736 (I didn't realize at the time that the OpenRC fix still contained a race condition.) Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory that is not writable only by yourself and root. There's some precedent for this in e.g. https://wiki.gentoo.org/wiki/Hardened/Grsecurity_Trusted_Path_Execution where they refuse to *execute* something that is writable by others. But a solution like that would break existing scripts. If it's any consolation, the tools like chown, chgrp, chmod, setfacl, etc. are all vulnerable to the same issue themselves. GNU chown has the "--from" flag (which still contains a race, by the way), but the other tools don't, and are all exploitable in the same way. Again the advice seems to be "don't do things if somebody can write to the directory you're in." Here's a very tedious proposal for OpenRC: 1. Create a new helper, called e.g. "newpath", that is like checkpath but only creates things, and doesn't modify them. 2. Have newpath throw a warning if it's used in a directory that is writable by someone other than root and the OpenRC user. This will prevent people from creating /foo/bar after /foo has already been created with owner "foo:foo". In other words, service script writers will be encouraged to do things in a safe order. Since we're starting over, this might even be made an error. 3. Deprecate checkpath 4. Wait a million years for people to switch from checkpath to newpath 5. Get rid of checkpath I'm not even sure that this solves the problem completely, but it's the only idea I've got left.