On Thu, Feb 13, 2025 at 07:59:48PM +0000, Pedro Falcato wrote: > On Wed, Feb 12, 2025 at 2:02 PM Lorenzo Stoakes > <lorenzo.stoakes@xxxxxxxxxx> wrote: > > > > (sorry I really am struggling to reply to mail as lore still seems to be > > broken). > > > > On Wed, Feb 12, 2025 at 12:37:50PM +0000, Pedro Falcato wrote: > > > On Wed, Feb 12, 2025 at 11:25 AM Lorenzo Stoakes > > > <lorenzo.stoakes@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Feb 12, 2025 at 03:21:48AM +0000, jeffxu@xxxxxxxxxxxx wrote: > > > > > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > > > > > > > > > > The commit message in the first patch contains the full description of > > > > > this series. > > > > > > [...] > > > > > > FWIW, although it would (at the moment) be hard to pull off in the > > > libc, I still much prefer it to playing these weird games with CONFIG > > > options and kernel command line options and prctl and personality and > > > whatnot. It seems to me like we're trying to stick policy where it > > > doesn't belong. > > > > The problem is, as a security feature, you don't want to make it trivially > > easy to disable. > > > > I mean we _need_ a config option to be able to strictly enforce only making > > the feature enable-able on architectures and configuration option > > combinations that work. > > > > But if there is userspace that will be broken, we really have to have some > > way of avoiding the disconnect between somebody making policy decision at > > the kernel level and somebody trying to run something. > > > > Because I can easily envision somebody enabling this as a 'good security > > feature' for a distro release or such, only for somebody else to later try > > rr, CRIU, or whatever else and for it to just not work or fail subtly and > > to have no idea why. > > Ok so I went looking around for the glibc patchset. It seems they're > moving away from tunables and there was a nice > GNU_PROPERTY_MEMORY_SEAL added to binutils. > So my proposal is to parse this property on the binfmt_elf.c side, and > mm would use this to know if we should seal these mappings. This seems > to tackle compatibility problems, > and glibc isn't sealing programs without this program header anyway. Thoughts? It seems to me that doing this ties it to the binary, rather than execution context, which may want to seal/not-seal, etc. I have a sense that it's be better as a secure bit, or prctl, or something like that. The properties seem to be better suited for "this binary _can_ do a thing" or "this binary _requires_ a thing", like the GNU_STACK bits, etc. But maybe there's more to this I'm not considering? > > I mean one option is to have it as a CONFIG_ flag _and_ you have to enable > > it via a tunable, so then it can become sysctl.d policy for instance. > > sysctl is also an option but the idea of dropping a random feature > behind a CONFIG_ that's unusable by lots of people (including the > general GNU/Linux ecosystem) is really really unappealing to me. I agree 100%, but I think we need to make small steps. Behind a CONFIG means we get it implemented, and then we can look at how to make it more flexible. I'm motivated to figure this out because I've long wanted to have a boot param to disable CRIU since I have distro systems that I don't use CRIU on, and I don't want the (very small) interface changes it makes available into seccomp filter visibility. And if CRIU could be run-time based, so could system mapping sealing. :) -- Kees Cook
