4 ms·

There is also 'doas' from the OpenBSD project. It's a replacement for 'sudo' with fewer features and a smaller codebase, with the aim of a smaller attack surfac

There is also 'doas' from the OpenBSD project. It's a replacement for 'sudo' with fewer features and a smaller codebase, with the aim of a smaller attack surface. https://en.m.wikipedia.org/wiki/Doas https://en.m.wikipedia.org/wiki/Doas

smabie 3y ago
Though written in C for no apparent reason. It's ironic to me how security focused OpenBSD is while at the same time looking down on any other language besides C.
- yjftsjthsd-h 3y ago
  > for no apparent reason Here's the list of hardware platforms that OpenBSD supports: https://www.openbsd.org/plat.html https://www.openbsd.org/plat.html Note that when they say support, they mean that it's fully supported and actually works well, including that OpenBSD is fully self-hosting on that platform (read: "oops, the compiler OOMs on 32-bit" is a no-go). Now, here's the list of targets that rust supports: https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html Notice that all the OpenBSD targets are tier 3, and it's a strict subset of OpenBSD's platoforms. Even if we ignore everything else - a questionable choice - rust is unsuitable for writing core parts of OpenBSD because it can't actually build for all the systems that OpenBSD supports.
  - jcranmer 3y ago
    The point GP was (probably) trying to make is that OpenBSD's vision of security is at odds with its insistence on C, a notoriously unsafe and insecure language. There's no reason that the replacement language has to be Rust; it could be Nim or Zig or C# or Java or Vala or OpenBSD Custom Memory-Safe Language. What it takes for OpenBSD to choose to support whichever language it wants to is primarily a commitment to actually spend its resources to support said language. That the OpenBSD targets for Rust are tier 3 is a sign of its unwillingness to consider moving away from C: what it takes to move from tier 3 to tier 2 is a set of maintainers who have a commitment to be responsive to patches, and an automated CI solution. (Also note that OpenBSD is the largest Unix "stuck" in tier 3 for Rust. Solaris/Illumos, FreeBSD, and NetBSD all manage to have tier 2 builders. Even Fuchsia and Redox have tier 2 support!)
    - PrimeMcFly 3y ago
      > OpenBSD's vision of security is at odds with its insistence on C, Their idea of security honestly seems very narrowly scoped on fixing a particular set of issues.
    - tedunangst 3y ago
      I think sometimes people forget the openbsd project was not started with a text editor opening an empty file.
- Karellen 3y ago
  OpenBSD doesn't have a Rust compiler in their core system. Having a core utility written in a language that isn't buildable with tools in their core system is a non-starter. Once they have their own Rust compiler, or are able to import a Rust compiler that supports OpenBSD to the point where bugs on that platform are release-blockers for that compiler, and which is suitably licensed, they should be able to start (re-)writing core tools in Rust.
- JohnFen 3y ago
  Just because something is written in C doesn't automatically mean it's unsafe. It's 100% possible to write safe C code. It's just not "automatic".
  - Gigachad 3y ago
    Safe C code is like functional communism, we are yet to see a real example. It probably could exist though.
    - rhdunn 3y ago
      SQLite? That has an extensive test suite and has been extensively vetted/checked.
      - dwattttt 3y ago
        True, but there are quite a few CVEs (of varying severity) https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html https://www.cvedetails.com/vulnerability-list/vendor_id-9237... Another way to look at that is "SQlite has had these bugs in the past, and our standards are unlikely to be that high". It does deal with a quite complex problem domain, but is still a strong warning re. vulnerabilities in C.
        thesnide 3y ago
        I actually am waiting for the increase in CVE number of rust replacements. So we can compare. As for now, less exposure means less CVE. So the numbers are biased. As usually, time will tell.
        Gigachad 3y ago
        We have the data now https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language... 1.5M lines of Rust in Android and not a single memory vulnerability found, including in their unsafe Rust code. They also observe that the number of memory vulnerabilities decreases almost exactly inline with the decreasing use of memory unsafe language in Android. The Android Rust code is also showing to have less bugs in general than the C/++ code.
hannob 3y ago
Yeah, but... Recently learned that it doesn't implement using a new pty, which makes it vulnerable to TIOCSTI and TIOCLINUX ioctl attacks. Which doesn't matter on OpenBSD, because OpenBSD does not have these features. But Linux does, so not ideal. https://github.com/Duncaen/OpenDoas/issues/106 https://github.com/Duncaen/OpenDoas/issues/106
rnijveld 3y ago
I’m on the team that is implementing sudo-rs, and we are definitely aware of doas and other similar utilities. Doas does definitely have its usages, especially with the ‘just let me run this as root’ use case in mind. That said, there is also something to say for the more extensive configurability of sudo, and doas does sometimes have an execution model that might be a little too simple. And having another alternative is never a bad thing in my mind.

