Date: Fri, 13 Mar 2026 10:08:55 +0000 From: bugzilla-noreply@freebsd.org To: chromium@FreeBSD.org Subject: [Bug 269234] www/chromium: Sandboxing cleanup and basic Capsicum support for renderer processes Message-ID: <bug-269234-28929-oVuggoO06r@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-269234-28929@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269234 Alex S <iwtcex@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |iwtcex@gmail.com, | |rnagy@FreeBSD.org --- Comment #3 from Alex S <iwtcex@gmail.com> --- As far as I can tell the cleanup part of this patch has been quietly merged quite a while ago, while the sandboxing part breaks at the first sysctl call (vm.stats.vm.v_page_count). I'm currently working on an alternative patch with the relevant libc functions being redirected a through a libpreopen-style shim to cap_sysctl and cap_net Casper services as well as the files/dirs that we open before entering sandbox. There is already a precedent for that in sandbox/linux/services/libc_interceptor.cc, so that's not some novel approach even for Chromium. All mess should be very well hidden. Bringing a yet another IPC thing (libnv) vs using native Chrome stuff is a bit regrettable, but we'll never get this done otherwise. Here's my WIP diff against the source with applied BSD patches: https://gist.github.com/shkhln/76ea1cdcfe342b39cd7fc09eb2ea0ba3 (Note that it reenables zygotes to be able to share Casper services.) Should we coordinate somehow? It might be worth splitting off zygote changes at least. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-269234-28929-oVuggoO06r>