Re: [PATCH] virtiofsd: Seccomp: Add 'send' for syslog

[Stefan Hajnoczi]

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" <dgilbert@redhat.com>
> > > 
> > > 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: amulmek1@in.ibm.com
> > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > ---
> > >  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