Date: Sat, 3 Mar 2018 09:53:25 +0000 From: Justin Cormack <justin@specialbusservice.com> To: Mariusz Zaborski <oshogbo@freebsd.org> Cc: "<cl-capsicum-discuss@lists.cam.ac.uk>" <cl-capsicum-discuss@lists.cam.ac.uk>, freebsd-hackers@freebsd.org Subject: Re: [capsicum] unlinkfd Message-ID: <CAK4o1Wyk54chHobhUkb2PBUtaWOF2rDv6tkX_bFGY6D331xUqw@mail.gmail.com> In-Reply-To: <20180302183514.GA99279@x-wing> References: <20180302183514.GA99279@x-wing>
index | next in thread | previous in thread | raw e-mail
I think it would make sense to have an unlinkfd() that unlinks the file from 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 anonymous 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 <oshogbo@freebsd.org> 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’t 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 check > it with fstat, etc. then we want to unlink(2) it… but the file we are 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’t 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 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 impractical! > > I think that opening directories also presents some wider attack vector because > 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 directory. > > 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 that > will allow us to remove files. Another idea was that we should perhaps redesign > programs to create some subdirs work on the subdirs and then remove all files in > this subdir. I don’t feel that creating a Casper service is a good idea because > we still have exactly the same issue of race condition. In my opinion creating > 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 directory but > with the risk of RC. > > In conclusion, I think we need syscall like unlinkfd(2), which turn out taht 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 nor > vnodes don’t 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 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…` so let’s do something 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!!1help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK4o1Wyk54chHobhUkb2PBUtaWOF2rDv6tkX_bFGY6D331xUqw>