3 ms·

I don't see how this sort of thing can be realistically prevented with today's software. I just don't. Yes, the damage can be limited through better IT practice

I don't see how this sort of thing can be realistically prevented with today's software. I just don't. Yes, the damage can be limited through better IT practices, but at some point everyone needs to have access to their relatively recent email and access to their files germane to their projects, and that need won't go away. And as long as our laughably porous networks and operating systems and application software can be penetrated at will by a targeted attack, those emails and files will be vulnerable. We need to start over. From the kernel on up. Until then, all we can hope for is band-aids like Qubes. And after we get there, we'll mostly have the hardware to fear. Not sure how addressable that part is, but it would be better than where we are now.

perlgeek 12y ago
> We need to start over. From the kernel on up. We need to start over. From the language that the kernel is written in, for starters. Doing it all in C sounds like a rather stupid idea, because we tried that already. I have high hopes that Rust, and the language that it will inspire, will be a big help here. (Yes, I know, you probably can't write the whole kernel in a memory-safe language, but I guess at least 95% of the current linux kernel could be. Probably 99% or more).
- Scramblejams 12y ago
  Yes. There need to be wholesale architectural changes as well. If there's a convincing argument that a monolithic kernel can be made secure, I haven't seen it. Device drivers are simply too dangerous to be running in kernel space, for example, along with much of the rest of what we usually get in the kernel (filesystems, TCP and UDP stacks, etc). No binary should ever be run without the kernel imposing an appropriately restrictive set of policies on what it can do. And there needs to be more sophistication in approaching how applications work. For example, a good argument can be made that binaries shouldn't be allowed to open their own file handles under most conditions. Your word processor shouldn't be the one putting up an open dialog and opening anything you point to in your directory tree because that's how it can be talked into dumping your entire home directory to a foreign server. It should have to ask the OS to put that dialog up, and then accept the file handle(s) it's handed by the OS. And then there are protocols that are broken by design, which we haven't even touched on. Everything, from top to bottom, needs to be rewritten with security in mind. Not sure how that could realistically happen, unfortunately.

perlgeek 12y ago

> We need to start over. From the kernel on up. We need to start over. From the language that the kernel is written in, for starters. Doing it all in C sounds like a rather stupid idea, because we tried that already. I have high hopes that Rust, and the language that it will inspire, will be a big help here. (Yes, I know, you probably can't write the whole kernel in a memory-safe language, but I guess at least 95% of the current linux kernel could be. Probably 99% or more).

Scramblejams 12y ago
Yes. There need to be wholesale architectural changes as well. If there's a convincing argument that a monolithic kernel can be made secure, I haven't seen it. Device drivers are simply too dangerous to be running in kernel space, for example, along with much of the rest of what we usually get in the kernel (filesystems, TCP and UDP stacks, etc). No binary should ever be run without the kernel imposing an appropriately restrictive set of policies on what it can do. And there needs to be more sophistication in approaching how applications work. For example, a good argument can be made that binaries shouldn't be allowed to open their own file handles under most conditions. Your word processor shouldn't be the one putting up an open dialog and opening anything you point to in your directory tree because that's how it can be talked into dumping your entire home directory to a foreign server. It should have to ask the OS to put that dialog up, and then accept the file handle(s) it's handed by the OS. And then there are protocols that are broken by design, which we haven't even touched on. Everything, from top to bottom, needs to be rewritten with security in mind. Not sure how that could realistically happen, unfortunately.