From owner-freebsd-hackers@freebsd.org Sat Mar 3 09:53:27 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BE45F2BE72 for ; Sat, 3 Mar 2018 09:53:27 +0000 (UTC) (envelope-from justin@specialbusservice.com) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26E8377FB9 for ; Sat, 3 Mar 2018 09:53:27 +0000 (UTC) (envelope-from justin@specialbusservice.com) Received: by mail-vk0-x229.google.com with SMTP id t126so7143247vkb.11 for ; Sat, 03 Mar 2018 01:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=specialbusservice.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OMHDWcJR+ZNc7+qiSY1kzOvqmZVsR68yYjd4B0GBmpE=; b=GJG8yaFaicDaMbt08IHRK1gDRaVeRDSaz1Jzwk0vDrUx+vE+dWyWnaUqFeJHrilPLT 4jiHS0Gvd+dAryGn3LDGN75UUjExpFJjg78I04wIJj3OoSZcAwzt0e8b1l7zqPDPdvNe s6cQtjnHmuxCW3cWHpiG0HDXagkhZP5XUASsU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OMHDWcJR+ZNc7+qiSY1kzOvqmZVsR68yYjd4B0GBmpE=; b=FSgzFh4lGS0x0IVVRQvi2uy0EGaN8wrfqVaUp4+DeziIPUpOrdic9a9AgVxz328VIt nQNix24Vw3dBhMbfOpbGkjUEsXYrxgNKwO27savDxCirFYMjfP51fBgp/UQwlqIWC12x 1/E/mFINO4ipgobP71mtG1Nl5EyYT1+Ac9OAiN5rHzzVos86/ru7lhFntpgyCJsLCbME 2uPKtS90bXEA1CTo5yN2VpxUBo5kdzQJmSgS+93W43isx/URlzPdz3PD1F5K/RvNSwtI WjPpCIn5pmxhH0uSwwfSZI//L82ATcU6tl/unw8WcaG6bTWCz1wnBv/XLj/8I5x3gZq8 4t2A== X-Gm-Message-State: APf1xPD/7r5OLnVjideKMkELYXgVu0dbYXAvK18fMYE2WiB5QnzioELf AaDFZojlon968cCGurmm01VaeiRpV7D5rFlD0VvhPA== X-Google-Smtp-Source: AG47ELuKmA9wUBGB6aGqaAKkDEtrUKIU/o75hHOQX+P7/c2JBherxn893ug67syrCnCaTzIOH8Axv3Z281ZZ+ICUIvU= X-Received: by 10.31.242.75 with SMTP id q72mr5716632vkh.188.1520070806355; Sat, 03 Mar 2018 01:53:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.2.81 with HTTP; Sat, 3 Mar 2018 01:53:25 -0800 (PST) In-Reply-To: <20180302183514.GA99279@x-wing> References: <20180302183514.GA99279@x-wing> From: Justin Cormack Date: Sat, 3 Mar 2018 09:53:25 +0000 Message-ID: Subject: Re: [capsicum] unlinkfd To: Mariusz Zaborski Cc: "" , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 03 Mar 2018 13:27:55 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 09:53:27 -0000 I think it would make sense to have an unlinkfd() that unlinks the file fro= m everywhere, so it does not need a name to be specified. This might be hard to implement. For temporary files, I really like Linux memfd_create(2) that opens an anon= ymous file without a name. This semantics is really useful. (Linux memfd also has additional options for sealing the file fo make it immutable which are very useful for safely passing files between processes.) Having a way to make unnamed temporary files solves a lot of deletion issues as the file never needs to be unlinked. On 2 March 2018 at 18:35, Mariusz Zaborski wrote: > Hello, > > Today I would like to propose a new syscall called unlinkfd(2) which came= up > during a discussion with Ed Maste. > > Currently in UNIX we can=E2=80=99t remove files safely. If we will try to= do so we > always end up in a race condition. For example when we open a file, and c= heck > it with fstat, etc. then we want to unlink(2) it=E2=80=A6 but the file we= are trying to > unlink could be a different one than the one we were fstating just a mome= nt ago. > > Another reason of implementing unlinkfd(2) came to us when we were trying > to sandbox some applications like: uudecode/b64decode or bspatch. It occu= red > to us that we don=E2=80=99t have a good way of removing single files. Of = course we can > try to determine in which directory we are in, and then open this directo= ry and > remove a single file. > > It looks even more bizarre if we would think about a program which operat= es on > multiple files. If we would analyze a situation with two totally differen= t > directories like `/tmp` and `/home/oshogbo` we would end up with pre open= ing > a root directory or keeping as many directories as we are working on open= . > All of that effort only to remove two files. This make it totally impract= ical! > > I think that opening directories also presents some wider attack vector b= ecause > we are keeping a single descriptor to a directory only to remove one file= . > Unfortunately this means that an attacker can remove all files in that di= rectory. > > I proposed this as well on the last Capsicum call. There was a suggestion= that > instead of doing a single syscall maybe we should have a Casper service t= hat > will allow us to remove files. Another idea was that we should perhaps re= design > programs to create some subdirs work on the subdirs and then remove all f= iles in > this subdir. I don=E2=80=99t feel that creating a Casper service is a goo= d idea because > we still have exactly the same issue of race condition. In my opinion cre= ating > subdirs is also a problem for us. > > First we would need to redesign some of our tools and I think we should > simplyfiy capsicumizition of the process instead of making it harder. > > Secondly we can create a temporary subdirectory but what will remove it? > We are going back to having a fd to directory in which we just created a = subdir. > Another way would be to have Casper service which would remove a director= y but > with the risk of RC. > > In conclusion, I think we need syscall like unlinkfd(2), which turn out t= aht it > is easy to implement. The only downside of this implementation is that we= not > only need to provide a fd but also a path file. This is because inodes no= r > vnodes don=E2=80=99t contain filenames. We are comparing vnodes of the fd= and the given > path, if they are exactly the same we remove a file. In the syscall we ar= e using > a fd so there is no Ambient Authority because we are proving that we alre= ady > have access to that file. Thanks to that the syscall can be safely used w= ith > Caspsicum. I have already discussed this with some people and they said > `Hey I already had that idea a while ago=E2=80=A6` so let=E2=80=99s do so= mething with that idea! > If you are intereted in patch you can find it here: > https://reviews.freebsd.org/D14567 > > Thanks, > -- > Mariusz Zaborski > oshogbo//vx | http://oshogbo.vexillium.org > FreeBSD commiter | https://freebsd.org > Software developer | http://wheelsystems.com > If it's not broken, let's fix it till it is!!1