1. 6

  2. 14

    The above rule allows odedlaz to run any executable found at /home/odedlaz/Development/doas/tools with any arguments, as root without requiring a password.

    Uhhhh, that seems like a horrible idea.

    1. 2
      ln -s /bin/bash /home/odedlaz/Development/doas/tools/lol
    2. 6

      It appears he just copied doas, so to say “I fixed it” is a bit rich.

      1. 8

        Why? because it’s written in C, and I really don’t want to maintain C code.

        Yeah, I can see the point. A weak type system, memory unsafety, surprising behaviour. All good reasons not to write a security relevant tool in C in 2017.

        implemented in modern C++

        Had a good laugh about this.

        1. 1

          i found the use of PCRE funny too for the same reason.

        2. 4
          1. 5

            Some people don’t understand why URLs should not change: https://www.w3.org/Provider/Style/URI

          2. 2
            deny odedlaz as root cmd /bin/rm args .*\s+/$

            Does that seem right?

            doas /bin/rm -rf //
            doas /bin/rm -rf / /tmp/whatever.txt

            The gist is that sudo is hard to configure is it. doas might be slightly easier to configure for some cases, but it’s so easy to get these things wrong that I simply don’t recommend the use of sudo or doas or any similar tool to anyone for any reason.

            setuid-root programs are dangerous. Heck, setuid-anyone programs are dangerous. These kinds of programs are very difficult to get right, so it makes sense to try and store all of the functionality and logic in a single place like sudo or doas, but I think it’s much too difficult for most programmers and worse still there’s simply no reason you need to use it.

            SSH forced commands are better, and if you forward environment variables and write wrapper scripts, you’ll get an audit trail (which could potentially and trivially be on a separate machine if you have configured pam that way), and what’s more: it’s easy to get right.

            1. 3

              The gist is not only the easier configuration but also the small codebase, which should statistically reduce the amounts of bugs. (I’m talking about the original doas, I think the c++ author didn’t get the memo) How is ssh any better, doas has a really small codebase, the configuration is easier to write than wrapper scripts. And you can get the audit trail through syslog and/or bsd-auth or pam.

              1. 2

                How is ssh any better?

                I assume I’ve already paid for ssh; I’m going to use it to reach the machine. The additional code is sudo/doas.

                If you don’t need ssh (e.g. because you access via the console, via a physically connected terminal, or a terminal simulated via a hypervisor, or even via a separate management network) then I wonder why don’t you audit the use of your terminal server instead of trying to do it from the machine?

                I’m talking about the original doas, I think the c++ author didn’t get the memo

                It’s hard to otherwise talk about doas: OpenBSD isn’t an option for most of what I do, but yes: it looks a lot better than this. I’m talking about this article which purports to represent “doas”.

                the configuration is easier to write than wrapper scripts

                You’ll probably need to write wrapper scripts anyway. OpenBSD’s doas doesn’t have a particularly flexible configuration file format, and this one has such a horrible grammar that you’re likely to get it wrong as well.

                But hey, you know bourne-shell already, so you’re probably likely to get your wrapper script correct.

            2. 1

              I am getting a 404, here is the archived page