Date: Wed, 30 Mar 2022 15:51:59 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Mathieu <sigsys@gmail.com> Cc: Baptiste Daroussin <bapt@FreeBSD.org>, freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <20220330195159.zraxrpgjcu6kcwae@mutt-hbsd> In-Reply-To: <8df2d609-0a0d-0a25-4918-a27c91c3790a@gmail.com> References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220330072210.icontj4n7hcqwtql@aniel.nours.eu> <8df2d609-0a0d-0a25-4918-a27c91c3790a@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Wed, Mar 30, 2022 at 01:52:09PM -0400, Mathieu wrote: > On 3/30/22 03:22, Baptiste Daroussin wrote: > > Hello Mathieu, > > First of all, thank you for this amazing work, leveraging the mac framework to > > build curtain is imho an excellent idea, I personnally see a curtain like > > approach as complementary to a capsicum approach rather than an antagonist > > feature, I can see many possible usage of curtains in freebsd in particular in > > the port framework! > > > Alright! > > One nice thing with the MAC approach is that many of the checks were already > carefully placed to not deviate too much from expected behavior for > applications. At first I tried to do all of the checks in namei() and this > often made syscalls fail too early with the wrong errnos and this confuses > some programs. When I figured out the right place to add the checks it was > almost always right next to a MAC check. > > Also, if I hadn't used a MAC module and added a new layer instead, you could > say that it would have been the fifth (!!!) general access control mechanism > in the kernel (after traditional UNIX, Capsicum, jails and MAC). This was > starting to feel like a bit much. So the MAC framework, it's not a perfect > fit for some of what this module wants to do but it could be worse. While I think using the MAC framework here was definitely the right choice, I also think it's important to note the one major downside of the MAC framework: function pointers. A kernel exploit could nullify one or more MAC calls by overwriting a function pointer. Additionally, in certain circumstances, a function pointer could be overwritten to point to another spot in memory. The next time the fptr is called, the originally intended code isn't executed--rather, a new code path. Again, I think using MAC here is the right way to go. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmJEtNwACgkQ/y5nonf4 4fpjAg//bFb4nturw6rSY/MpDj3mVps0OeYncRynpc+apbKI5qHIINN1fxf3mPJ5 F0Eklg1F0IJdxzTSFVy94iEPDrDi39zJyp5LW8GM4tEdtPcdVw3tHhdOUhZ/DWdh NhvSNNQ5yRANzXr8YsXIMyiHrgO+D48mcXiKD8fhrM/iXc0dPW8coNJkHiU9etQV vnxhMmch5iN6g7IS4rZOsp9mbstKD2YZVat3ETJTnwGxdD3X23WVF4tu5K9+cfvb rA4XD/ve5IcVDsZKzxt5EoSBJm3dz9KkdczP1JeiLNTK6EWm8cFLfK26weDTGM5l /YuprWGmChW0TthPZSA7jLPpdYAj2JcwM5Lo7IMGpVsxmZKqAo4ftNCkR1WzKbt+ zeycvXFsKaRL0+DxtyYzPILAg+RAHI1c/XDFewpR6uKweM5IJjsVZYQWg59GiJOP /WxdPMqLxT9Q2Df9rSZFpYa6yUt3ms4f5nuDtBdAQP3b9VE6N6t6yw17UwuCTyuC BHAPxOpoIgdkdcrx0xx0fGkASnwqBDLmKPyiSKqtmI+DBMpXbURSxhNMMVv6gNGu NvsOiJZi2JLrJJY0O/L4Z+Lvdl3gr4DtjxaAQB6/sfnNne93ASQ8NyeedLgMoowu guDbHD4PeGrTuGYx9TxY3gEY4iQr69QPRQi2Gm9aQ48s/Ixx+ps= =QZsf -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220330195159.zraxrpgjcu6kcwae>