14 ms·

On the other hand, the 'everything is a file' paradigm does sometimes cause issues where you can make kernels crash by doing unexpected things with them. - mac

On the other hand, the 'everything is a file' paradigm does sometimes cause issues where you can make kernels crash by doing unexpected things with them. - macOS could once easily be panicked by calling something like fpathconf() on a message queue. - If you want to have fun, try calling revoke(2) on character devices that are not TTYs. I remember fixing a bug in FreeBSD once, where you could make the system panic by calling that function on /dev/bpf.

himinlomax 6y ago
On the other hand, having a single abstraction / entry point makes it easier to implement generic sanity checks. If you add a check for that kind of problem at the right layer, it will cover other / future interfaces. On the other hand, if you use ad-hoc system calls, any mitigation or fix will typically only cover that one specific call.
- cyphar 6y ago
  Unfortunately, generic sanity checks are often not enough. You immediately run into problems where very file-specific concepts (owner, RWX permissions) aren't sufficient to handle certain types of represented-as-files objects (such as procfs files, where privileges with regard to a process aren't accurately described through Unix DAC permissions). And then you get into some of the really hairy issues -- any user can trick a privileged program into writing or reading from any file by simply spawning a setuid program with stdio set to the file they wish to operate on. Thus, any interface which is administrative is simply unsafe to expose through the standard open/read/write interfaces -- which means that you have to come up with some alternative interface anyway.
brynet 6y ago
> If you want to have fun, try calling revoke(2) on character devices that are not TTYs. I remember fixing a bug in FreeBSD once, where you could make the system panic by calling that function on /dev/bpf. IIRC there's a lot of problems with revoke(2) on anything that's not a tty device, so on OpenBSD revoke(2) returns ENOTTY in those cases. https://github.com/openbsd/src/commit/0aefaaaa63aa6de2ea734ff2b9d0ba250d3cef5f https://github.com/openbsd/src/commit/0aefaaaa63aa6de2ea734f... https://github.com/openbsd/src/commit/205dd0b22f2c32de7bacbd784378000713599ff2 https://github.com/openbsd/src/commit/205dd0b22f2c32de7bacbd... This was discovered earlier on during pledge(2) development.

himinlomax 6y ago

On the other hand, having a single abstraction / entry point makes it easier to implement generic sanity checks. If you add a check for that kind of problem at the right layer, it will cover other / future interfaces. On the other hand, if you use ad-hoc system calls, any mitigation or fix will typically only cover that one specific call.

cyphar 6y ago
Unfortunately, generic sanity checks are often not enough. You immediately run into problems where very file-specific concepts (owner, RWX permissions) aren't sufficient to handle certain types of represented-as-files objects (such as procfs files, where privileges with regard to a process aren't accurately described through Unix DAC permissions). And then you get into some of the really hairy issues -- any user can trick a privileged program into writing or reading from any file by simply spawning a setuid program with stdio set to the file they wish to operate on. Thus, any interface which is administrative is simply unsafe to expose through the standard open/read/write interfaces -- which means that you have to come up with some alternative interface anyway.

brynet 6y ago

> If you want to have fun, try calling revoke(2) on character devices that are not TTYs. I remember fixing a bug in FreeBSD once, where you could make the system panic by calling that function on /dev/bpf. IIRC there's a lot of problems with revoke(2) on anything that's not a tty device, so on OpenBSD revoke(2) returns ENOTTY in those cases. https://github.com/openbsd/src/commit/0aefaaaa63aa6de2ea734ff2b9d0ba250d3cef5f https://github.com/openbsd/src/commit/0aefaaaa63aa6de2ea734f... https://github.com/openbsd/src/commit/205dd0b22f2c32de7bacbd784378000713599ff2 https://github.com/openbsd/src/commit/205dd0b22f2c32de7bacbd... This was discovered earlier on during pledge(2) development.