| There are three ways to tackle the human costs of computing. 1) Make the things humans have to do easier. UI/UX 2) Reduce the number of things humans have to do. While all modern hardware can calculate the same things (are universal) they have different security models which can affect how much maintenance the user has to do. Take capability based security, an old idea implemented in hardware in the IBM AS 400. Languages (E, Joe-E) based on it are currently being touted as a way to reduce the risk of malware infection, even if malware does get on the system it can't do much because the language VMs operate under a principle of least privilege. If we are changing the Arch for performance (e.g. fleet) and can't make use of the performance with standard software we may want to change it in this way as well, to take advantage of the system. To give a concrete example of how computer architectures can be changed for the better. If windows had capability based security at the low level it could pass bits of memory to the user land process by sharing a capability that gave it write access. Then the user land process could populate it, once it had finished and the kernel wanted to read it, they could revoke the the writeable permission. This would prevent this sort of attack http://news.ycombinator.org/item?id=1331025 See this for an intro to the philosophy http://www.erights.org/talks/virus-safe/index.html 3) Make the computer do the work for the human. Yes this is mainly an AI problem, but it also an architecture problem. If you want the system to manage things like your graphics card drivers for you, you have to make some decisions about the hardware. Which programs are allowed to try and manage the graphics card drivers, how can the user communicate what she wants in terms of graphics card drivers in a way that the computer will find unambiguous. So yep, UI and UX, is important but it is only one possibly angle of attack, and not the one I'm interested in. Because people are doing fine work on it, while the others languish a bit. |
> by sharing a capability that gave it write access.
> Then the userland process could populate it,
> once it had finished and the kernel wanted to read it,
> they could revoke the the writeable permission.
> This would prevent this sort of attack [apparently,
> confusing auditors with TOCTOU attacks on system call arguments]
Virtual memory mapping hardware is already roughly a capability system. The CPU doesn't maintain a list of ownerships and permissions for every page of physical memory; it puts capabilities to those pages into page tables. That's how KeyKOS was able to run efficiently on stock hardware.
Capability systems are indeed better for security in several ways, but this isn't one of them. The problem here is that the memory page is shareable between different user threads. You can solve this problem in a variety of ways, including the one you suggest. However, unmapping the page that a system-call argument lives in before invoking an auditor does not constitute implementing a capability system.
To a great extent, it seems like the move toward web apps is exactly a move toward a different security model in order to reduce the maintenance the user has to do, a model in which most apps are fairly limited in their authority. The same-origin policy still falls far short of full POLA, but it's a step. The project in this area I'm most excited about is Caja, which is what MarkM's working on these days.