On Mon, Nov 02, 2020 at 03:18:24PM +0000, Daniel P. Berrangé wrote: > On Mon, Nov 02, 2020 at 04:11:44PM +0100, Philippe Mathieu-Daudé wrote: > > On 11/2/20 4:07 PM, Dr. David Alan Gilbert (git) wrote: > > > From: "Dr. David Alan Gilbert" <[email protected]> > > > > > > On ppc it looks like syslog ends up using 'send' rather than 'sendto'. > > > > > > Reference: https://github.com/kata-containers/kata-containers/issues/1050 > > > > > > Reported-by: [email protected] > > > Signed-off-by: Dr. David Alan Gilbert <[email protected]> > > > --- > > > tools/virtiofsd/passthrough_seccomp.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/tools/virtiofsd/passthrough_seccomp.c > > > b/tools/virtiofsd/passthrough_seccomp.c > > > index eb9af8265f..672fb72a31 100644 > > > --- a/tools/virtiofsd/passthrough_seccomp.c > > > +++ b/tools/virtiofsd/passthrough_seccomp.c > > > @@ -118,6 +118,7 @@ static const int syscall_whitelist[] = { > > > > > > /* Syscalls used when --syslog is enabled */ > > > static const int syscall_whitelist_syslog[] = { > > > > Is it worth restricting the syscall to POWER? > > That would be wrong, as this is needed on multiple arches. > > There is no real security benefit to restricting it either, as both > syscalls give you broadly equivalent abilities.
Restricting send to architectures where glibc slightly decreases the host kernel attack surface. I think it makes sense from a security perspective. There could be a send(2)-only bug in Linux isn't present in sendto(2). But there are other issues with seccomp - are we really sure send(2) is never called? Since we don't control the entire binary (share libraries are used, virtiofsd could be linked against another libc, etc) we may not have enough information to conclude that can be eliminated send(2). Stefan
signature.asc
Description: PGP signature
