1. 38

  2. 20

    Why isn’t this tagged ‘crimes’ on your site

    1. 10

      is the joke that without the setuid bit it does nothing?

      An unironic simpler sudo replacement: https://github.com/illiliti/ssu

        1. 5

          ssu is interesting because it’s genuinely simple: 120 lines of C. It’s very much auditable.

        2. 8

          The joke is that attack code can’t deal with emoji so it’s secure.

          Also it’s written in Rust because I have good reason to believe that writing new software in C is professional malpractice.

          1. 13

            So, if I can do the thing where I explain the joke…

            Pretty much everyone gets unicode wrong, so here’s a program that literally gives you root without any authentication, or even group membership checks (it’s chmod’d 6755), and since it’s written in Rust it’s still more secure than sudo, written in C. I happen to disagree. :)

            1. 10

              2 of the 3 CVEs seem to be possible regardless of the language?… Am I wrong about my understanding?

              I’m starting to realize now only after using Rust for a few years that we’re digging a dangerous hole of saying “it’s not written in Rust, it’s not safe”… It’s not only possible to write lots of unsafe code in Rust, it’s a super common thing! There are unsafe bugs that exist outside of memory management errors, and as we see 2 of the 3 are in those cases.

              Also is it the wisest thing to encourage people to use a really untested security component? You’re a big voice…! I know the code is essentially one line but what isn’t being shown there?

              Sorry for being a bit critical on what I’m understand is tongue-in-cheek. I don’t mean to ruin anyone’s fun :D.

              1. 13

                Yup, this. The problem with sudo is not that it’s written in C, it’s that it is a gigantic creeping code base. Solution here is to use doas, not to RIR.

                And if you do RIR, you should tread carefully. IIRC, first audit of please uncovered a bunch of logicial vulnerabilities, and, having skimmed its readme, I’d rather stay with doas.

                1. 5

                  There are also much better languages for the purpose of high assurance computing, most notably Ada/SPARK which offers provable functional correctness, contracts, absence of runtime errors, etc. on top of Rust’s memory ownership model.

                  Consider this overview article within the more complete introduction to SPARK. You can download it as a PDF and read it on the bus/train to/from work. It will be worth your time! Rust is not the end all be all. :)

                  1. 5

                    Non sequitur: POSIX cli utils are not high assurance software.

                    We could prove them correct, but our time is better spent elsewhere. It’s OK to malloc, abort on OOM, and move on.

                    Though, I’d love to see a SPARK implementation of sudo: I am curious to what extent can we prove functional correctness of something, which isn’t a state machine, but rather a POSIX poking script.

                    1. 1

                      You would need to formalize POSIX itself, I presume, so you can give any guarantees.

                  2. 1

                    The problem with sudo is not that it’s written in C, it’s that it is a gigantic creeping code base.

                    It’s both. We do see memory safety issues in sudo still.

                    first audit of please uncovered a bunch of logicial vulnerabilities

                    They were almost all information disclosures because the threat model of sudo was not clear to the developer.

                    1. 3

                      For the record, the audit is here https://marc.info/?l=oss-security&m=162133298513412&w=2

                      One excerpt:

                      So this more or less allows anybody who is allowed to execute at least one command with password authentication to perform a full local root exploit.

                      I agree that “huge codebase for setuid binary” and “not written in memory safe language” are both problems. With the the info I currently know, I think the former is a bigger one.

                      I don’t know whether doas had any memory safety vulns, but if it didn’t, it’s a signal that in this case the first problem is not only bigger, but actually dominates the second one.

                      1. 3

                        It did, in fact, have a memory-safety vuln: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15900.

            2. 9

              It is a command that lets you set user and then do a command.

              pushes up glasses Well, Ackkchually, the ‘s’ stands for ‘substitute’ so it’s ‘substitute user.’

              1. 7

                I’ll change that after this meeting. 🤓


              2. 6


                1. 10

                  🥺 make me a sandwhich

                  1. 12


                2. 4

                  the hacker news discussion is horrifying, the lack of humor and the smartassery there is astonishing :/ I really enjoyed the post and I learned something (the setuid bit)

                  1. 3

                    I did not like the post, mainly because the “teacher” character, Cadey, came across more as a shitposter than a teacher in the original version (it was later changed to read better). I was also upset at the lack of historical context in the post, implying that the authors of sudo where beyond stupid for picking C over Rust (at least, that’s how I read it—wonder what that says about me).

                    1. 2

                      I’m fairly certain the whole thing was a joke and not anything serious.

                      1. 1

                        The choice here to me is not the initial one at the beginning of the project, but the implict one that every project makes everyday

                        1. 1

                          Which would be … ? Switching to anything other than C?

                          1. 1

                            What language do I use? What stack? What toolchain? What testing suite? A fuzzer? Which? Do I use formal verification? What does packaging and deployment look like? Do I have beta builds?

                            You don’t think about these each day, but you’re still making an implicit choice to go with what you decided before