Control: close On Thu, 19 Mar 2026 16:24:57 +0000 Nikolas Kyx <[email protected]> wrote:
> > I'm not sure if this is a coincidence, but I suppose you tried this in > > the wake of the CrackArmor disclosure last week. > > I like to build stripped-down kernels on different hardwares, those > fit my needs and not more. All desktop applications work fine but do > not benefit from e.g. bubblewrap (which is installed as a dependency > and tries to do its job). But yes, it may be related to CrackArmor, > since that all is about mediating risks between <unprivileged userns > clone, kernel API is in danger> and <user applications can't do > userns clone, no isolation between them>. I would prefer the former, > since stripped down kernels hide less bugs in them :) I see your point and I guess it's valid in the vast majority of cases, but you can definitely have non-negative amounts of code, in some other cases, that improve security rather than making it worse. I (still) think that namespaces are examples of that. Of course in the past years additional kernel surface was exposed because of them (and I'm myself at fault for CVE-2022-2078, for example) but I'd ascribe that to novelty rather than to some intrinsic quality of that code. That is, the longer it's exposed, the more secure it gets (as a general trend at least). Just like everything else. > Btw, no apparmor in my system either. > > When I was creating an issue, I mistakenly thought that it's just that > single check which did not recognize the possibility of missing > CONFIG_USERNS. But when adapting passt code for local build, I > realized that USERNS is explicitly mandatory and there is no mistake. > I think that for things like userns / seccomp / etc it is normal to > emit big fat warning when some mechanism is not available - if those > are required exclusively from a security viewpoint. Sometimes, yes. But I would argue that, in general, this isn't exactly an incentive to fix things, should some security mechanism be unavailable or unusable due to other issues. We had users in particular environments (KubeVirt is an example) who asked us to add options to disable passt's seccomp profile. By not giving in, things were fixed, eventually, and passt now runs with its strict seccomp profile on any environments I'm aware of. > I tested passt > with all userns-dependent code (as you described in (a)) removed and > it works just fine. Though if you want to depend on that features > unconditionally I understand since checking itself may open exploit > possibilities. It's a bit about checking, and a bit about discouraging potentially insecure shortcuts. Sure, if you disable user namespaces you make some things a bit more secure, but, especially without LSMs, if you skip filesystem sandboxing, passt now gets have access to your filesystem, and, with passt, also the guest, in case of arbitrary code execution. I would suggest that you run your own tailored build in this case. You know what you're doing and you're doing it for a very specific reason, but I don't want to risk having unreported issues. For example: https://passt.top/passt/commit/?id=faab79cfd56a if we had just skipped isolation features based on user namespaces, we wouldn't have found out about this, at least for a while, and kept those features disabled as a result, with user namespaces available in general on the system. > Then you may just close that issue. I just did. Thanks for following up with your usage and reasoning! -- Stefano
