[Qemu-commits] [qemu/qemu] 6dbb71: virtiofsd: add --rlimit-nofile=NUM option

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 6dbb716877728ce4eb51619885ef6ef4ada9565f
      
https://github.com/qemu/qemu/commit/6dbb716877728ce4eb51619885ef6ef4ada9565f
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M tools/virtiofsd/fuse_lowlevel.h
    M tools/virtiofsd/helper.c
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  virtiofsd: add --rlimit-nofile=NUM option

Make it possible to specify the RLIMIT_NOFILE on the command-line.
Users running multiple virtiofsd processes should allocate a certain
number to each process so that the system-wide limit can never be
exhausted.

When this option is set to 0 the rlimit is left at its current value.
This is useful when a management tool wants to configure the rlimit
itself.

The default behavior remains unchanged: try to set the limit to
1,000,000 file descriptors if the current rlimit is lower.

Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>


  Commit: 8c1d353d107b4fc344e27f2f08ea7fa25de2eea2
      
https://github.com/qemu/qemu/commit/8c1d353d107b4fc344e27f2f08ea7fa25de2eea2
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M tools/virtiofsd/helper.c

  Log Message:
  -----------
  virtiofsd: stay below fs.file-max sysctl value (CVE-2020-10717)

The system-wide fs.file-max sysctl value determines how many files can
be open.  It defaults to a value calculated based on the machine's RAM
size.  Previously virtiofsd would try to set RLIMIT_NOFILE to 1,000,000
and this allowed the FUSE client to exhaust the number of open files
system-wide on Linux hosts with less than 10 GB of RAM!

Take fs.file-max into account when choosing the default RLIMIT_NOFILE
value.

Fixes: CVE-2020-10717
Reported-by: Yuval Avrahami <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>


  Commit: 397ae982f4df46e7d4b2625c431062c9146f3b83
      
https://github.com/qemu/qemu/commit/397ae982f4df46e7d4b2625c431062c9146f3b83
  Author: Miklos Szeredi <address@hidden>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  virtiofsd: jail lo->proc_self_fd

While it's not possible to escape the proc filesystem through
lo->proc_self_fd, it is possible to escape to the root of the proc
filesystem itself through "../..".

Use a temporary mount for opening lo->proc_self_fd, that has it's root at
/proc/self/fd/, preventing access to the ancestor directories.

Signed-off-by: Miklos Szeredi <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>


  Commit: ace0829c0d08f0e5f1451e402e94495bc2166772
      
https://github.com/qemu/qemu/commit/ace0829c0d08f0e5f1451e402e94495bc2166772
  Author: Max Reitz <address@hidden>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  virtiofsd: Show submounts

Currently, setup_mounts() bind-mounts the shared directory without
MS_REC.  This makes all submounts disappear.

Pass MS_REC so that the guest can see submounts again.

Fixes: 5baa3b8e95064c2434bd9e2f312edd5e9ae275dc
Signed-off-by: Max Reitz <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
  Changed Fixes to point to the commit with the problem rather than
          the commit that turned it on


  Commit: a59feb483b8fae24d043569ccfcc97ea23d54a02
      
https://github.com/qemu/qemu/commit/a59feb483b8fae24d043569ccfcc97ea23d54a02
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  virtiofsd: only retain file system capabilities

virtiofsd runs as root but only needs a subset of root's Linux
capabilities(7).  As a file server its purpose is to create and access
files on behalf of a client.  It needs to be able to access files with
arbitrary uid/gid owners.  It also needs to be create device nodes.

Introduce a Linux capabilities(7) whitelist and drop all capabilities
that we don't need, making the virtiofsd process less powerful than a
regular uid root process.

  # cat /proc/PID/status
  ...
          Before           After
  CapInh: 0000000000000000 0000000000000000
  CapPrm: 0000003fffffffff 00000000880000df
  CapEff: 0000003fffffffff 00000000880000df
  CapBnd: 0000003fffffffff 0000000000000000
  CapAmb: 0000000000000000 0000000000000000

Note that file capabilities cannot be used to achieve the same effect on
the virtiofsd executable because mount is used during sandbox setup.
Therefore we drop capabilities programmatically at the right point
during startup.

This patch only affects the sandboxed child process.  The parent process
that sits in waitpid(2) still has full root capabilities and will be
addressed in the next patch.

Signed-off-by: Stefan Hajnoczi <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>


  Commit: 66502bbca37ca7a3bfa57e82cfc03b89a7a11eae
      
https://github.com/qemu/qemu/commit/66502bbca37ca7a3bfa57e82cfc03b89a7a11eae
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  virtiofsd: drop all capabilities in the wait parent process

All this process does is wait for its child.  No capabilities are
needed.

Signed-off-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>


  Commit: 6897541d902218b31eef2e8eabc74fa56618f9b3
      
https://github.com/qemu/qemu/commit/6897541d902218b31eef2e8eabc74fa56618f9b3
  Author: Peter Maydell <address@hidden>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M tools/virtiofsd/fuse_lowlevel.h
    M tools/virtiofsd/helper.c
    M tools/virtiofsd/passthrough_ll.c

  Log Message:
  -----------
  Merge remote-tracking branch 
'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200501' into staging

virtiofsd: Pull 2020-05-01 (includes CVE fix)

This set includes a security fix, other fixes and improvements.

Security fix:
The security fix is for CVE-2020-10717 where, on low RAM hosts,
the guest can potentially exceed the maximum fd limit.
This fix adds some more configuration so that the user
can explicitly set the limit.

Fixes:

Recursive mounting of the exported directory is now used in
the sandbox, such that if there was a mount underneath present at
the time the virtiofsd was started, that mount is also
visible to the guest; in the existing code, only mounts that
happened after startup were visible.

Security improvements:

The jailing for /proc/self/fd is improved - but it's something
that shouldn't be accessible anyway.

Most capabilities are now dropped at startup; again this shouldn't
change any behaviour but is extra protection.

# gpg: Signature made Fri 01 May 2020 20:06:46 BST
# gpg:                using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <address@hidden>" 
[full]
# Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A  9FA9 0516 331E BC5B FDE7

* remotes/dgilbert-gitlab/tags/pull-virtiofs-20200501:
  virtiofsd: drop all capabilities in the wait parent process
  virtiofsd: only retain file system capabilities
  virtiofsd: Show submounts
  virtiofsd: jail lo->proc_self_fd
  virtiofsd: stay below fs.file-max sysctl value (CVE-2020-10717)
  virtiofsd: add --rlimit-nofile=NUM option

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/1c47613588cc...6897541d9022