mirrors/crosvm
1
0
Fork 0
mirror of https://chromium.googlesource.com/crosvm/crosvm synced 2024-12-01 04:28:48 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
crosvm/seccomp/x86_64/fs_device.policy

49 lines
930 B
Text
Raw Normal View History

Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
# Copyright 2019 The Chromium OS Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
@include /usr/share/policy/crosvm/common_device.policy
devices: fs: Implement copy_file_range BUG=none TEST=vm.Virtiofs Change-Id: I2ed7137a901e6e506e6b1562b77fdb042bdc58ab Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2105822 Tested-by: Chirantan Ekbote <chirantan@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2020-03-17 09:20:10 +00:00
copy_file_range: 1
seccomp: Add missing syscalls to fs device policy BUG=none TEST=`tast run <dut> vm.Fio.virtiofs` Change-Id: I937df0be738e0aa302a4ad3e87ed33ff97afb4fc Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2089174 Tested-by: Chirantan Ekbote <chirantan@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Auto-Submit: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2020-03-05 06:29:41 +00:00
fallocate: 1
fs: Don't use path-based operations There are no *at variants for the xattr syscalls so we were using the path-based variants by reading the /proc/self/fd symlink. While this symlink can track renames it cannot track if the user hard links the file to some other location and then unlinks the original location. In this case the symlink simply shows that the path was deleted even though the fd is still valid. To deal with this, stop using the path-based method. For regular files and directories, we can simply open them and then make the appropriate f{get,set,list,remove}xattr syscall. For non-regular files and directories we can emulate an *at syscall by changing the CWD to /proc and then making the path-based syscall via the self/fd path. Even though the symlink is no longer valid, manipulating the fd via this path still works. BUG=b:168689429 TEST=Create a file, set an xattr, hard link it to a new location, unlink the original, and then verify that {get,set}fattr still works on the new link Change-Id: Ic291f432b96f18e3e7ccbcf27737d5f8fd240a65 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2437684 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2020-09-29 07:54:17 +00:00
fchdir: 1
devices: fs: Use 2 stage create and mkdir When creating a file or directory the virtio-fs server changes its effective uid and gid to the uid and gid of the process that made the call. This ensures that the file or directory has the correct owner and group when it is created and also serves as an access check to ensure that the process that made the call has permission to modify the parent directory. However, this causes an EACCES error when the following conditions are met: * The parent directory has g+rw permissions with gid A * The process has gid B but has A in its list of supplementary groups In this case the fuse context only contains gid B, which doesn't have permission to modify the parent directory. Unfortunately there's no way for us to detect this on the server side so instead we just have to rely on the permission checks carried out by the kernel driver. If the server receives a create call, then assume that the kernel has verified that the process is allowed to create that file/directory and just create it without changing the server thread's uid and gid. Additionally, in order to ensure that a newly created file appears atomically in the parent directory with the proper owner and group, change the create implementation to use `O_TMPFILE` and `linkat` as described in the open(2) manpage. There is no `O_TMPFILE` equivalent for directories so create a "hidden" directory with a randomly generated name, modify the uid/gid and mode, and then rename it into place. BUG=b:156696212 TEST=tast run $DUT vm.Virtiofs TEST=Create a test directory with group wayland and permissions g+rw. Then run `su -s /bin/bash -c 'touch ${dir}/foo' - crosvm` and `su -s /bin/bash -c 'mkdir ${dir}/bar' - crosvm`. Change-Id: If5fbcb1b011664c7c1ac29542a2f90d129c34962 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2217534 Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org> Tested-by: Chirantan Ekbote <chirantan@chromium.org>
2020-05-27 08:18:07 +00:00
fchmod: 1
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
fchmodat: 1
devices: fs: Use 2 stage create and mkdir When creating a file or directory the virtio-fs server changes its effective uid and gid to the uid and gid of the process that made the call. This ensures that the file or directory has the correct owner and group when it is created and also serves as an access check to ensure that the process that made the call has permission to modify the parent directory. However, this causes an EACCES error when the following conditions are met: * The parent directory has g+rw permissions with gid A * The process has gid B but has A in its list of supplementary groups In this case the fuse context only contains gid B, which doesn't have permission to modify the parent directory. Unfortunately there's no way for us to detect this on the server side so instead we just have to rely on the permission checks carried out by the kernel driver. If the server receives a create call, then assume that the kernel has verified that the process is allowed to create that file/directory and just create it without changing the server thread's uid and gid. Additionally, in order to ensure that a newly created file appears atomically in the parent directory with the proper owner and group, change the create implementation to use `O_TMPFILE` and `linkat` as described in the open(2) manpage. There is no `O_TMPFILE` equivalent for directories so create a "hidden" directory with a randomly generated name, modify the uid/gid and mode, and then rename it into place. BUG=b:156696212 TEST=tast run $DUT vm.Virtiofs TEST=Create a test directory with group wayland and permissions g+rw. Then run `su -s /bin/bash -c 'touch ${dir}/foo' - crosvm` and `su -s /bin/bash -c 'mkdir ${dir}/bar' - crosvm`. Change-Id: If5fbcb1b011664c7c1ac29542a2f90d129c34962 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2217534 Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org> Tested-by: Chirantan Ekbote <chirantan@chromium.org>
2020-05-27 08:18:07 +00:00
fchown: 1
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
fchownat: 1
seccomp: Add missing syscalls to fs device policy BUG=none TEST=`tast run <dut> vm.Fio.virtiofs` Change-Id: I937df0be738e0aa302a4ad3e87ed33ff97afb4fc Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2089174 Tested-by: Chirantan Ekbote <chirantan@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Auto-Submit: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2020-03-05 06:29:41 +00:00
fdatasync: 1
fs: Don't use path-based operations There are no *at variants for the xattr syscalls so we were using the path-based variants by reading the /proc/self/fd symlink. While this symlink can track renames it cannot track if the user hard links the file to some other location and then unlinks the original location. In this case the symlink simply shows that the path was deleted even though the fd is still valid. To deal with this, stop using the path-based method. For regular files and directories, we can simply open them and then make the appropriate f{get,set,list,remove}xattr syscall. For non-regular files and directories we can emulate an *at syscall by changing the CWD to /proc and then making the path-based syscall via the self/fd path. Even though the symlink is no longer valid, manipulating the fd via this path still works. BUG=b:168689429 TEST=Create a file, set an xattr, hard link it to a new location, unlink the original, and then verify that {get,set}fattr still works on the new link Change-Id: Ic291f432b96f18e3e7ccbcf27737d5f8fd240a65 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2437684 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2020-09-29 07:54:17 +00:00
fgetxattr: 1
getxattr: 1
fsetxattr: 1
setxattr: 1
flistxattr: 1
listxattr: 1
fremovexattr: 1
removexattr: 1
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
fstatfs: 1
seccomp: Add missing syscalls to fs device policy BUG=none TEST=`tast run <dut> vm.Fio.virtiofs` Change-Id: I937df0be738e0aa302a4ad3e87ed33ff97afb4fc Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2089174 Tested-by: Chirantan Ekbote <chirantan@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Auto-Submit: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2020-03-05 06:29:41 +00:00
fsync: 1
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
ftruncate: 1
getdents64: 1
getegid: 1
geteuid: 1
devices: fs: Fix posix acl handling Posix acls are a truly incredible example of API design. The presence of a default posix acl in a directory completely changes the meaning of the `mode` parameter for all system call that create inodes. However, this new behavior only applies when the inode is first created and not for any subsequent operations that use the mode, like fchmod. When a directory has a default posix acl, all inodes created in that directory get the permissions specified in the default acl. The mode parameter is treated like a umask where any permissions allowed by the default acl that are not allowed by the mode parameter are blocked. The actual umask is ignored in this case. So to handle this properly we need to set FUSE_DONT_MASK to prevent the kernel driver from preemptively applying the umask. Then we have to check if the parent directory has a default posix acl and only apply the umask to the mode if it does not. This also means that we cannot use `mkdtemp` because that always creates directories with a mode of 0o700 and since the default posix acl calculation only applies on creation and not on later operations, we need to apply the proper mode in the very beginning. BUG=b:159285544,b:152806644 TEST=vm.Virtiofs. Use a test program to create files/directories in directories that have a default acl and ones that don't, and verify that the mode is correctly set after creation Change-Id: Ieca8ac9db391feebe5719630c5f3b57b04b71533 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2260253 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org> Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
2020-06-23 08:12:03 +00:00
getrandom: 1
devices: fs: Support FS_IOC_{GET,SET}FLAGS Needed by arcvm. BUG=b:159870893 TEST=`lsattr foo` and `chattr +S foo` inside a VM. Check with strace that it's making the ioctl. Cq-Depend: chromium:2297090 Change-Id: I11b490062b3c777c0cf4543f3d09f94e3790453b Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2297004 Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: Chirantan Ekbote <chirantan@chromium.org> Commit-Queue: Lepton Wu <lepton@chromium.org>
2020-07-14 09:50:13 +00:00
ioctl: arg1 == FS_IOC_GET_ENCRYPTION_POLICY || arg1 == FS_IOC_SET_ENCRYPTION_POLICY || arg1 == FS_IOC_FSGETXATTR || arg1 == FS_IOC_FSSETXATTR || arg1 == FS_IOC_GETFLAGS || arg1 == FS_IOC_SETFLAGS
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
linkat: 1
lseek: 1
devices: fs: Use 2 stage create and mkdir When creating a file or directory the virtio-fs server changes its effective uid and gid to the uid and gid of the process that made the call. This ensures that the file or directory has the correct owner and group when it is created and also serves as an access check to ensure that the process that made the call has permission to modify the parent directory. However, this causes an EACCES error when the following conditions are met: * The parent directory has g+rw permissions with gid A * The process has gid B but has A in its list of supplementary groups In this case the fuse context only contains gid B, which doesn't have permission to modify the parent directory. Unfortunately there's no way for us to detect this on the server side so instead we just have to rely on the permission checks carried out by the kernel driver. If the server receives a create call, then assume that the kernel has verified that the process is allowed to create that file/directory and just create it without changing the server thread's uid and gid. Additionally, in order to ensure that a newly created file appears atomically in the parent directory with the proper owner and group, change the create implementation to use `O_TMPFILE` and `linkat` as described in the open(2) manpage. There is no `O_TMPFILE` equivalent for directories so create a "hidden" directory with a randomly generated name, modify the uid/gid and mode, and then rename it into place. BUG=b:156696212 TEST=tast run $DUT vm.Virtiofs TEST=Create a test directory with group wayland and permissions g+rw. Then run `su -s /bin/bash -c 'touch ${dir}/foo' - crosvm` and `su -s /bin/bash -c 'mkdir ${dir}/bar' - crosvm`. Change-Id: If5fbcb1b011664c7c1ac29542a2f90d129c34962 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2217534 Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org> Tested-by: Chirantan Ekbote <chirantan@chromium.org>
2020-05-27 08:18:07 +00:00
mkdir: 1
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
mkdirat: 1
mknodat: 1
newfstatat: 1
seccomp: remove redundant unconditional rules Minijail's policy compiler complains when there's multiple unconditional rules for a syscall. In most cases the rules are redundant to common_device.policy. I don't know what to do about the intentionally contradictory rules for open and openat, other than to remove then from the common device policy and add it to all the others. BUG=None TEST=Ran compile_seccomp_policy.py until it stopped complaining. Change-Id: I6813dd1e0b39e975415662bd7de74c25a1be9eb3 Signed-off-by: Matt Delco <delco@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1918607 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2019-11-15 01:48:44 +00:00
open: return ENOENT
openat: 1
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
preadv: 1
pwritev: 1
readlinkat: 1
renameat2: 1
setresgid: 1
setresuid: 1
symlinkat: 1
seccomp: allow statx syscall where stat/fstat was allowed This is used in Rust 1.40.0's libstd in place of stat/fstat; update the whitelists to allow the new syscall as well. BUG=chromium:1042461 TEST=`crosvm disk resize` does not trigger seccomp failure Change-Id: Ia3f0e49ee009547295c7af7412dfb5eb3ac1efcb Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2003685 Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
2020-01-15 21:34:09 +00:00
statx: 1
Enable seccomp for virtio-fs Add x86_64 and arm seccomp policy files for the virtio-fs device. BUG=b:136128319 TEST=Run a vm with a sandboxed virtio-fs device Change-Id: I8ea7c5d3e90696077f0c2b1f942cb286a0b36cf4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1916559 Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2019-11-14 09:45:56 +00:00
umask: 1
unlinkat: 1
utimensat: 1
Reference in a new issue Copy permalink