On 6/17/07, Freddie Rosario <frosario777@xxxxxxxxx> wrote:
I know that Ubuntu disables the root account by default and automatically
enables the first user added to the system to have sudo access. That might
not be a bad idea as it guards against brute force attempts against the root
account. That would be a good argument in favor of that change but can
anyone think of any reasons against this sudo setup?
Giving some users sudo access by default can easily make things less
secure. It means that accessing root becomes as easy as finding a
standard users' password. If there is some exploit successfully
executed on the user's account, I estimate chances are very high that
they can find the account's password saved in either the browser or
desktop environment settings and quickly gain root access.
While some people take the effort to use a different root password and
keep it separate from other passwords, very few people separate their
user account password from the myriad of other authentications, and
they shouldn't have to. It's reasonable and sensible that people reuse
their more trivial passwords, and for them to save their commonly used
passwords in commonly used applications.
To my recollection, these are said advantages of sudo: (I will discuss
them and ways of implementing them without needing regular users to be
in sudoers directly)
1) Don't have to repeat password as often
For people who want this feature, it is better written as a pam module
instead, which would allow it to be used for su, sudo and any other
access mechanisms (very extensible).
2) Commands are logged.
While I have seen this touted as a security feature, it really
provides no security. All it takes is a "sudo sh" or "sudo
innocuous_looking_script" and that's all you get to see in the log
(and even that can be easily erased from a local log after root
privileges are gained). For general logging purposes, bash_history is
far more useful.
3) Easier to type sudo blah etc than su -c "blah etc"
Handy, though it would be trivial to write a wrapper script which does
su -c "...".
4) Allows the root user to be disabled.
Disabling the root user is not all that helpful. I recommend that root
access be disallowed in {g,k,x}dm and ssh_config, but a root account
is still good to have. If you want to restrict who is able to run su,
or whether or not root can log in on vt's, this is better done in
/etc/pam.d/su, /etc/pam.d/login and /etc/securetty.
5) Gives fine-grained access controls to root privileges.
This is the only real advantage of sudo, and it's what it was designed
for. While not many people would actually need this (there's usually
only one person who needs root access), it can be setup in a way that
minimises impact to security. The concept here is that if you need to
share the root password with several people, it becomes very difficult
to ever change the password or keep it from leaking. So instead what
you do is give these people separate access to root, via individual
username+passwords and sudo. This way access can be revoked if it's
ever necessary.
From a security perspective, the passwords for these accounts should
be treated as with superuser accounts. The problem I have with sudo as
it is used in Some Other Distros (TM) is that regular desktop user
accounts are added to sudoers. If sudo is to be used (which I am all
for), passwords should be separate from the normal passwords for a
desktop user.
The usual way this is done is by having separate user accounts (one
for each person that needs root access) which are meant to exclusively
be used for doing privilege escalation. So people have a separate
account for their day-to-day work and their web browsing and document
writing, and su in to the special account to use sudo from there.
A better way of giving users this kind of access is to allow the
password to go from user -> root to be set to a different password
than their usual login password (which would be essentially the same
as having a second user). This could be implemented with a pam module,
so users trying to sudo are not asked for their own password but a
second password they set (and any dialogue would be clearly labelled
to make clear which password was being asked for). This could then be
integrated into consolehelper.
Just my 2 cents,
n0dalus.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
