4 ms·

In this networked world, it really is a terrible language, there is no excuse for it The only authority this program should have is network access, some comput

In this networked world, it really is a terrible language, there is no excuse for it The only authority this program should have is network access, some compute time and permission to create and write to one or more files. Nothing more. Though this is where almost all of our currently popular programming languages and operating systems are failing. They are fundamentally broken. Just on account of security, monolithic kernels are a terrible idea. And sandboxing hasn't even been an afterthought in most languages and virtual machines. Even on the hardware level, secure compartmentalization and access mechanisms are a joke.

nickysielicki 3y ago
The issue is not that there’s no way to do this, it’s that there’s no portable way to do this. A seccomp bpf implementation of https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 could go a long way.
- 7373737373 3y ago
  That would be a good start, because it would allow one to "hollow out the attack surface" - a great concept I've encountered in the erights community. Primitives that allow one to gradually secure a system in the future when the need arises. Though unfortunately it doesn't provide the level of expressivity and flexibility that a full capability security architecture would. The world has a great deal to learn from the likes of KeyKOS, seL4 and Genode, i don't see any of these issues going away without their adoption (or at least their ideas, in other systems).
- chucky_z 3y ago
  like https://github.com/jart/pledge https://github.com/jart/pledge? i'm using this all over our production environment and it's very nice.
xign 3y ago
Those are two separate things though. C is more vulnerable than Rust, but either way we should properly sandbox our applications even if they are written in a memory-safe language like Rust (which is not infallable, it's just safer). One issue is if cURL is allowed to write to "one or more files", then how do you prevent it from writing to a key configuration file or sensitive one that has a lot of downstream effect or write a Bash script that could launch further attacks?
- 7373737373 3y ago
  This really calls for a new type of shell that allows one to pass file descriptors/capabilities as arguments

nickysielicki 3y ago

The issue is not that there’s no way to do this, it’s that there’s no portable way to do this. A seccomp bpf implementation of https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 could go a long way.

7373737373 3y ago
That would be a good start, because it would allow one to "hollow out the attack surface" - a great concept I've encountered in the erights community. Primitives that allow one to gradually secure a system in the future when the need arises. Though unfortunately it doesn't provide the level of expressivity and flexibility that a full capability security architecture would. The world has a great deal to learn from the likes of KeyKOS, seL4 and Genode, i don't see any of these issues going away without their adoption (or at least their ideas, in other systems).
chucky_z 3y ago
like https://github.com/jart/pledge https://github.com/jart/pledge? i'm using this all over our production environment and it's very nice.

xign 3y ago

Those are two separate things though. C is more vulnerable than Rust, but either way we should properly sandbox our applications even if they are written in a memory-safe language like Rust (which is not infallable, it's just safer). One issue is if cURL is allowed to write to "one or more files", then how do you prevent it from writing to a key configuration file or sensitive one that has a lot of downstream effect or write a Bash script that could launch further attacks?

7373737373 3y ago
This really calls for a new type of shell that allows one to pass file descriptors/capabilities as arguments