* Jann Horn:
> But if you can't tell whether the more modern syscall failed because
> of a seccomp filter, you may be forced to retry with an older syscall
> even on systems where the new syscall works fine, and such a fallback
> may reduce security or reliability if you're trying to use some
* Mark Wielaard:
> For valgrind the issue is statx which we try to use before falling back
> to stat64, fstatat or stat (depending on architecture, not all define
> all of these). The problem with these fallbacks is that under some
> containers (libseccomp versions) they might return EPERM
* Jann Horn:
> +seccomp maintainers/reviewers
> [thread context is at
> https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/
> ]
>
> On Tue, Nov 24, 2020 at 5:49 PM Christoph Hellwig wrote:
>> On Tue, Nov 24, 2020 at 03:08:05PM +0100, Mark Wielaard wrote:
>> > For valgrind
On Tue, Nov 24, 2020 at 6:44 PM Greg KH wrote:
> On Tue, Nov 24, 2020 at 06:30:28PM +0100, Jann Horn wrote:
> > On Tue, Nov 24, 2020 at 6:15 PM Greg KH wrote:
> > > On Tue, Nov 24, 2020 at 06:06:38PM +0100, Jann Horn wrote:
> > > > +seccomp maintainers/reviewers
> > > > [thread context is at
> >
On Tue, Nov 24, 2020 at 06:30:28PM +0100, Jann Horn wrote:
> On Tue, Nov 24, 2020 at 6:15 PM Greg KH wrote:
> > On Tue, Nov 24, 2020 at 06:06:38PM +0100, Jann Horn wrote:
> > > +seccomp maintainers/reviewers
> > > [thread context is at
> > >
On Tue, Nov 24, 2020 at 6:15 PM Greg KH wrote:
> On Tue, Nov 24, 2020 at 06:06:38PM +0100, Jann Horn wrote:
> > +seccomp maintainers/reviewers
> > [thread context is at
> > https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/
> > ]
> >
> > On Tue, Nov 24, 2020 at 5:49 PM
On Tue, Nov 24, 2020 at 06:15:36PM +0100, Greg KH wrote:
> On Tue, Nov 24, 2020 at 06:06:38PM +0100, Jann Horn wrote:
> > +seccomp maintainers/reviewers
> > [thread context is at
> > https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/
> > ]
> >
> > On Tue, Nov 24, 2020 at
On Tue, Nov 24, 2020 at 06:06:38PM +0100, Jann Horn wrote:
> +seccomp maintainers/reviewers
> [thread context is at
> https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/
> ]
>
> On Tue, Nov 24, 2020 at 5:49 PM Christoph Hellwig wrote:
> > On Tue, Nov 24, 2020 at
+seccomp maintainers/reviewers
[thread context is at
https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/
]
On Tue, Nov 24, 2020 at 5:49 PM Christoph Hellwig wrote:
> On Tue, Nov 24, 2020 at 03:08:05PM +0100, Mark Wielaard wrote:
> > For valgrind the issue is statx which
* Christoph Hellwig:
> On Tue, Nov 24, 2020 at 03:08:09PM +0100, Florian Weimer wrote:
>> Do you categorically reject the general advice, or specific instances as
>> well?
>
> All of the above. Really, if people decided to use seccompt to return
> nonsensical error codes we should not work
On Tue, Nov 24, 2020 at 03:08:09PM +0100, Florian Weimer wrote:
> Do you categorically reject the general advice, or specific instances as
> well?
All of the above. Really, if people decided to use seccompt to return
nonsensical error codes we should not work around that in new kernel
ABIs.
On Tue, Nov 24, 2020 at 03:08:05PM +0100, Mark Wielaard wrote:
> For valgrind the issue is statx which we try to use before falling back
> to stat64, fstatat or stat (depending on architecture, not all define
> all of these). The problem with these fallbacks is that under some
> containers
Hi,
Just a reply to note that this isn't just an issue for glibc, but for
any program that might use linux syscalls directly (with fallbacks).
On Tue, 2020-11-24 at 13:54 +0100, Florian Weimer wrote:
>
> I agree that the standard should mandate ENOSYS, and I've just proposed
> a specification
* Christoph Hellwig:
> On Tue, Nov 24, 2020 at 01:08:20PM +0100, Florian Weimer wrote:
>> This documents a way to safely use new security-related system calls
>> while preserving compatibility with container runtimes that require
>> insecure emulation (because they filter the system call by
On Tue, Nov 24, 2020 at 01:08:20PM +0100, Florian Weimer wrote:
> This documents a way to safely use new security-related system calls
> while preserving compatibility with container runtimes that require
> insecure emulation (because they filter the system call by default).
> Admittedly, it is
* Aleksa Sarai:
> As I mentioned in the runc thread[1], this is really down to Docker's
> default policy configuration. The EPERM-everything behaviour in OCI was
> inherited from Docker, and it boils down to not having an additional
> seccomp rule which does ENOSYS for unknown syscall numbers
On 2020-11-24, Florian Weimer wrote:
> This documents a way to safely use new security-related system calls
> while preserving compatibility with container runtimes that require
> insecure emulation (because they filter the system call by default).
> Admittedly, it is somewhat hackish, but it can
* Christian Brauner:
> I'm sorry but I have some doubts about this new "rule". The idea of
> being able to reliably trigger an error for a system call other then
> EPERM might have merrit in some scenarios but justifying it via a bug in
> a userspace standard is not enough in my opinion.
>
> The
On Tue, Nov 24, 2020 at 01:08:20PM +0100, Florian Weimer wrote:
> This documents a way to safely use new security-related system calls
> while preserving compatibility with container runtimes that require
> insecure emulation (because they filter the system call by default).
> Admittedly, it is
This documents a way to safely use new security-related system calls
while preserving compatibility with container runtimes that require
insecure emulation (because they filter the system call by default).
Admittedly, it is somewhat hackish, but it can be implemented by
userspace today, for
20 matches
Mail list logo
