Sudo instead su (in Ubuntu & other distro)

Limit Permissions with sudo

If you have used a number of different Linux distributions in the past, one surprising thing you'll notice the first time you use Ubuntu is that it disables the root account.

For most other distributions, the installer prompts you for root's password, and when you need to get work done as root, you log in or use the su command to become root, and type in root's password. Since Ubuntu's root user has no password by default, you must use the sudo command to run commands as root. sudo sets up a way to allow access to root or other user accounts with fine-grained controls over what a person can do as that user. Plus the way sudo works is that it prompts you for your password, not that of the other user you want to switch to. This allows an administrator the ability to grant particular types of root access to users on the system without them all knowing the root password.

The default sudo configuration in Ubuntu is pretty basic and can be found in the /etc/sudoers file. Note that you must never edit this file using a standard text editor. You must use the visudo tool. visudo is required because it will perform extra validation on the sudoers file before you close it to make sure there aren't any syntax errors. This is crucial because a syntax error in a sudoers file could lock out all of the users on your system. Here are the roles defined in the default Ubuntu /etc/sudoers file:

# User privilege specification
root ALL=(ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

• The first rule allows root to use sudo to become any other user on the system, and
  
• the second rule allows anyone who is a member of the admin group to run any command as root. So when you want to run a command as root on a default Ubuntu system, type sudo followed by the command to run.
  

For instance if you wanted to run apt-get update as root, you would type:

$ sudo apt-get update 

/etc/sudoers Syntax
To fully explain the syntax of /etc/sudoers, we will use a sample rule and break down each column:

jorge ALL=(root) /usr/bin/find, /bin/rm

1. The first column defines what user || group this sudo rule applies to. In this case, it is the user jorge. If the word in this column is preceded by a % symbol, it designates this value as a group instead of a user, since a system can have users and groups with the same name.
2. The second value (ALL) defines what hosts this sudo rule applies to. This column is most useful when you deploy a sudo environment across multiple systems. For a desktop Ubuntu system, or a system where you don't plan on deploying the sudo roles to multiple systems, you can feel free to leave this value set to ALL, which is a wildcard that matches all hosts.
3. The third value is set in parentheses and defines what user or users the user in the first column can execute a command as. This value is set to root, which means that jorge will be allowed to execute the commands specified in the last column as the root user. This value can also be set to the ALL wildcard, which would allow jorge to run the commands as any user on the system.
4. The last value (/usr/bin/find, /bin/rm) is a comma-separated list of commands the user in the first column can run as the user(s) in the third column. In this case, we're allowing jorge to run find and rm as root. This value can also be set to the ALL wildcard, which would allow jorge to run all commands on the system as root.
   

Show It's Working
To take advantage of his sudo role, jorge would use the sudo command on the command line followed by the program to execute:

jorge@ubuntu:~$ sudo find . ! -name '*.mp3' -exec rm -f \\{\\} \\;

If jorge tried to run a command other than find or rm, sudo would fail with a warning that he is not allowed to run that command as root.

You can use sudo to run commands as users other than root. If you don't specify a user, sudo defaults to the root user, but you can use the -u flag to designate a particular user to run as:

$ sudo -u fred ls /home/fred

As you can see, these rules allow you to create specific roles on a system. For instance, you might want to designate a group of administrators as account administrators. You don't want these users to have full root access, but you do want them to be able to add and remove users from the system.

1. You could create a group on the system called accounts and add these users to that group
   
2. Then you could use visudo to add the following line to /etc/sudoers:

   %accounts  ALL=(root) /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermod

Now any member of the accounts group can run useradd, userdel, and usermod. If you found there were other tools this role needed to access, you could simply add them to the end of the list.

WARNING--- when we define particular commands a user can run, we list the full path to the command. This is for security reasons. If, for instance, we just put useradd instead of /usr/sbin/useradd, the user could create her own script called useradd that did whatever she wanted and put it in her local path. Then she would be able to essentially run any command she wanted as root via that local useradd script.

Another handy feature of sudo is the ability to specify commands that don't require a password to run. This is useful if you need to run certain commands as root within a script non interactively. For instance, you may want a user to be able to run the kill command as root without requiring a password (so the user can quickly kill a runaway process, for instance). To enable this privilege, add the NOPASSWD: attribute before the command list. To grant this ability to our jorge user, we would add the following line to /etc/sudoers:

jorge ALL=(root) NOPASSWD: /bin/kill, /usr/bin/killall

Then jorge could run:

jorge@ubuntu:~$ sudo killall rm

to quickly kill a runaway rm process as root.



Enable the root Account
So sudo is all well and good, but what if you just want to go back to an enabled root account that you access with su? Essentially, all you need to do is set the root password:

$ sudo passwd root

Now you should be able to log in directly as root, as well as use su.

sudo is an incredibly powerful tool, and this hack covers only some of the configurations that might be useful to a desktop user. If you want to deploy sudo across an enterprise, check out the sudoers manpage (man 5 sudoers) to see examples of how to configure a number of aliases to define

• user groups,
  
• groups of users to run commands as,
  
• host aliases, and
  
• command aliases.
  

This modular approach to defining roles really comes in handy when deploying across a large number of computers.

Manage Security Updates

There is an old saying that the only safe computer is one that's disconnected from the network, turned off, and locked in an underground bunkerand even then you can't be sure! Keeping your computer up-to-date with the latest security patches is essential if you want to keep yourself safe from the latest threats and exploits.



Ubuntu Update Policy
When each version of Ubuntu is released, all packages within it are considered "frozen." No new versions of software contained in that release are added to it, so when you install Ubuntu Dapper Drake, the versions of all the software available within that release will remain the same indefinitely. New versions of individual packages are not added because that would make the release a moving target rather than a predictable environment and might even introduce new bugs and security vulnerabilities.

Of course, software itself doesn't stand still; new versions are always coming out, and sometimes an existing vulnerability is found and fixed by a new release. That means older versions of the software may still be vulnerable, but Ubuntu policy dictates that new versions of software are not shoe-horned into an already released distribution.
This impasse is resolved by back-porting security fixes to the version of the software that was included with the distribution at the time of release and then releasing a "security update" package for just that particular piece of software. System administrators can then install the security update, safe in the knowledge that they are fixing only a specific security problem and not changing the fundamental way the system operates.



Obtain Security Updates(Whithout Synaptic gui)
Security updates are distributed from special package repositories, so check your /etc/apt/sources.list to make sure you have entries that match your main package sources, like this:

deb http://archive.ubuntu.com/ubuntu dapper main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu dapper-security main restricted

Note that there are no security updates available for the universe and multiverse sources because they are not officially supported by the Ubuntu security team.



Automate Update Notifications
The Ubuntu desktop comes with a panel applet called update-notifier that pops up an alert if any new packages have been released since your machine was last updated, but if you are running a headless server, you can set up a trivial script to notify you via email directly from the server.

Place the following in /etc/cron.daily/notify-updates:

#!/bin/sh
apt-get -qq update
apt-get -qq --simulate dist-upgrade

Then make it executible:

$ sudo chmod +x /etc/cron.daily/notify-updates 

• The -qq flags tell apt-get to run in "really quiet" mode so it produces no output unless it really needs to, so apt-get -qq update causes it to silently fetch the latest list of packages from the package servers.
  
• The --simulate flag causes the dist-upgrade to be done in a dry-run mode that pretends to upgrade all available packages without really doing it, and if there are no packages available for upgrade, it will also complete silently.

Because this script is being called by cron, it will be triggered every day, and if it produces no output, cron will just silently move on. However, if there are packages available for upgrade, the dist-upgrade command will generate output listing all packages that can be upgraded, and cron will email the output to the system administrator, who can then decide whether to apply the updates manually. If cron does not send email to the right person, you may need to edit /etc/crontab and put in an entry near the top similar to:

MAILTO=user@example.com




Package Signatures
Packages distributed through the official Ubuntu archives are cryptographically signed so that you can verify that the packages haven't been tampered with or forged using a man-in-the-middle attack. The official archive keys are included in the ubuntu-keyring package and installed in /etc/apt/trusted.gpg by default as part of Dapper. You can use the apt-keys tool to verify and manage the keys that are trusted by your system when new packages are installed:

harrykar@harrykar-desktop:~$ sudo apt-key list
[sudo] password for harrykar:
/etc/apt/trusted.gpg
--------------------
pub   1024D/437D05B5 2004-09-12
uid                  Ubuntu Archive Automatic Signing Key 
sub   2048g/79164387 2004-09-12

pub   1024D/FBB75451 2004-12-30
uid                  Ubuntu CD Image Automatic Signing Key 

pub   1024R/247D1CFF 2009-01-21
uid                  Launchpad PPA for OpenOffice.org Scribblers

pub   1024D/B8C0755A 2008-09-13
uid                  Adam Blackburn 
sub   2048g/CF3C3262 2008-09-13

pub   1024D/BA62BC7E 2003-07-28 [expires: 2009-08-16]
uid                  Stéphane Galland (sgalland-cgc) 
sub   1024g/25721C4B 2003-07-28 [expires: 2009-08-16]

pub   1024R/365C5CA1 2009-01-22
uid                  Launchpad PPA for transmissionbt

pub   1024R/0624A220 2009-01-19
uid                  Launchpad PPA for TualatriX

pub   1024R/05F4C15A 2009-01-28
uid                  Launchpad PPA for Ubuntu Mono Maintainers

pub   1024D/5416E75D 2009-02-04
uid                  Dan Repository (le-web.org) 
sub   2048g/ABE42BFA 2009-02-04

pub   2048R/FF95D333 2009-05-14 [expires: 2010-05-14]
uid                  powdarrmonkey Automatic Archive Signing Key 

harrykar@harrykar-desktop:~$

If you attempt to install any packages that originated in archives that aren't verified by one of those trusted keys, apt will complain but allow you to proceed anyway if you choose y:

WARNING: The following packages cannot be authenticated!
myprogram lib-blah lib-foo
Install these packages without verification [y/N]?

Monitor Security Advisories
One of the most important sources of up-to-the-minute information on threats and vulnerabilities is CERT (Computer Emergency Response Team), run by the Carnegie Mellon University's Software Engineering Institute. The CERT Coordination Center (CERT/CC) acts as a global clearing-house for advisories relating to computer security, and even makes its advisories available as RSS and Atom news feeds so you can stay on top of the latest problems as they come to light.
However, the CERT advisory listing can be overwhelming because it includes notifications for all operating systems and software packages. A much more concise list of advisories that relate directly to Ubuntu is available online at USN (Ubuntu Security Notices), along with links to the Ubuntu Security Announcements mailing list and list archives. If you believe you have found an unreported vulnerability in an Ubuntu package, you can contact the Ubuntu security team via email at security@ubuntu.com.