3 ms·

So if I understand correctly, one of the most common flags is "sudo" and it means that the tool doesn't bother detecting whether it's operating with elevated pr

So if I understand correctly, one of the most common flags is "sudo" and it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running. I suppose that's a fundamental design flaw in POSIX setuid operations. Setting real/effective UID/GID in a process is persistent, and tools don't normally keep checking to see whether they have/need elevated privileges, and so this happens. Now I expected this tag to mean something else. I expected there to be a list of tools that are commonly granted to ordinary users in the sudoers configuration, like the operator being able to kick off a backup. For example, "less" has a shell escape, and when running under sudo, it was possible to simply shell out and have an unrestricted root shell. I think that's fixed, but the moral of the story is not to grant sudo access to any tool that has shell escapes or arbitrary command execution.

Arch-TK 3y ago
In my experience, if you see * or more rarely ? in a sudo command configuration then there's a good chance there's a problem. I once saw a bunch of systemctl start someprefix* being allowed in a sudoers configuration (likewise for stop). systemctl can start more than one service at a time and the way that the sudoers configuration is checked is by glob matching the concatenated command. If your command is literally: "systemctl" "start" "someprefix" "sshd" this gets concatenated to "systemctl start someprefix sshd" which matches the glob "systemctl start someprefix*".
- opk 3y ago
  If you want to grant particular systemctl start/stops to normal users, that can be done with policykit,
  - BenjiWiebe 3y ago
    Thanks, I didn't know that!
deathanatos 3y ago
> it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running. No, it doesn't seem to mean even that. It just means that … the thing might do something construed as privileged, if the user running it is privileged. Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? This is solidly on the wrong side of the airtight hatch: I'm not "bypassing security restrictions", I've been granted access to read a file otherwise restricted with sudo. If you grant someone access to running `cat` as root, I can't imagine how it would be a shock that they can then read files that only root can read?
- ElectricalUnion 3y ago
  > Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? The `sudo` tag means, if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea.
  - deathanatos 3y ago
    > if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea. It might be a bad idea, but that's not "bypassing local security restrictions", that's explicitly changing the local security restrictions such that that's not a restricted command for the user you're granting it to. If you don't want someone to be able to read any file on the system, no, you shouldn't grant them the ability to run "cat" as root! But "I granted them X" "they ran X" → "they bypassed local security restrictions" is non sequitur.

Arch-TK 3y ago

In my experience, if you see * or more rarely ? in a sudo command configuration then there's a good chance there's a problem. I once saw a bunch of systemctl start someprefix* being allowed in a sudoers configuration (likewise for stop). systemctl can start more than one service at a time and the way that the sudoers configuration is checked is by glob matching the concatenated command. If your command is literally: "systemctl" "start" "someprefix" "sshd" this gets concatenated to "systemctl start someprefix sshd" which matches the glob "systemctl start someprefix*".

opk 3y ago
If you want to grant particular systemctl start/stops to normal users, that can be done with policykit,
- BenjiWiebe 3y ago
  Thanks, I didn't know that!

deathanatos 3y ago

> it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running. No, it doesn't seem to mean even that. It just means that … the thing might do something construed as privileged, if the user running it is privileged. Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? This is solidly on the wrong side of the airtight hatch: I'm not "bypassing security restrictions", I've been granted access to read a file otherwise restricted with sudo. If you grant someone access to running `cat` as root, I can't imagine how it would be a shock that they can then read files that only root can read?

ElectricalUnion 3y ago
> Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? The `sudo` tag means, if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea.
- deathanatos 3y ago
  > if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea. It might be a bad idea, but that's not "bypassing local security restrictions", that's explicitly changing the local security restrictions such that that's not a restricted command for the user you're granting it to. If you don't want someone to be able to read any file on the system, no, you shouldn't grant them the ability to run "cat" as root! But "I granted them X" "they ran X" → "they bypassed local security restrictions" is non sequitur.