From nobody Fri Nov 12 12:05:58 2021 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 48DAB18434B2 for ; Fri, 12 Nov 2021 12:05:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HrHNl1QMGz4W81 for ; Fri, 12 Nov 2021 12:05:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0ECE61EEE2 for ; Fri, 12 Nov 2021 12:05:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1ACC5wFa073812 for ; Fri, 12 Nov 2021 12:05:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1ACC5wO7073811 for bugs@FreeBSD.org; Fri, 12 Nov 2021 12:05:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 259770] ggate: jail(2) failure error: Unable to jail process in directory /var/empty after stable/12 src ca9ab8ea1774 Date: Fri, 12 Nov 2021 12:05:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mjg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259770 Mateusz Guzik changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjg@FreeBSD.org --- Comment #3 from Mateusz Guzik --- But does this really work with the pwd_chroot_chdir_check_open_directories hack? To my reading the pidfile API keeps the dir fd open so that it can unlink t= he file down the road. As /var/run is 755 you need root permissions to do it. The patchset includes setuid to an unprivileged user which to my understand= ing already prevents the functionality from working. So let's say ggated stays running as a jailed root. If the /var/run dirfd is let inside even with rights limited to unlinking files in that directory, compromised ggated would be able to unlink evey file inside, not just its o= wn pidfile. This could be worked around with a syscall which takes a path and a matching file descriptor to prove you have the thing open and only then allows unlin= k. I think this sufficiently demonstrates that: 1. passing dir fds inside is very error prone 2. managing pidfiles from a daemon of the sort is a bad idea That said, in my opinion the best long term solution is to move pidfile management out of any priv-dropping code. I do have to note that the rc system has to tolerate stale pidfiles already (e.g., what if the machine crashed and there was nobody to clean it up), so perhaps in the meantime the pidfile API can grow a flag that the caller is = not going to do pidfile_remove and consequently dir fd is not needed. --=20 You are receiving this mail because: You are the assignee for the bug.=