disable my own sudo for current shell?

Question

Is it possible to prevent sudo from gaining root without password only in the current session (e.g. bash shell process?)

I've noticed that ruby's bundle underhandedly used my sudo powers, without asking, to write to system directories. Anyways, perhaps I didn't read enough about this wonderful tool, but is there a way to withdraw sudo blessings temporarily without reconfiguring /etc/sudoers*?

Edit: I currently have NOPASSWD enabled for the sudo group, which I'm a member of. I'd rather make the current process unable to sudo (e.g. by using something like newgrp) than give up NOPASSWD.

Does this answer your question? Forcing sudo to prompt for a password — Gilles 'SO- stop being evil', Apr 28 '21 at 18:11
It's a way to do it (remove NOPASSWD, set a long timeout, manually expire as needed). I'd prefer to do something like newgrp to change the current PID's notion of who I am (and remove myself from the sudo group which I configured to sudo without password) — usretc, Apr 28 '21 at 18:15

score 1 · Answer 1 · answered Apr 28 '21 at 22:28

1

$ alias sudo="echo sudon't "

$ sudo su - root

sudon't su - root

This will just break it where it's calling sudo, unless it's calling the full path like /usr/bin/sudo

answered Apr 28 '21 at 22:28

jerry

11

This won't work for the case described in the question, where sudo is called within an application itself. – Chris Down Apr 28 '21 at 22:37
Aha! But it's a good idea. ln -s /bin/true /tmp/sudo; PATH=/tmp:"$PATH" finally breaks bundle. Seems like they just call sudo from the PATH, without hardcoding its location (which makes sense) – usretc Apr 29 '21 at 01:14

LL3 · Answer 2 · 2021-04-29T12:52:34.313

Your idea would be easily doable by means of a small "set-userID-root" program which would only perform a setgroups(2) with all the current groups (as per getgroups(2)) except the sudo one, effectively dropping it. The set-userID-root is required because setgroups(2) is a privileged operation.

On Linux it could even be simpler as you could leverage the capabilities(7) hence make the executable program setcap(8)-ed to be CAP_SETGID rather than set-userID-root. At that point such dedicated program would only need to capset(2) itself to that capability before performing setgroups(2).

On the other hand, though, beware of dropping/changing group memberships inadvertently, because being member of a group is also used to reduce access rights e.g. to files & directories via ACLs purposefully placed.

That said, by leveraging the (Linux specific) setpriv(1) command (if available on your system) you can harness a proof-of-concept made as a shell function, like the below in which I'm using sudo itself (given that you are NOPASSWD) as the "set-userID-root enabler":

# NOTE: this one uses Bash facilities
dropgrp() {
    local groups grp="${1:?Specify group to drop}" IFS=; shift
    IFS=: read -ra grent < <(getent group "$grp")
    groups=(${GROUPS[@]/${grent[2]}})
    IFS=,; sudo setpriv --reuid "$EUID" --regid "$GROUPS" --groups "${groups[*]}" "$@"
}

You would then run $ dropgrp sudo bundle (the sudo in there refers to the group name, not the command), and when that bundle program invokes sudo (the command) it will ask for your password to proceed.

disable my own sudo for current shell?

2 Answers2