[kibwen]

I've considered proposing this before, but presumably it's a cat and mouse game. Can the Rust stdlib reliably detect writes to /proc/mem in the face of links and raw FDs? And it probably should be reliable, because nobody writes to /proc/mem by accident.

And even then, it doesn't help with whole-system security when every program in every other language on your system, including safe ones like Java and Python, have the same capability. (Although if I'm wrong that there's no precedence for languages attempting to block this, I'd love to see the prior art.)

[amluto]

It’s not just /proc/sys/mem. One could also modify executable files and cause all manner of other mayhem. At the end of they, if you have access to all ambient privileges available to your process, you can use them. Trying to specifically block memory safety violations would be a bit odd.

[Joker_vD]

> One could also modify executable files

ETXTBSY.

[amluto]

Not if they’re not running or if you replace them outright. So you can rename a garbage file over your main executable, exec yourself, and segfault. Is that memory unsafety?

How about ptracing yourself?

How about undervolting your CPU such that it malfunctions?

How about running your program off a FUSE filesystem that changes the contents out from under it?

How about editing the raw block device you’re running from?

How about modifying /dev/mem on older systems that allow that?

This particular rabbit hole is extremely deep, and I don’t think it’s practical to address it for real short of making a real security model for what running code may and may not to do the rest of the world. (I think doing that is an extremely worthwhile endeavor, but disallowing opening specific files won’t be part of it.)

[jonathrg]

In case anyone else was wondering if this was an acronym for an aphorism (like YAGNI), this is an error code (error text busy). And 'text' refers to the executable