Linux's syscall list is out of control. The many BSDs have managed to keep it more reasonable.
The last time I checked, FreeBSD's list of system calls was larger than Linux's. This is because Linux tends to expose more functionality through sysfs, procfs, ioctl, while FreeBSD uses dedicated system calls.
https://filippo.io/linux-syscall-table/ <- max = 313
https://github.com/freebsd/freebsd/blob/master/sys/kern/sysc... <- max = 576, 356 marked 'STD'
And of course, as with everything else, virtually all this new functionality is modular. Don't want the system call (or whatever)? Don't put it in your kernel.
Basically: you're wrong here. Cite the specific functionality you think is being shipped in an insecure way.
- 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.
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.
This was discovered earlier on during pledge(2) development.
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.
Will finish and republish in a few days.
The typefaces are close enough though that it is quite difficult to notice the difference.