Date: Fri, 2 Mar 2018 19:35:14 +0100 From: Mariusz Zaborski <oshogbo@FreeBSD.org> To: cl-capsicum-discuss@lists.cam.ac.uk Cc: freebsd-hackers@freebsd.org Subject: unlinkfd Message-ID: <20180302183514.GA99279@x-wing>
next in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180302183514.GA99279>