4 ms·

For capabilities, a special instruction only makes sense in the context of CPU memory access and this is all about out of bounds C bugs. OS capabilities do not

For capabilities, a special instruction only makes sense in the context of CPU memory access and this is all about out of bounds C bugs. OS capabilities do not need new instructions. And then, out of bound memory access may be better solved with better programming languages, thought of course we need to live with the legacy code.

PhilipRoman 1y ago
I think what the parent means is we should be able to create syscall sandboxes within the same process (like a library not being able to do IO). Maybe I'm wrong but I think this could sort of be implemented with CHERI, by restricting syscalls to the official libc entry points (like OpenBSD) and requiring a capability pointer to access the functions.
- colejohnson66 1y ago
  .NET Framework tried that with their whole "security" system, but it was a massive failure. The only fool-proof solution is separate address spaces and OS cooperation.
  - yencabulator 1y ago
    Are you referring to Midori? I've only ever seen three reasons for Midori to shutdown: 1) they were hitting C# limitations (and started working on custom compilers etc) (and people involved in Midori say Rust has already shipped things they failed to do) 2) there was a bit too much academic overeagerness, e.g. software transactional memory will kill any project that attempts it 3) basically getting their budget taken away https://www.zdnet.com/article/whatever-happened-to-microsofts-midori-operating-system-project/ https://www.zdnet.com/article/whatever-happened-to-microsoft... https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
    - colejohnson66 1y ago
      Midori is certainly an interesting project, but no; I meant the old "code access security" model that .NET Framework had.[0][1] Administrators (and other code) could restrict you from doing certain operations, and the runtime would enforce it. It was removed in .NET Core.[2] [0]: https://learn.microsoft.com/en-us/previous-versions/dotnet/framework/code-access-security/code-access-security https://learn.microsoft.com/en-us/previous-versions/dotnet/f... [1]: https://learn.microsoft.com/en-us/dotnet/api/system.security.permissions?view=netframework-4.8 https://learn.microsoft.com/en-us/dotnet/api/system.security... [2]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/code-access-security-apis-obsolete https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
      - yencabulator 1y ago
        Okay, that looks really funky. Like, libraries explicitly state what access they have ambient authority to use, and then callers can be constrained by an access control list, or something like that. Really weird design. I'd love to see someone put genuine thought into what it would take to say that e.g. a Rust crate has no ambient authority. No unsafe, applied transitively. For example, no calling std::fs::open, must pass in a "filesystem abstraction" for that to work. I think the end of that road could be a way to have libraries that can only affect the outside world by values you pass in (=capabilities), busy looping, deadlocking, or running out of memory (and no_std might be a mechanism to force explicit use of an allocator, too). (Whether that work is worth doing in a world with WASM+WASI is a different question.)
yvdriess 1y ago
Language safety helps get you 80% of the way there, but you are still working from software on top of fundametally unsafe hardware. Companies and agencies are and, increasingly, will pour money into hardware that give certain safety and security guarantees.
pjmlp 1y ago
In regards to bounds checking, that has been solved in Solaris since ADI was introduced in 2015. https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/prog-interfaces/using-application-data-integrity-adi.html https://docs.oracle.com/en/operating-systems/solaris/oracle-...

PhilipRoman 1y ago

I think what the parent means is we should be able to create syscall sandboxes within the same process (like a library not being able to do IO). Maybe I'm wrong but I think this could sort of be implemented with CHERI, by restricting syscalls to the official libc entry points (like OpenBSD) and requiring a capability pointer to access the functions.

colejohnson66 1y ago
.NET Framework tried that with their whole "security" system, but it was a massive failure. The only fool-proof solution is separate address spaces and OS cooperation.
- yencabulator 1y ago
  Are you referring to Midori? I've only ever seen three reasons for Midori to shutdown: 1) they were hitting C# limitations (and started working on custom compilers etc) (and people involved in Midori say Rust has already shipped things they failed to do) 2) there was a bit too much academic overeagerness, e.g. software transactional memory will kill any project that attempts it 3) basically getting their budget taken away https://www.zdnet.com/article/whatever-happened-to-microsofts-midori-operating-system-project/ https://www.zdnet.com/article/whatever-happened-to-microsoft... https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
  - colejohnson66 1y ago
    Midori is certainly an interesting project, but no; I meant the old "code access security" model that .NET Framework had.[0][1] Administrators (and other code) could restrict you from doing certain operations, and the runtime would enforce it. It was removed in .NET Core.[2] [0]: https://learn.microsoft.com/en-us/previous-versions/dotnet/framework/code-access-security/code-access-security https://learn.microsoft.com/en-us/previous-versions/dotnet/f... [1]: https://learn.microsoft.com/en-us/dotnet/api/system.security.permissions?view=netframework-4.8 https://learn.microsoft.com/en-us/dotnet/api/system.security... [2]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/code-access-security-apis-obsolete https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
    - yencabulator 1y ago
      Okay, that looks really funky. Like, libraries explicitly state what access they have ambient authority to use, and then callers can be constrained by an access control list, or something like that. Really weird design. I'd love to see someone put genuine thought into what it would take to say that e.g. a Rust crate has no ambient authority. No unsafe, applied transitively. For example, no calling std::fs::open, must pass in a "filesystem abstraction" for that to work. I think the end of that road could be a way to have libraries that can only affect the outside world by values you pass in (=capabilities), busy looping, deadlocking, or running out of memory (and no_std might be a mechanism to force explicit use of an allocator, too). (Whether that work is worth doing in a world with WASM+WASI is a different question.)

yvdriess 1y ago

Language safety helps get you 80% of the way there, but you are still working from software on top of fundametally unsafe hardware. Companies and agencies are and, increasingly, will pour money into hardware that give certain safety and security guarantees.

pjmlp 1y ago

In regards to bounds checking, that has been solved in Solaris since ADI was introduced in 2015. https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/prog-interfaces/using-application-data-integrity-adi.html https://docs.oracle.com/en/operating-systems/solaris/oracle-...