Currently I have sudoers set up to allow root and myself to run all commands which is clearly not secure. The sudo and sudoers man pages are a bit cryptic on what constitutes a good sudoers file though, and surprisingly I can't find a lot of information online apart from recommendations not to allow normal users unfettered access and to use both sudo and su depending on the task. What I want is probably to be able to use aptitude and synaptic without a password and restrict access to text editors and such (and instead use sudoedit configured to run with something other than vi/vim, I think nano is reasonably secure,) and be able to run user scripts in ~/bin/ with a password. If I need to do anything else like configure/run rkhunter or write to sensitive directories/files and change permissions and whatever I can su to root.

How is this for a sudoers file? Is there something I'm overlooking or is this hypothetical setup insecure in some way or what? I'd also like some tips on how to properly implement this since the syntax is a little confusing (though I understand the basics) and I've heard you do not want to mess up your sudoers file.

Thanks!

In a way, what you're asking is "how high is up?" A 'good' sudoers file for you might be horrible for someone else. Don't think of it in absolutes, think of it as a way to mitigate risk.

You will never, EVER, be able to totally eliminate all risk, so you have to balance security with usability. If it takes you twice as long to do your job and be 'secure', it's pointless...if you add a lot to your administration of the system for very little return, it's also pointless. You can spend hours/days/eons trying to whittle out a sudoers file, so try to keep it broad, and divide up your users:

• Administrators: get a root shell, and do whatever they want. They're the ADMINISTRATORS...they probably already have the root password (or need it sometimes), and will clean up any messes they make and be held accountable. That's the job.
• Admin-helpers, like help desk folks..those are ones who need to run things as root sometimes, but not without oversight. Take their shell access away, and some other commands (like "rm -rF *").
• 'Super-users', like backup administrators who might only need to run a few things as root; they just get those commands, and NOTHING ELSE.

Before you dole them out, though, perform your due diligence. Yes, the backup administrator may need to run the backup client as root..but can they spawn a sub-shell from it? If so, you've just given them root access to the system. Use caution, dole out warnings, and apply the LART vigorously when the rules are broken.

Nano is only on the surface more secure than Vim/Emacs (or other editors), just because, unlike Vim/Emacs, it doesn't allow to run commands or drop to a shell. Nonetheless it isn't secure, just think about the user invoking and altering it to get complete access to the system.

Haha, point taken. But it is generally agreed that giving a compromised user account effective access to a root terminal via sudo is terrible security, right? You might as well use the same password for user and root, it makes no difference. I was really just asking whether there were any inadvertent holes in my "plan," whether introduced by certain freedoms or ignored entirely. Granting that I'm not a POI I can afford some luxuries I otherwise couldn't, but that's no excuse not to lock your door, eh? If there are a million equivalent doors to choose from, it makes sense to just keep looking until you find one that is unlocked rather than bruteforcing one at random and risk getting caught.

Yeah, of course. I'm just looking to take certain basic precautions. If I make it impossible to edit sources.list without root access then leaving the package managers accessible without a password at worst leaves me with a bunch of useless packages or with no packages at all (I back up the list of packages semi-regularly with dpkg --get-selections though.) That kind of pointless destruction is a pretty rare occurrence though, isn't it?

But isn't there a way to make sudoers only accessible via the visudo command, which I would set up to require root access (non-sudoable?) If so, that wouldn't be a concern. Sure, if the user acquires my root password they can do whatever they want with sudoers, but they wouldn't need to by that point.

EDIT: I'm sorry, I forgot to merge my responses before posting.

It is horrible security to have compromised user accounts in the first place. sudo is meant as a way to give restricted users limited access (as fine-grained as possible) to programs that need root privileges. In the first place you should make sure that those user accounts don't get compromised, as far as that is possible (which you point out in your the following sentences.
As far as I remember (haven't used it for a long time) Synaptic gives you the possibility to alter your sources.list.
Possibly. I merely wanted to point out that, especially when it comes to editors, sudo is a thing that really needs serious thought, not only which commands you allow, but also what can be done with those commands. For example, think about a user who is allowed to use Synaptic sets up an additional repository which contains a package that replaces sudoers with a compromised version, does all kind of evil stuff on your system and then restores the old version. All those are things you have to think about, at least when you do this in an enterprise environment.
Off course you can, if you want, be more lax about such things on your home system, especially when you have other safety measures in place (firewall, rkhunter, ...).

In short: When you want to give a user root access to certain programs use sudo. When you want to give the user the ability to alter a specific file use file permissions and access control lists. This way you can get the whole group if editors out of the way.

1 members found this post helpful.

Ah, what I meant was that if a user account becomes compromised (somebody gets a hold of my user password) then they wouldn't be able to do much without also cracking the root password. In other words, not compromised in the sense that the user account is fundamentally compromised (easy to hack,) but compromised in the sense that it has become compromised.

Will have to look out for that, thanks.

Indeed, that is precisely what I was talking about.

Well, yes of course. But my concern is especially with vi's :shell command in conjunction with sudo which is obviously very dangerous. File permissions are rather useless if you allow anybody to become root. You understand that my main point with this exercise though is just to learn good habits.