This bug is for investigating if it is feasible to restrict ioctl() arguments using seccomp-bpf on Linux desktop. icotl() is a very powerful system call and restricting its arguments would reduce the attack surface this system call exposes.

In particular, tty ioctls could be a problem — e.g., TIOCSTI (“Simulate Typed Input”) can inject arbitrary text into the terminal's input buffer, including shell commands. This is a known problem for other sandboxes: http://www.openwall.com/lists/oss-security/2016/10/25/9 Unfortunately, we can't get rid of ioctl completely as long as we have GPU drivers in the content process. And I don't even know how feasible it would be to change it to a default-deny policy (although if the kernel interface situation is that everything is either DRI or Nvidia, then maybe). But we should at least be able block the entire 'T' class of ioctls (i.e., xxxx54xx in hex).

(In reply to Jed Davis [:jld] {⏰UTC-7} from comment #1) > Unfortunately, we can't get rid of ioctl completely as long as we have GPU > drivers in the content process. And I don't even know how feasible it would > be to change it to a default-deny policy (although if the kernel interface > situation is that everything is either DRI or Nvidia, then maybe). However, if there are other GPU interfaces besides those two, we'll probably have to explicitly allow them in the file broker policy (where “probably” becomes “definitely” once we stop having a default-allow policy for reads) before ioctls can be a concern. For reference, DRI uses 'd' (0x64) and Nvidia seems to use 'F' (0x46).

nvidia is more complicated than that; on GL startup I'm seeing it open /dev/nvidia-modesetting and do an ioctl with type 0x6d ('m'). I also took a look at nvidia's OpenCL driver (because we're seeing media codec libraries try to use it, and it might share infrastructure with advanced GL features). Just running the "clinfo" utility opens /dev/nvidia-uvm and uses ioctls of types 0x00 and 0x07. So it might be best to just block the 'T' ioctls for now, because that's a few lines of code and fairly safe and will stop some known issues, and file a followup bug to lock this down more.

From the upstream issue linked in bug 1384292, it looks like they're going to keep doing the ioctls (i.e., fix the “broken” but not the “useless”). I could just fail the SIOCGIF* family with EPERM instead and that should unblock the rest of this.