smabie 3y ago

Though written in C for no apparent reason. It's ironic to me how security focused OpenBSD is while at the same time looking down on any other language besides C.

yjftsjthsd-h 3y ago
> for no apparent reason Here's the list of hardware platforms that OpenBSD supports: https://www.openbsd.org/plat.html https://www.openbsd.org/plat.html Note that when they say support, they mean that it's fully supported and actually works well, including that OpenBSD is fully self-hosting on that platform (read: "oops, the compiler OOMs on 32-bit" is a no-go). Now, here's the list of targets that rust supports: https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html Notice that all the OpenBSD targets are tier 3, and it's a strict subset of OpenBSD's platoforms. Even if we ignore everything else - a questionable choice - rust is unsuitable for writing core parts of OpenBSD because it can't actually build for all the systems that OpenBSD supports.
- jcranmer 3y ago
  The point GP was (probably) trying to make is that OpenBSD's vision of security is at odds with its insistence on C, a notoriously unsafe and insecure language. There's no reason that the replacement language has to be Rust; it could be Nim or Zig or C# or Java or Vala or OpenBSD Custom Memory-Safe Language. What it takes for OpenBSD to choose to support whichever language it wants to is primarily a commitment to actually spend its resources to support said language. That the OpenBSD targets for Rust are tier 3 is a sign of its unwillingness to consider moving away from C: what it takes to move from tier 3 to tier 2 is a set of maintainers who have a commitment to be responsive to patches, and an automated CI solution. (Also note that OpenBSD is the largest Unix "stuck" in tier 3 for Rust. Solaris/Illumos, FreeBSD, and NetBSD all manage to have tier 2 builders. Even Fuchsia and Redox have tier 2 support!)
  - PrimeMcFly 3y ago
    > OpenBSD's vision of security is at odds with its insistence on C, Their idea of security honestly seems very narrowly scoped on fixing a particular set of issues.
  - tedunangst 3y ago
    I think sometimes people forget the openbsd project was not started with a text editor opening an empty file.
Karellen 3y ago
OpenBSD doesn't have a Rust compiler in their core system. Having a core utility written in a language that isn't buildable with tools in their core system is a non-starter. Once they have their own Rust compiler, or are able to import a Rust compiler that supports OpenBSD to the point where bugs on that platform are release-blockers for that compiler, and which is suitably licensed, they should be able to start (re-)writing core tools in Rust.
JohnFen 3y ago
Just because something is written in C doesn't automatically mean it's unsafe. It's 100% possible to write safe C code. It's just not "automatic".
- Gigachad 3y ago
  Safe C code is like functional communism, we are yet to see a real example. It probably could exist though.
  - rhdunn 3y ago
    SQLite? That has an extensive test suite and has been extensively vetted/checked.
    - dwattttt 3y ago
      True, but there are quite a few CVEs (of varying severity) https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html https://www.cvedetails.com/vulnerability-list/vendor_id-9237... Another way to look at that is "SQlite has had these bugs in the past, and our standards are unlikely to be that high". It does deal with a quite complex problem domain, but is still a strong warning re. vulnerabilities in C.
      - thesnide 3y ago
        I actually am waiting for the increase in CVE number of rust replacements. So we can compare. As for now, less exposure means less CVE. So the numbers are biased. As usually, time will tell.
        Gigachad 3y ago
        We have the data now https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language... 1.5M lines of Rust in Android and not a single memory vulnerability found, including in their unsafe Rust code. They also observe that the number of memory vulnerabilities decreases almost exactly inline with the decreasing use of memory unsafe language in Android. The Android Rust code is also showing to have less bugs in general than the C/++ code.

hannob 3y ago

Yeah, but... Recently learned that it doesn't implement using a new pty, which makes it vulnerable to TIOCSTI and TIOCLINUX ioctl attacks. Which doesn't matter on OpenBSD, because OpenBSD does not have these features. But Linux does, so not ideal. https://github.com/Duncaen/OpenDoas/issues/106 https://github.com/Duncaen/OpenDoas/issues/106

rnijveld 3y ago

I’m on the team that is implementing sudo-rs, and we are definitely aware of doas and other similar utilities. Doas does definitely have its usages, especially with the ‘just let me run this as root’ use case in mind. That said, there is also something to say for the more extensive configurability of sudo, and doas does sometimes have an execution model that might be a little too simple. And having another alternative is never a bad thing in my mind.