From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-83547-garchives=archives.gentoo.org@lists.gentoo.org>
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 ADF0E138206
for <garchives@archives.gentoo.org>; Sat, 20 Jan 2018 00:16:59 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D23C1E099E;
Sat, 20 Jan 2018 00:16:53 +0000 (UTC)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b])
(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 7468DE0984
for <gentoo-dev@lists.gentoo.org>; Sat, 20 Jan 2018 00:16:53 +0000 (UTC)
Received: by mail-ot0-x22b.google.com with SMTP id r4so2873316oti.12
for <gentoo-dev@lists.gentoo.org>; Fri, 19 Jan 2018 16:16:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=sender:date:from:to:cc:subject:message-id:mail-followup-to
:references:mime-version:content-disposition:in-reply-to:user-agent;
bh=ZiNZkuJm0OBUNUzYHHdFj0oTbfIOWI4ipcKCk7uHZwg=;
b=uHgguG+JpPn6h5XnoWYDmUusWoB5BETcIDv4gEdz28qwbe5MnMgwE+HQQQ+sfSk7gZ
PbTuwhSGgbd1scgOBmzRfodPjGTppETtyXECLtK2Ln5kSXnDFn77d5aeztjWD7otW3Vl
BDMijUJIIl2aIhHn39Pq28pxHnAzi3PBUbDqh5n07agneCPWRf+qI+QIbiPCf1fgw9TD
SKgfIKZc7tkGKZNBdLo+zPnbc39w8dzhkuTDHoe4bnEPvjZZm+43tGGrhZk93HbL0dzH
8qSHjNiKBBYOoEPo+iNKGKSJdInvFVmBMi8uiMh9ucJPuQzLepSFPgggAR6JvBVnsKRe
8U1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
:mail-followup-to:references:mime-version:content-disposition
:in-reply-to:user-agent;
bh=ZiNZkuJm0OBUNUzYHHdFj0oTbfIOWI4ipcKCk7uHZwg=;
b=h6qyyUGobaZPTRU5LXHQANy8ajlXFvmGdE8cvtk/lmMVGDOGsG2F7RHhiC53kFykC0
NGPZU88iKWkRaya3Y8c/oyEwyszjl9AsmMqi9aunOP89AVYRXTb6mpfQGgvwwXMYCWLR
uD/uCXXJvhz4sQ7PeER5kkRlnvDh3ncur6fCMNhFIpFYJODPNKR6vgXm8DaDt/sXZQxO
GYbN8lVgeZfdrPsYUIzWNvKQweXang+Q0tx+5LpZMikvDQIYpXTl3FWme2EZ0RVkRD9v
SeVKDCOOUANMMH0IK87Oa9e2p7o6VssOxpYBMZD7Q/8QlU7fwn1poWSQd+gp/QZvPQrM
UiNg==
X-Gm-Message-State: AKwxyte+iECURosFqXm3Bi1AfYJnVcid7S6wly4e22wLygMGvbx1nNwp
jSDX2rfVfoKNcmZWrMNwUxl2Pg==
X-Google-Smtp-Source: AH8x226XjJ130vjvdMLg9jfOtCPx9duo3/o4xNNb9p80Tyfkl4xFAwcvOUrtkM/Ib/lOLnASA49nEA==
X-Received: by 10.157.89.162 with SMTP id u34mr166669oth.302.1516407411947;
Fri, 19 Jan 2018 16:16:51 -0800 (PST)
Received: from linux1 (cpe-66-68-34-247.austin.res.rr.com. [66.68.34.247])
by smtp.gmail.com with ESMTPSA id i11sm5107666otb.57.2018.01.19.16.16.49
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Fri, 19 Jan 2018 16:16:49 -0800 (PST)
Sender: William Hubbs <w.d.hubbs@gmail.com>
Received: (nullmailer pid 25212 invoked by uid 1000);
Sat, 20 Jan 2018 00:16:48 -0000
Date: Fri, 19 Jan 2018 18:16:48 -0600
From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: mjo@gentoo.org
Subject: Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue
Message-ID: <20180120001648.GA24415@linux1.home>
Mail-Followup-To: gentoo-dev@lists.gentoo.org, mjo@gentoo.org
References: <20180110000741.GA3995@whubbs1.gaikai.biz>
<14e5af26-fdb7-802c-e6d2-7a69c5115e0d@gentoo.org>
<20180110180443.GA1085@whubbs1.gaikai.biz>
<b41e288a-2ec4-00f7-2b44-f72259ec9831@gentoo.org>
<20180110215437.GA3156@whubbs1.gaikai.biz>
<731ea2b8-349d-28d4-72a6-3b9555f5bdf7@gentoo.org>
<20180117152108.GA9130@linux1.home>
<04627c1a-64b7-9370-41d8-ddc79213de5b@gentoo.org>
<20180117171416.GA18843@whubbs1.gaikai.biz>
<03558fda-26b3-2e3a-ad42-c94848f49955@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx"
Content-Disposition: inline
In-Reply-To: <03558fda-26b3-2e3a-ad42-c94848f49955@gentoo.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Archives-Salt: 3fe7fec0-3a9c-461e-8749-480e193a5c88
X-Archives-Hash: aeb591993424eb4546f3b42ce5d5210e
--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jan 18, 2018 at 07:19:59PM -0500, Michael Orlitzky wrote:
> Not at all. I'm working this out as I go, so better to speak up if
> something looks fishy.
>=20
> There are a few risks that I see with the first approach...
>=20
>=20
> Risk #1: From what I can tell, the current implementation of checkpath
> first creates the path, and then adjusts the ownership and permissions
> on it. After /run/foo/bar has been created but before the permissions
> and ownership are changed, the "foo" user can replace "bar" with a hard
> link (because he owns /run/foo). The lchown/chmod will operate on the
> target of that link, and if he's fast enough, then the "foo" user can
> use that to take over root's files. (Limited to /run in this example,
> but that's beside the point.)
>=20
> Maybe that can be avoided. Is there a portable way to atomically create
> a file/directory with its ownership and permissions already set? Or is
> it possible to operate on the descriptor that you get back when creating
> the path?
Permissions are set as part of the mkdir/open/mkfifo call, so they are
set immediately when the file is created. but ownership is adjusted
separately by calling chown/fchown/lchown.
At a high level, checkpath looks like this:
1. Creating and setting permissions.
a. If the file doesn't exist, set the permissions when it is created.
b. If the file does exist, only fix the permissions if necessary.
c. At this point, the file's permissions are correct.
2. setting ownership
a. always set the ownership if the file's ownership doesn't match the
specified ownership.
It looks like we can't use your --as suggestion if we want to be
able to create paths in /var/lib and /var/spool that are owned by
non-privileged users because of the permissions on those paths. It is
possible that service scripts are doing this.
Is it worth changing the algorithm to do this instead:
0. test for existance by opening a read-only file descriptor to this
file.
1. Creating the file/directory/fifo.
a. If it doesn't exist, create it -- note that I'm not setting
permissions with the create call.
b. Open a read-only file descriptor that attaches to the newly created
file.
2. Setting Permissions.
a. Fix the permissions of the file if necessary.
3. setting ownership
a. Set the ownership if it doesn't match the specified ownership.
> Risk #2: Instead consider a four-component path /run/foo/bar/baz. If you
> start creating those directories with owner "foo", then when you get to
> creating "baz", it's possible that "bar" has been replaced by a symlink
> somewhere else.
=20
It is possible, sure, but the question I would ask is, could this also
be a legit situation where a user would want /run/foo/bar to be a
symlink to some other location? If it is, there's no way to tell the
difference.
> Certain tricks exist to avoid that, but I'm not an expert on them and I
> don't know how portable or secure they really are. For example, you
> might get the descriptor of "bar" and then use openat(dirfd,...) instead
> of open(...) to create "baz".
>=20
> If both of those can be solved portably, then all you have to worry
> about is everything I haven't thought of =3D)
Thoughts?
William
--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCWmKKaQAKCRBuVBb0MMRl
OHHLAJ9zeP245ib8NMO9ld71SyfnbSk7BgCfewkprVkfrpy/sBIPrXxyj5FNflQ=
=Bpml
-----END PGP SIGNATURE-----
--dDRMvlgZJXvWKvBx--