0

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?

  • 2
    That last paragraph reminds me of xkcd.com/1200 – muru Mar 10 at 4:14
  • 1
    If the machines are yours, and you're the only user, then you're almost certainly overthinking it. Personally I'd put root-run utilities in /usr/local/bin. – roaima Mar 11 at 8:41
0

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.

| improve this answer | |
  • Assuming an incident such as these happens, which measure I should have taken to stop privilege escalation regarding the 'sudo scripts'? – André Werlang Mar 11 at 2:32
  • @AndréWerlang reinstall from scratch. You are toast. – vonbrand Mar 13 at 23:00
  • Thanks, but re-reading my previous comment I see it is not what I meant... I wanted to say 'prevent before it takes place', not 'stop while it is taking place' :) – André Werlang Mar 13 at 23:09
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.