Date: Thu, 31 Mar 2022 15:33:06 -0400 From: Ed Maste <emaste@freebsd.org> To: David Chisnall <theraven@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <CAPyFy2BCpdzP=68r19UpazCmEPft7ZK52qmZFb2Ohjw8Jf14OQ@mail.gmail.com> In-Reply-To: <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Mar 2022 at 06:25, David Chisnall <theraven@freebsd.org> wrote: > > Capsicum simply disallows '..' in paths. This is no longer true as of 7359fdcf5ffa. During a lookup the kernel checks that each ".." component specifies a directory that has already been visited in this name lookup call. > The execve hole is the reason that I have little interest in pledge as > an enforcement mechanism. Note that execve is only available if the "exec" keyword is specified. The child does not inherit the parent's limits, though.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2BCpdzP=68r19UpazCmEPft7ZK52qmZFb2Ohjw8Jf14OQ>