For a user who may run arbitrary commands with sudo, changing environments variables is not a direct security issue. If you like, you can run tmp=$(mktemp); export >$tmp; sudo bash -c ". $tmp; exec bash" — in other words, save the environment and restore it inside the root shell.
As you note, a trojan in a configuration file is not a concern, since the trojan could put a wrapper around sudo anyway (and grab your password while it's at it).
The topic has come up a few times in the Ubuntu mailing lists (1 2). Ubuntu doesn't reset HOME. David Mandelberg's arguments cover most of the case for resetting HOME.
Resetting HOME protects against exploitation of mistakes you might make. For example, one of your configuration file might contain a temporary file vulnerability that could be exploited to gain access to the root account. This example is, as before, not really a concern since the exploit could equally affect your account first and then hook into your call of sudo.
Resetting HOME also protects against mistakes you might make, and this is where the case for doing it has a point — but not a very convincing one.
- There's an extreme view that says that you should stick to the default configuration as root. This way, anything done as root is easily distinguishable from what to do under your own customized account, so you won't forget that you're acting as root. Also doing things as root is painful so that you are incited to use the root account as little as possible. I don't buy this: doing things “the hard way” instead of the way you're comfortable with makes it more likely to make mistakes, not less. It's normally easy enough to know whether you're acting as root: if you're editing a file under
/etc, you're root¹. If you're running a shell and the prompt ends with # instead of $ or % (following the usual convention), you're root — and you can use things like colors to make the distinction more visible. If you're running a package management program, you're root.
- You might mistakenly leave a confidential file lying around in a publicly readable location in your home directory, believing it to be in
/root. Or you might leave it in /tmp… This argument seems really far-fetched to me. Sure, it's a mistake you might make, but it's not any more likely than, say, mistakenly adding a firewall rule that leaves everything open, or making /bin/* world-writable.
- One of your configuration files might cause confidential information to pop up in your home directory. This is plausible − it could be a history file or an autosave file — but these files would presumably be in a private location anyway, otherwise people could snoop on you.
- Applications that automatically save their configuration might write to your home directory. This is not so much a security concern as a matter of convenience for you, and it's more than offset by the convenience of having your usual configuration when acting as root.
- You might mistakenly edit files under
~, thinking that this is root's home directory when it is actually you home directory. Yes, but if $HOME is your home directory, then you'll also have your usual configuration, so you're less likely to think that you're running as the root user and more likely to think that you're running in a privileged mode. This argument is hoisted by its own petard.
Scott James Remnant put it this way:
"sudo -s" is for lazy people who don't want to duplicate config files, "sudo -i" is for forgetful people.
But sudo -i (run a root shell) seems like a bad idea for forgetful people. And duplicating configuration files as root is only possible on a single-user machine, in which case running as root isn't such a big deal in the first place.
Conclusion: no, there aren't any serious security concern, and the case for resetting HOME is pretty weak. The purpose of always_set_home is to protect you against yourself, but it protects so little that it isn't worth it.
¹ Except that you shouldn't be running an editor as root: use sudoedit or Emacs (Tramp)'s sudo method to run the editor as your normal user.
