If you want to fix UNIX security issues related to C, first you need to convince kernel developers across all UNIX variants to move away from C.

Then even a fully modernized UNIX kernel needs to provide support to unsafe POSIX APIs.

But, Linus et al still love C...

Write your own out-of-tree Rust modules if you like, but they'll never be merged in.

But the codebase numbers in the 100's of millions of LOC, and replacing that with Rust (or anything else for that matter) will come with a number of requirements:

- it really needs to be better in terms of bugs

- it needs to be about as fast or faster

- it would have to come with similar start-up times for the runtime

- you'd need to find funding somewhere or convince people the need is so high they should volunteer their time

For a single individual this is likely not a viable project, even doing just the basics (coreutils) would take you a couple of years at a minimum.

What might be a better way is to reboot unix entirely starting from the kernel and working your way up into userland.

There is plenty there that could use a more modern look at things, after all UNIX really is showing its age and LINUX is a re-implementation of something that was already old when it was started.

POSIX is defined in terms of C semantics, which includes C unsafety, like managing pointers and the respective length as separate entities, using null terminated strings or casting void* to specific data structures.

Which means the POSIX translation layer would need some sprinkles of unsafe code to be able to comply with the required semantics, thus opening it to the same exploits as C code.

This issue is visible in OS that aren't written in C, but do expose POSIX runtime layers like mainframes.

As mainframes, they usually restrict possible security exploits thanks to running POSIX applications on their own containers or enclaves.

For larger, and legacy project, maintainability and continuity is the overwhelmingly top priority, being flashy is the least of their concern.

http://www.minix3.org/

https://en.wikipedia.org/wiki/XNU

https://en.wikipedia.org/wiki/Mach_(kernel)

https://en.wikipedia.org/wiki/L4_microkernel_family

I think rust opens the door to designing kernels that are small and tight with most of the OS stuff that was traditionally in kernel space moved into user space.

Note the types of vulnerabilities and the languages they use. DoS, File Inclusion, XSS, Exec Code, Dir Traversal, Priv Escalation, SQLI, Bypass, CSRF, Info leak, etc.

Many of them (including ones in C) have nothing to do with memory protection. Those that do (null pointer deref, use-after-free, memory leak, buffer overflow, etc) are all trivially protected with small kernel patches that have been around for 17 years, and of course most of these vulns would become trivial with proper mandatory access control. But for reasons that completely escape me, nobody has adopted these basic techniques to prevent small bugs from becoming big holes.

Now balance the common holes in C against all the other bugs in higher level languages with otherwise suitable memory protection, and consider that at least with C there are basic steps that prevent many of these from becoming problems, whereas with other languages you need a hodge-podge of different, more complicated countermeasures. C is actually easier to secure because its bugs are common and not difficult to catch by the kernel.

Honestly, if people spent as much time developing new industry best practices for use of the language as they do complaining about it, this would be a non-issue. But C isn't trendy, so let's all crap on it and pretend it's the only issue so we can have fun reinventing classical bugs with new languages.

C++ comes to mind for writing browser engines, but those have their fair share (if not more) of security issues as well.