edit root alias when installing the OS

[n0dalus]

On 1/9/06, Tommy Reynolds <Tommy.Reynolds at megacoder.com> wrote:
> Uttered n0dalus <n0dalus+redhat at gmail.com>, spake thus:
>
> > Why should we cripple people's ability to administrate their systems
> > by taking away the root password? If I had to prepend all my commands
> > with 'sudo' and half of my paths with '/sbin' I'd quickly get
> > frustrated and give root a password.
>
> So put "/sbin" on your normal path.
>
> Well, doing a significant amount of work as root does seem to justify
> sudo'ing into the root account:
>
>         $ sudo su -
>
> But the proper /etc/sudoers entry would let only _your_ account run
> _only_ that program and require _your_ password to do it.  At least
> you'd get an audit trail entry as you entered the superuser realm.
> With a root login, you get *nothing*.  Was that a hostile root login?
> You can only hope not.

As said earlier in the thread, it's really easy to make a hostile
operation seem completely innocent in the audit trail -- not to
mention how easy it is to delete the audit trail entirely, or re-setup
sudoers. Audit trails don't help you when it comes to anything
malicious or hostile. It only helps you work out what commands you
ran.

>
> > Just because admins know the root password doesn't mean any malware
> > that manages to sneak on does too. Putting all the users in sudoers
> > means that malware only needs to get a user password for root access,
> > which is usually much easier than obtaining the root password.
>
> Not really.  To break into a UNIX system, I need to have two items: a
> valid account name, and a valid password.  With the "root" account,
> I'm halfway there already.

We are talking about where the malware is already on the computer. In
which case, it knows at least one other username and probably all the
usernames on the computer. Maybe it even knows which users can sudo.
Let's count the number of people that know the root password -- let's
say 5. Let's count the number of users that might be able to sudo --
lets say 10. Now let's count the number of family/friends of those
users (and websites, considering that many users use their user
password for website signups) who know the sudoers' passwords: much
more than the 5 who know the root password. Social engineering,
password cracking and malicious put-your-password-here prompts all
make it magnitudes easier to get root access as more users are put in
sudoers. If Gmail used a Firefox exploit to send me some malware on
Linux, there's a good chance that if they try the password I used to
signup they could get root access on my machine using sudo (if I was
in sudoers, and used the same password as my user account). Yes sudo
shouldn't be blamed for any of this, but the fact remains that the
more users that can sudo, the better chance malware has of getting
root access.

>
> > Weak passwords are not sudo's fault, but statistically the more users
> > in sudoers the easier it becomes to get root access. It doesn't matter
> > how strong the passwords are.
>
> The idea is not to C3 secure the whole environment (that's another
> show ;-) but to help Aunt Minerva (substitute your favorite
> non-technical user name here) get help when something gets bungled
> while in superuser mode.  At least there is an audit trail so the
> help desk can get a glimmer of what was actually done rather than what
> the semi-inept user thought was being done.

Aunt Minerva should not be doing anything as superuser. On occasion
she might be asked to enter the root password into a graphical
dialogue to setup something, but that should be all. If a user can't
handle su -, they shouldn't be using sudo either.

Maybe Fedora should come setup with bash so it logs all commands ran
as root -- this would be more useful for tech support than the sudo
audit trail.

> The goal, at least of my original posting, was to encourage newbies
> to use the sudo method for those times they need superuser privilege.
> Reading the sudo(1) man page gives pause even to seasoned admins and
> probably drives newbies back screaming to Google.com for another
> command.  Yet, sudo(1) is probably the safest was to superuser command
> line access for casual admin activity.  Thus the need to gently steer
> newbies to sudo(1) for, maybe, some set of common root commands.
>
> Sudo(1) is not intended to outlaw su(8) for real admins and power
> users.
>
> As we try to promote Linux on the desktop and in the home, depending
> on more casual admins, we need more audit trails, not fewer, so the
> savy among us can help when disaster ensues.  Sudo(1) or su(8) issues
> aside, disaster _will_ ensue, so why not try for the most well-paved
> path?
>

Let's pave the path for su as well then. ~/.bash_history only stores a
small number of lines by default, but perhaps something else could be
setup to give better logging of commands run as root.

If all commands ran from bash as root were logged somewhere, would
that be sufficient to make su acceptable for casual administration? Is
this a solution that everyone can agree on? I am all for having more
audit trails, but if we can have that without weaking the security of
Fedora by default, then I think that's a better solution.

Sudo is still useful for multi-admin situations, but really only when
sudoers is setup with strict permissions. Nobody should be put in an
allow-everything sudoers by default.

n0dalus.