GNU bug report logs - #56359
seccomp test failures on RHEL 9.0

Previous Next

Full log

Message #42 received at 56359 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Glenn Morris <rgm <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>, 56359 <at> debbugs.gnu.org
Subject: Re: bug#56359: seccomp test failures on RHEL 9.0
Date: Tue, 18 Oct 2022 11:32:46 +0200

Am Di., 11. Okt. 2022 um 21:47 Uhr schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
>
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
> > My "fix" involved allowing all uses of clone3, which (as Philipp noted
> > in August) is problematic. I'm not sure what's being tested for, but
> > if clone3 lets you evade the checks then the test is arguably more
> > trouble than it's worth. Would marking it as :unstable lessen the
> > number of false alarms we're getting? If not, perhaps we should remove
> > it or mark it as :dont-use-unless-you-know-what-youre-doing or
> > whatever.
>
> And pidfd_open also sounds like a non-safe call (without looking at it
> closely).
>
> Skimming the tests, they seem to test pretty basic functionality in the
> seccomp area -- that is, without allowing pidfd_open/clone3, nothing
> will be able to run using the seccomp functionality.  But since those
> are somewhat unsafe, then...  what's the point?

Neither pidfd_open nor clone3 are "unsafe". The concern is that clone3
might expand its functionality to eventually allow unsafe operations
like opening network sockets, and with its interface there's no way
for a seccomp filter to prevent that. One option might be to have
clone3 return ENOSYS, if the caller falls back to clone in that case.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.