On Thu, Sep 24, 2020 at 6:56 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > This file is guarded by CONFIG_PROC_SECCOMP_CACHE with a default > The question of permissions is my central concern here: who should see > this? Some contained processes have been intentionally blocked from > self-introspection so even the "standard" high bar of "ptrace attach > allowed?" can't always be sufficient. > > My compromise about filter visibility in the past was saying that > CAP_SYS_ADMIN was required (see seccomp_get_filter()). I'm nervous to > weaken this. (There is some work that hasn't been sent upstream yet that > is looking to expose the filter _contents_ via /proc that has been > nervous too.) > > Now full contents vs "allow"/"filter" are certainly different things, > but I don't feel like I've got enough evidence to show that this > introspection would help debugging enough to justify the partially > imagined safety of not exposing it to potential attackers. Agreed. I'm inclined to make it CONFIG_DEBUG_SECCOMP_CACHE and guarded by a CAP just to make it "debug only". > I suspect it _is_ the right thing to do (just look at my own RFC's > "debug" patch), but I'd like this to be well justified in the commit > log. > > And yes, while it does hide behind a CONFIG, I'd still want it justified, > especially since distros have a tendency to just turn everything on > anyway. ;) Is there something to stop a config from being enabled in an allyesconfig? I remember seeing something like that. Else if someone is manually selecting we can add a help text with a big banner... > But behavior-wise, yeah, I like it; I'm fine with human-readable and > full AUDIT_ARCH values. (Though, as devil's advocate again, to repeat > Jann's own words back: do we want to add this only to have a new UAPI to > support going forward?) Is this something we want to keep stable? YiFei Zhu
