Security implications of running user-writable scripts with sudo

Question

I need to run a few commands with sudo. These commands are located either in .bashrc or ~/bin, and stored in a git repository (i.e. dotfiles).

I've placed symbolic links in ~root pointing to my user's $HOME, but I think it isn't great security-wise doing so, so I removed them.

My concern is that if a non-root user have write permissions for these files, a malicious program could manage to perform privilege escalation. Yet I find many dotfiles repositories which are unsafe in my book.

In .bashrc, sudo commands can be on /etc/sudoers with NOPASSWD. On bin/*.sh scripts, I was thinking in omitting sudo from commands and chown them to root, but this can be an issue since git doesn't store ownership. (Almost) all individual command require sudo anyways, so I guess technically it's the same, except assigning scripts to root should be safer. Git would cause some trouble I guess.

A thought: if I granted every single command on /etc/sudoers with NOPASSWD, then if root password was requested, I would smell something was off.

Additional information:

• This is for a couple local, single-user machines;
• Unauthorized access to my desktop computer isn't an issue, so I have autologin set up;
• My laptop requires password for starting a session.

If the question is not clear by now, I ask, how can I arrange these scripts/commands in a safe way? Could privilege escalation with root be more harmful than a malicious program on my own user's data? Maybe I'm just overthinking it?

Answer 1

A writeable script can be replaced by something nefarious while you weren't looking, and if root runs it, game over.

True, if you are the one and only user of the machine, the risk is low. But it is often easier to crack the account of a regular user (read email with malware, connected to a malicious website, willy-nilly compiled and ran a random source "to see what it does", ...), and this would allow escalating to root privilege.

Answer 2

Considering all options that I was aware of (/usr/local/bin, owner root, removing write permission), I went with the immutable flag on each versioned file:

sudo chattr +i filename

Non-root users, nor even the owner can't reset the flag. Neither can the file or the parent directory be removed or replaced.

To edit the file, I added the following function to .bashrc:

editrc () {
    sudo chattr -i $1
    nano $1
    sudo chattr +i $1
}

On other computers I have to pull the dotfiles, the flag needs to be removed before git pull, and then re-applied. Made a helper function which takes the flag as argument.

protect-config () {
    FLAG=$1
    FILES=$(git ls-files | xargs -I @ -- find @ -type f | xargs echo)
    lsattr $FILES
    if [ "$FLAG" ]; then
        sudo chattr $FLAG $FILES
    fi
}

That said, yeah, I'm overthinking it. Still, it is in place now. Mostly out of good habit.

---

EDIT: I don't use this anymore, since it was more inconvenient than the sense of security it was adding.