From owner-freebsd-hackers@freebsd.org Fri Mar 2 18:35:13 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 80732F3B9B2 for ; Fri, 2 Mar 2018 18:35:13 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 DF62670AB2 for ; Fri, 2 Mar 2018 18:35:12 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id i80so14678971lfg.5 for ; Fri, 02 Mar 2018 10:35:12 -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:mime-version :content-disposition:user-agent; bh=1dxE3Qt8dHrgNn3we+1wUnY+iFbnSWXkgwd2433DiVQ=; b=TiA6ON/LSWOPRzkGPyBeUkNBIX8nsYRf31P3IPCiHoZyoEAI9d4G7mBih+BnX+Mmnc 241nP5la/umil7XW2BlvBNeRMyv0aU2LbHYDbCpWWPTZi27ZdfZCguydoPtKCjjQUxAw fm/SnplR98lLxFiUaETg84E0FFiKPYXiDd9/zPN89X/lEmp7B8GxkajRLfcmszV/gP6Y /kM6QSBvzKOJeWTJN51z5LSVoIz/ggO6yRBMwPgNcRhIsFFwr5rZ3w5JHpJP689ZUKhY PT/GUWw4sqZrGpRVrmWOAareD50e/Y+sH7gcG9Ohlxb8INw53ncqOqmMpB4C/qtKSJbk f8xg== 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 :mime-version:content-disposition:user-agent; bh=1dxE3Qt8dHrgNn3we+1wUnY+iFbnSWXkgwd2433DiVQ=; b=FLogR9D7t3xSuzLuRTEcFI8uSPmL+y+hKcSuL1Vxoajh9gQwFwTl7aByABtm8U9njL hXmWGLFvk2N1tUR5rnpR/StRGm2YF94ptWXQmp2lIVlQHWCB0cH0Qc7QPe76t1e8hSMQ oDVwMHtGkXNsjusmyHZe/TBCVVbCmHokAPLJTW5ekU524oxtpRQOh6YohnAiJVmpU/HZ 7KV2MBe7b6knBogahqXTTL56HMvve0FvNe4DYQed1sefP2d3F9U7rJqxXnoCmVmh5eFe BvFc4Ekjz5N36dnNWSmfb6ujBW5zXWeT7RBloDPoHIK9DOHMzZdRUxfh0LgBXefosHi/ 7z4A== X-Gm-Message-State: AElRT7HB1FVeXnWibDzm12FUAdNza/lDxmpy72YYS3MIOWwClsY5UZJC IdAnTi40h4BbnILsGmo9AORQIFBT X-Google-Smtp-Source: AG47ELs74YI+BBaUpoJZXigch7/hFo8loE4wYpHrL0uQjUHsOjTIuZx0pnj5HfKF0TbKRBHPLHlIpg== X-Received: by 10.46.2.11 with SMTP id 11mr4747739ljc.0.1520015711508; Fri, 02 Mar 2018 10:35:11 -0800 (PST) Received: from x-wing (87-206-170-77.dynamic.chello.pl. [87.206.170.77]) by smtp.gmail.com with ESMTPSA id t28sm1446115lfd.71.2018.03.02.10.35.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 10:35:09 -0800 (PST) Sender: Mariusz Zaborski Date: Fri, 2 Mar 2018 19:35:14 +0100 From: Mariusz Zaborski To: cl-capsicum-discuss@lists.cam.ac.uk Cc: freebsd-hackers@freebsd.org Subject: unlinkfd Message-ID: <20180302183514.GA99279@x-wing> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) 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: Fri, 02 Mar 2018 18:35:13 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 d= o so we always end up in a race condition. For example when we open a file, and che= ck it with fstat, etc. then we want to unlink(2) it=E2=80=A6 but the file we a= re trying to unlink could be a different one than the one we were fstating just a moment= ago. Another reason of implementing unlinkfd(2) came to us when we were trying to sandbox some applications like: uudecode/b64decode or bspatch. It occured to us that we don=E2=80=99t have a good way of removing single files. Of co= urse we can try to determine in which directory we are in, and then open this directory= and remove a single file. It looks even more bizarre if we would think about a program which operates= on multiple files. If we would analyze a situation with two totally different directories like `/tmp` and `/home/oshogbo` we would end up with pre opening 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 impractic= al! I think that opening directories also presents some wider attack vector bec= ause 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 dire= ctory. I proposed this as well on the last Capsicum call. There was a suggestion t= hat instead of doing a single syscall maybe we should have a Casper service that will allow us to remove files. Another idea was that we should perhaps rede= sign programs to create some subdirs work on the subdirs and then remove all fil= es in this subdir. I don=E2=80=99t feel that creating a Casper service is a good = idea because we still have exactly the same issue of race condition. In my opinion creat= ing 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 su= bdir. Another way would be to have Casper service which would remove a directory = but with the risk of RC. In conclusion, I think we need syscall like unlinkfd(2), which turn out tah= t it is easy to implement. The only downside of this implementation is that we n= ot only need to provide a fd but also a path file. This is because inodes nor vnodes don=E2=80=99t contain filenames. We are comparing vnodes of the fd a= nd the given path, if they are exactly the same we remove a file. In the syscall we are = using a fd so there is no Ambient Authority because we are proving that we already have access to that file. Thanks to that the syscall can be safely used with 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 some= thing with that idea! If you are intereted in patch you can find it here: https://reviews.freebsd.org/D14567 Thanks, --=20 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 --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkD1x0xkJXVVY1Gwf38KEGuLGxWQFAlqZmVkACgkQ38KEGuLG xWSNJQ/+Om5z6D8nvxGL2xCGDx8f/0zJ+z97AkzWtEMd+YSY2nUVVif/mIp3baqY GoqpESoKEOuXugk7gYL6uEN1LqMkNwxyP7bNoIOts8yLmtflDOa44z3rWkkDlzm8 VLtz9FfmL2NBOt5z+sQrUuliMlBOhCgmZzHdb7iCmja06cGo2hERtXsOUK7nOATq 2oxLzMs827tpTVU5Y62LnbHG0wdj9qbKJW77dF7xtZjh7iZZv76uebBZzyXm79s6 wiD8HV2kc5guvZSctF+f7xcnlN0vwQcpKEAXVfrzUJgYO/spySGcNehPSjAbUTE4 BDRKC192vYxGSYkiX+nDtCYXVCj+yy52T5ikdocB8Tl6CAb+68Jmp1zNXuVo8vP2 nEr0CSVwSWTd8Y8Shz6NIjYZ6KWjVYYlbyY315R1ycu/XzLwmGnjZmVD/DCa+7z0 WWZvfHQYhhQMiu8Jp5EMLfK2VWklVAQLVp3xIANEaxoWDjpJnfNM7WmXpn3m8rcO 68pogZ4O4iNtgZ9PTbgcczw7HAYkkNsv3A1tl1KJVaTGrHSA9xMaHe37sNANK5AH thb1kl0Mjw+gcKXnKAXpy1ev30nvXzjTLAlC52WTto0Y1KJyd37p2CCyTvFsFqai DOnqxbw6ZU/8XlRegnXxxSuvEdaChWFnLfYyNexVYsUW3phPVak= =LZpw -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF--