4 ms·

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

by catern 5y ago

mikewarot 5y ago
If that were true, you could cross compile Windows 10 to Rust Source code (or whatever language you think its magic enough to be safe), compile it from that language, and then it would never have a security problem again. Obviously that's not true.
- catern 5y ago
  Cross-compiling OpenSSL to Rust and then compiling the Rust would also not get rid of the memory-unsafety vulnerabilities created by writing OpenSSL in C. Nevertheless, if you wrote OpenSSL in Rust, or any memory-safe language, it would not have those memory-unsafety vulnerabilities. The same applies when writing in a capability-safe language. It's fairly deliberately ignorant to call these kind of properties "magic".
- adrianN 5y ago
  That's not true because the compiler of the magical safe language would likely reject the Windows 10 source and "cross compiling" is actually a major rewrite.
  - junon 5y ago
    No, it's mostly not true because Rust does not prevent logic bugs.
    - adrianN 5y ago
      Which is why I explicitly didn't write "Rust" is my comment.
mikewarot 5y ago
Please let me re-state my objection to your assertion, in a different, and hopefully more constructive, manner. An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem? It is my assertion that the design of Linux, Windows, MacOS are all flawed. They provide, by default, any program the computer equivalent of "power of attorney". All you have to do is confuse, or subvert any program the user runs one time to abuse that privilege on behalf of an outside influence, and the system is on the way to being pwned. Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise. I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient.
- catern 5y ago
  Yes, and in a capability-safe language it's much more difficult to implement those flawed designs. (In the same way memory safety makes a buffer overrun vulnerability much more difficult to implement) A concrete example is the Network capability mentioned in the article. The syscall to create a new process does not need network access, so in a capability-safe language that part of the OS won't have that capability passed in, so the OS won't be able to create new processes with network access. The Network capability, if desired for this process, will need to be explicitly added later by other code, in the OS or in userspace.
- kragen 5y ago
  > An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem? A capability-safe language safely multiplexes hardware and software resources among different parts of the same application. So, even if every application has the privilege to crash your computer, delete all your files, or exfiltrate your Bitcoin and ssh keys, not all the code in the application would. For example, your logging library doesn't need those authorities, so the rest of the program wouldn't pass them in. > Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise. It is necessary to enforce the user's desired limits the authority on each application to prevent damage from malicious applications, but capability-safe languages (or hardware, like CHERI) can in most cases prevent damage from confused applications and from confused or malicious libraries. > I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient. I agree, but capability safety properly integrated with the user interface may be sufficient, as long as the capability system is sufficiently expressive to express the will of the user. (For example, KeyKOS's capability system includes keys to use limited amounts of CPU time, while E has no effective way to keep malicious code from denying access to a whole vat once it starts running; killing a running process because they're using too much CPU or memory requires some way to recover from their failures, which E does not have.)

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

by catern 5y ago

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

mikewarot 5y ago

If that were true, you could cross compile Windows 10 to Rust Source code (or whatever language you think its magic enough to be safe), compile it from that language, and then it would never have a security problem again. Obviously that's not true.

catern 5y ago
Cross-compiling OpenSSL to Rust and then compiling the Rust would also not get rid of the memory-unsafety vulnerabilities created by writing OpenSSL in C. Nevertheless, if you wrote OpenSSL in Rust, or any memory-safe language, it would not have those memory-unsafety vulnerabilities. The same applies when writing in a capability-safe language. It's fairly deliberately ignorant to call these kind of properties "magic".
adrianN 5y ago
That's not true because the compiler of the magical safe language would likely reject the Windows 10 source and "cross compiling" is actually a major rewrite.
- junon 5y ago
  No, it's mostly not true because Rust does not prevent logic bugs.
  - adrianN 5y ago
    Which is why I explicitly didn't write "Rust" is my comment.

mikewarot 5y ago

Please let me re-state my objection to your assertion, in a different, and hopefully more constructive, manner. An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem? It is my assertion that the design of Linux, Windows, MacOS are all flawed. They provide, by default, any program the computer equivalent of "power of attorney". All you have to do is confuse, or subvert any program the user runs one time to abuse that privilege on behalf of an outside influence, and the system is on the way to being pwned. Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise. I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient.

catern 5y ago
Yes, and in a capability-safe language it's much more difficult to implement those flawed designs. (In the same way memory safety makes a buffer overrun vulnerability much more difficult to implement) A concrete example is the Network capability mentioned in the article. The syscall to create a new process does not need network access, so in a capability-safe language that part of the OS won't have that capability passed in, so the OS won't be able to create new processes with network access. The Network capability, if desired for this process, will need to be explicitly added later by other code, in the OS or in userspace.
kragen 5y ago
> An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem? A capability-safe language safely multiplexes hardware and software resources among different parts of the same application. So, even if every application has the privilege to crash your computer, delete all your files, or exfiltrate your Bitcoin and ssh keys, not all the code in the application would. For example, your logging library doesn't need those authorities, so the rest of the program wouldn't pass them in. > Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise. It is necessary to enforce the user's desired limits the authority on each application to prevent damage from malicious applications, but capability-safe languages (or hardware, like CHERI) can in most cases prevent damage from confused applications and from confused or malicious libraries. > I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient. I agree, but capability safety properly integrated with the user interface may be sufficient, as long as the capability system is sufficiently expressive to express the will of the user. (For example, KeyKOS's capability system includes keys to use limited amounts of CPU time, while E has no effective way to keep malicious code from denying access to a whole vat once it starts running; killing a running process because they're using too much CPU or memory requires some way to recover from their failures, which E does not have.)