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 3754E1382C5 for ; Fri, 4 Dec 2020 14:23:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E780E0986; Fri, 4 Dec 2020 14:23:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 00B5AE0966 for ; Fri, 4 Dec 2020 14:23:15 +0000 (UTC) Subject: Re: [gentoo-user] Switching default tmpfiles and faster internet coming my way. To: gentoo-user@lists.gentoo.org, Dale References: <4b0dc38c-0f6e-208d-6187-c856a453aeae@gentoo.org> <61d98418-9451-027d-3266-4f62a13a8802@gmail.com> From: Michael Orlitzky Message-ID: Date: Fri, 4 Dec 2020 09:23:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <61d98418-9451-027d-3266-4f62a13a8802@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 21621df2-867b-458b-a070-470d69bbad40 X-Archives-Hash: b3cd863f05b64f507c359ab35aeb0c7b On 12/4/20 1:44 AM, Dale wrote: > > Will opentmpfiles be fixed at some point or is it true that it can't be > fixed?  On -dev, I think I read where one person said it can't be > fixed.  In that case, switching is likely a good idea since the insecure > package can't be fixed. > The answer is a bit complicated. The first thing we need to understand that opentmpfiles is supposed to be a cross-platform (i.e. POSIX) implementation of the systemd-tmpfiles program. Systemd itself only runs on newer versions of linux, and since it has control of the entire system, it can enable those non-standard symlink and hardlink protections. So, * systemd-tmpfiles is secure, but only on linux, and only if you let it enable fs.protected_hardlinks for you. The security there comes from two places. The first is that everything was implemented carefully in C to avoid these problems, and the second is that fs.protected_hardlinks solves the otherwise-unavoidable hardlink exploits. Now for contrast, opentmpfiles is INsecure for two reasons: (1) It's written in shell script, so it doesn't have the ability to pass e.g. O_NOFOLLOW to all of the calls that might follow symlinks. And shell programs all operate on path names as opposed to file descriptors, so race conditions are impossible to avoid. (2) The fs.protected_hardlinks sysctl is not cross-platform, so if it's to fulfill its stated design goals, opentmpfiles can't rely on fs.protected_hardlinks. The first problem is fixable, but the second is not. If opentmpfiles is rewritten in C, it could be just as secure as systemd-tmpfiles... but **only on linux with fs.protected_hardlinks enabled**. It will never be both secure and cross-platform. The design of the whole tmpfiles.d thing is flawed in that regard. > > root@fireball / # sysctl -n fs.protected_hardlinks > 1 > root@fireball / # > > > Does that improve things any or does that not really help anything? > It completely fixes one of the problems (hardlinks), but does nothing for the other (non-terminal symlinks).