The "breaking interface contracts is a security enhancement" view is a very very harmful one. It's the opposite.
Conversation
Systems code should be written in something higher level than assembler but lower level than the symbolic execution system that C claims to provide currently. “Just use assembly” or “just use a type safe language” aren’t useful answers.
1
Systems code benefits from memory and type safety even more than most other code because it's often in a position of trust and privilege. Using a language where unsafety can be contained and quickly wrapped into safe APIs is certainly useful advice for newly written systems code.
1
2
6
The expectations of software robustness and security have increased a lot, and it's simply not realistic to achieve it while using unsafe tools making it much more difficult to write safe code. Writing something complex like an safe ext4 implementation is C is not very realistic.
1
5
i.e. writing the entire thing with zero memory corruption bugs for an attacker to exploit either via an attacker controlled filesystem or an application. Drivers similarly have to be written treating the hardware and code using them as adversarial. Choice of tools is important.
1
2
FS drivers do not belong in privileged contexts. The FS driver for an untrusted FS should be executing in a context where it can do nothing worse than store or retrieve wrong data.
1
2
Definitely, but gaining arbitrary code execution even within a sandbox is a huge victory for an attacker, especially if it's not sitting on top of a lean microkernel that's very difficult to exploit. Escaping from a sandboxed FUSE driver on Linux is easier than initial code exec.
This Tweet was deleted by the Tweet author. Learn more
I'm not sure why you're linking that. I'm talking about vulnerabilities in the Linux kernel usable to escape from a sandbox not the userspace FUSE components, which aren't a substantial portion of the attack surface for a FUSE filesystem driver. FUSE drivers are a normal process.
1
cvedetails.com/product/47/Lin for the Linux kernel is also not even close to a full overview of fixed security vulnerabilities. I recommend reading kroah.com/log/blog/2018/ from Greg KH, one of the core Linux kernel developers / maintainers.
1
"Because security bugs are not announced to the public by the kernel team, CVE numbers for Linux kernel-related issues are usually released weeks, months, and sometimes years after the fix was merged into the stable and development branches, if at all."
Like most projects, the Linux kernel fixes security vulnerabilities alongside other bugs. They don't do analysis of which issues are security bugs. The subset of these security bugs that are assigned a CVE are due to external security researchers or downstream distributions.
1
The recommendation from Greg KH is to just the stable / longterm kernel branches, because only a small subset of the security bugs receive a CVE.
events.linuxfoundation.org/wp-content/upl
syszkiller has found *literally hundreds of security bugs* every month, primarily memory corruption bugs...