FAQ
|
Size: 14680
Comment:
|
Size: 15869
Comment: add gnome-keyring entry
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 39: | Line 39: |
== Versions == Ubuntu releases security updates by patching specific issues rather than updating whole versions of software. This is to keep the packages in a stable release as close to their original version as possible to avoid introducing unintended regressions. For more details, see [[StableReleaseUpdates#Why|Stable Release Updates]]. |
|
| Line 106: | Line 109: |
| === Rescue Mode === * I am not prompted for a password when going into rescue mode! * This is related to 'sudo', above. Because in Ubuntu there is no root password, there is nothing to prompt for. In general, not prompting for a password in single user mode does not decrease security because it requires physical access to the machine. An attacker with physical access can bypass this restriction easily (eg with bootable media or removing the hard drive). If you decide to set a root password, you will be prompted for it in rescue mode. |
|
| Line 110: | Line 117: |
| === gnome-keyring === '''Q:''' Does using ```gnome-keyring``` weaken security? '''A:''' For most users in typical environments, no. Basically, [[http://live.gnome.org/GnomeKeyring|gnome-keyring]] can store passwords for you. The passwords are stored in keyrings that are not available to applications until the keyring is unlocked. A common keyring is the 'login' keyring, but others can be used. Once the keyring is unlocked, applications can ask gnome-keyring for passwords and use them so that users don't have to remember them all, or be hassled with password prompts all the time. A keyring can be locked after it is unlocked. Because gnome-keyring uses protected memory, other users on the system cannot access the keys within a user's keyring (see man mmap for PROT_READ, PROT_WRITE, MAP_PRIVATE, and MAP_ANON). Gnome/Ubuntu integration does a few things (see the [[http://live.gnome.org/GnomeKeyring/Pam|upstream documentation]] for more details): * The 'login' keyring is configured, via PAM, to be automatically unlocked upon successful authentication via PAM (ie, when you login) * When the PAM session is closed via the screensaver, all keyrings are locked, and the 'login' keyring is unlocked upon successful authentication to the screensaver * All keyrings are locked on logout of the user's session This provides: * A good usability experience * Protection against access from anyone to keys when the user is not authenticated * Protection against other users on the system at all times Some people may not like to use keyrings in general and there are certain environments where their use is not appropriate. Users can always choose to not store their passwords in the keyring at all. Furthermore, gnome-keyring behavior can be adjusted: * Temporarily by using ```seahorse``` and manually locking the unlocked keyring * Permanently by changing the passphrase of the 'login' keyring * Permanently by removing gnome-keyring from the PAM stack Please note that by changing this behavior, programs that need access to the unlocked passwords will prompt you for the keyring passphrase whenever they need it. In general, using a keyring does not weaken the security of the system. To use them safely^1^: * You should choose a strong login passphrase (eg, using a mixture of letters, numbers, capitalization and non-alphanumerics that is at least 8 (preferably 12 or more) characters long and not subject to a dictionary attack). This login passphrase should be memorized, and not written down. * You should always lock your screen when you step away from your system. You can set a short inactivity timeout and/or better yet, use 'ctrl+alt+l' or activate the screensaver from within your session every time you step away. Notice that ''these recommendations are no different from when you are not using a keyring'' (ie, you always want a strong login passphrase and to lock your screen). [1] if you leave your computer powered on in an environment where it might be stolen (eg, a hotel room), software techniques cannot protect you. In general, in these environments the computer should be completely powered off and use disk encryption. Disk encryption as well as discussion to mitigate hardware, firmware, BIOS, cold-boot or 'evil maid' attacks are beyond the scope of this FAQ). |
|
| Line 113: | Line 152: |
| actually done intentionally. Several classes of issue are not considered bugs in Ubuntu security: |
actually done intentionally. Please review the [[SecurityTeam/Policies|Ubuntu Security Policies]]. |
| Line 116: | Line 154: |
| === Unblocked Physical Access === While every attempt is made to securely isolate physically local users of a shared computer from one another, the stock Ubuntu installation is not intended to block an attacker with physical access. If this is a priority for your system, it is recommended that you take advantage of hard drive encryption, BIOS passwords, and other mechanisms designed to increase physical access security. By default, Ubuntu's root user does not have a password. As a result, the "safe" and "recovery" modes (which require console access) will allow root to log in without a password. Since these systems use "sulogin", once a root password has been set, these modes will require the root password to start up. If this is desired, set a password with "sudo passwd root". === Local Denial of Service === The default Ubuntu configuration is designed to handle multiple users sharing resources. Because of this, it is possible for a single user to accidentally (or intentionally) use up all of a shared resource (e.g. CPU time, memory, hard drive space). A common example of this is a "fork-bomb", or filling all available disk space. If resource limits are a priority for your system, please investigate using ulimits and disk quotas to help limit resource over-usage. === Permissive Home Directory Permissions === By default, Ubuntu is designed to allow users to easily share files and help each other ([[https://bugs.launchpad.net/bugs/48734|see bug 48734]]). To support this, each user's default home directory is readable by all other users. Private files could be kept in the "Private" sub-directory, where access permissions can be set to limit access by other users (mode 0700). If restrictive home directory permissions are a priority for your system, please investigate the {{{/etc/adduser.conf}}} file for adjusting various settings when creating new users, including the default permission mask for newly created home directories. === Local Network Privacy === There are no open service ports on a default Ubuntu system. The exceptions to this are the DHCP client and mDNS (Avahi). For DHCP and mDNS to work fully, the local hostname is used when handling certain DHCP and mDNS actions. As such, the hostname of a system is not considered private information and is shared with the local network. By default, user names are not available to the local network. However, they may become shared with the local network when various mDNS-announcement services are enabled (e.g. Rhythmbox Music Sharing, Remote Desktop, etc). As such, it is best to consider individual local user names as public, but the list of all users on a system as private. For this reason, any mechanisms that allow an unauthenticated way to query for a list of all local user names should be considered a security issue. ## The above section is quoted in DebuggingSecurity, so if you add anything here, please ## adjust the Regex to match the new end, and not the line starting with four "-"s: |
Official Support
- What does official security support mean?
Members of the Ubuntu Security team are Canonical employees who provide security updates for supported software in the Ubuntu distribution. Security updates are in part prioritized based on severity of impact, exploitability and number of affected users.
- What software is officially supported by the Ubuntu Security team?
Ubuntu is currently divided into four components: main, restricted, universe and multiverse. Packages in main and restricted are supported by the Ubuntu Security team for the life of an Ubuntu release, while packages in universe and multiverse are supported by the Ubuntu community.
- Who can receive official support?
Official support is provided free of charge to all users of Ubuntu during the life of an Ubuntu release.
Repositories
- How are the "-updates" and "-security" pockets different?
-updates includes things that have gone through the StableReleaseUpdates process, and contain various important bug fixes.
-security includes only updated packages that contain security-related fixes, and are built to not require anything from "-updates".
- How are components and pockets used in the builds, and how do they affect security updates?
- When packages are built, only certain components are available during the build:
main: built with only the main component enabled
restricted: built with main and restricted components enabled
universe: built with main and universe components enabled
multiverse: built with main, restricted, universe and multiverse components enabled
Ubuntu also has several pockets that further divide the archive: release, security, updates, proposed and backports. The pocket can be found by looking at the Distribution entry of a source package. The release pocket is simply the name of the release, and the other pockets are denoted by <release name>-<pocket>. For example, the release pocket for Ubuntu 8.04 LTS, the Hardy Heron, is simply hardy, while the security pocket for Ubuntu 8.04 LTS is hardy-security. Packages in release, security and updates are supported by the Ubuntu Security team, while packages in backports are supported by the community and packages in proposed are the responsibility of the uploader. When packages are built, only certain pockets are available during the build:
release: during the development cycle, this is the only pocket that is used. Once the development version is released, the release pocket is frozen and does not change.
security: built with release and security. UpdateProcedures gives the process used for creating security updates.
proposed: built with release, security, and updates
updates: packages in updates are not directly built, but rather copied from proposed after they have been tested. See StableReleaseUpdates for details.
backports: built with release, security, and updates. See UbuntuBackports for details.
- When packages are built, only certain components are available during the build:
- How do I automatically install security updates?
Packages
Where did mod_security go?
- The license to mod_security did not allow for redistribution, so it was removed from Debian and Ubuntu after 6.06 (Dapper):
- The licensing issue has been resolved and mod_security is back in the archive as of Ubuntu 9.04 (Jaunty):
Versions
Ubuntu releases security updates by patching specific issues rather than updating whole versions of software. This is to keep the packages in a stable release as close to their original version as possible to avoid introducing unintended regressions. For more details, see Stable Release Updates.
Architectures
Ubuntu is built for many architectures. Officially supported architectures for a particular release of Ubuntu can be found in http://archive.ubuntu.com/ubuntu/dists/<release>/main/ and ported architectures (where maintenance is best-effort) are in http://ports.ubuntu.com/dists/<release>/main/.
Release |
amd64 |
armel |
hppa |
i386 |
ia64 |
lpia |
powerpc |
sparc |
Dapper |
yes |
-- |
ports |
yes |
ports |
-- |
yes |
yes |
Edgy1 |
yes |
-- |
ports |
yes |
ports |
-- |
yes |
yes |
Feisty1 |
yes |
-- |
ports |
yes |
ports |
-- |
ports |
yes |
Gutsy1 |
yes |
-- |
ports |
yes |
ports |
-- |
ports |
yes |
Hardy |
yes |
-- |
ports |
yes |
ports |
yes2 |
ports |
ports |
Intrepid |
yes |
-- |
ports |
yes |
ports |
yes2 |
ports |
ports |
Jaunty |
yes |
ports |
ports |
yes |
ports |
ports |
ports |
ports |
Karmic |
yes |
ports |
-- |
yes |
ports |
ports |
ports |
ports |
- Release has reached end of life and is no longer officially maintained
- While LPIA is listed in ports.ubuntu.com for this release, it should be considered a supported architecture
Endianness
Sometimes a security vulnerability affects a particular architecture or endianness. Most architectures in Ubuntu are little-endian, some are so-called bi-endian and some big-endian. In Ubuntu, the endianness of a particular architecture can be see in the following table:
Architecture (hardware name) |
Little Endian |
Big Endian |
amd64 (x86_64) |
yes |
-- |
armel (armv5tel) |
yes |
-- |
hppa (parisc) |
-- |
yes |
i386 (i686) |
yes |
-- |
ia64 |
yes |
-- |
lpia |
yes |
-- |
powerpc (ppc64) |
-- |
yes |
sparc (sparc64) |
-- |
yes |
Software
SSH
When I run ssh HOST sudo CMD..., I can see the password as I type it. How do I fix that?
There is no "tty" allocated when running commands directly via ssh, please add the "-t" flag.
- When I connect to my ssh server port, I can see a banner with the exact version I'm running. Can we include a patch to disable the version number?
There is an upstream bug that gets into detail about this feature, but Ubuntu does not want to carry the patches unless upstream approves.
Hiding the version number is Security through obscurity, which is not real security.
- SSH clients, including OpenSSH, usually parse the version string in order to identify known bugs/features with a particular version of the server. Changing the values could introduce communication problems with certain clients. See compat.c in the OpenSSH source code.
Sudo
- Why does Ubuntu disable the root account and use sudo instead?
See RootSudo for a thorough discussion, but simply put, sudo offers many benefits including (but not limited to):
- protecting the user from accidentally damaging parts of the system
- providing a log audit trail
- preventing brute-force login and ssh attacks to a well known account
- authentication timeouts
- fine-grained granting of privileges
- I am not prompted for my password when I run "sudo" for a second time!
sudo is design to keep a "ticket" valid for 15 minutes after you use your password the first time. This is configurable. Please read man sudoers:
timestamp_timeout Number of minutes that can elapse before sudo will ask for a passwd again. The default is 15. Set this to 0 to always prompt for a password. If set to a value less than 0 the user’s timestamp will never expire. This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respec‐ tively.
- If sudo authentication does not immediately expire, doesn't that allow for privilege escalation for malware and local users?
- Giving untrusted users access to your account or running untrusted code can allow privilege escalation via sudo, but Ubuntu does not (and by default cannot) provide protections against users running code as themselves. Some protections against these sort of attacks are:
- do not open files or run/install programs from untrusted sources
- enable locking of your screensaver
- using 'sudo -k' or 'sudo -K' to remove the timestamps (see 'man sudo' for details)
- adjusting timestamp_timeout in /etc/sudoers (using visudo) (see above, and 'man sudoers' for details)
- using a virus scanner such as clamav on your files
- Giving untrusted users access to your account or running untrusted code can allow privilege escalation via sudo, but Ubuntu does not (and by default cannot) provide protections against users running code as themselves. Some protections against these sort of attacks are:
Rescue Mode
- I am not prompted for a password when going into rescue mode!
- This is related to 'sudo', above. Because in Ubuntu there is no root password, there is nothing to prompt for. In general, not prompting for a password in single user mode does not decrease security because it requires physical access to the machine. An attacker with physical access can bypass this restriction easily (eg with bootable media or removing the hard drive). If you decide to set a root password, you will be prompted for it in rescue mode.
UFW
Why is the ufw firewall not enabled by default?
ufw is available in all new installations of Ubuntu since 8.04 LTS, but is disabled by default. The standard Ubuntu installation has a no open service ports policy, so enabling the firewall by default doesn't gain any extra security in the default installation, but could provide confusion for people new to Ubuntu when new software that is installed does not work because of restrictive firewall rules. As a result, when first adding ufw to Ubuntu it was decided that users must 'opt-in' to using the firewall. In Ubuntu 9.04 and later, you can enable ufw during installation using preseeding. See /usr/share/doc/ufw/README.Debian for details.
gnome-keyring
Q: Does using gnome-keyring weaken security?
A: For most users in typical environments, no.
Basically, gnome-keyring can store passwords for you. The passwords are stored in keyrings that are not available to applications until the keyring is unlocked. A common keyring is the 'login' keyring, but others can be used. Once the keyring is unlocked, applications can ask gnome-keyring for passwords and use them so that users don't have to remember them all, or be hassled with password prompts all the time. A keyring can be locked after it is unlocked. Because gnome-keyring uses protected memory, other users on the system cannot access the keys within a user's keyring (see man mmap for PROT_READ, PROT_WRITE, MAP_PRIVATE, and MAP_ANON).
Gnome/Ubuntu integration does a few things (see the upstream documentation for more details):
- The 'login' keyring is configured, via PAM, to be automatically unlocked upon successful authentication via PAM (ie, when you login)
- When the PAM session is closed via the screensaver, all keyrings are locked, and the 'login' keyring is unlocked upon successful authentication to the screensaver
- All keyrings are locked on logout of the user's session
This provides:
- A good usability experience
- Protection against access from anyone to keys when the user is not authenticated
- Protection against other users on the system at all times
Some people may not like to use keyrings in general and there are certain environments where their use is not appropriate. Users can always choose to not store their passwords in the keyring at all. Furthermore, gnome-keyring behavior can be adjusted:
Temporarily by using seahorse and manually locking the unlocked keyring
- Permanently by changing the passphrase of the 'login' keyring
- Permanently by removing gnome-keyring from the PAM stack
Please note that by changing this behavior, programs that need access to the unlocked passwords will prompt you for the keyring passphrase whenever they need it.
In general, using a keyring does not weaken the security of the system. To use them safely1:
- You should choose a strong login passphrase (eg, using a mixture of letters, numbers, capitalization and non-alphanumerics that is at least 8 (preferably 12 or more) characters long and not subject to a dictionary attack). This login passphrase should be memorized, and not written down.
- You should always lock your screen when you step away from your system. You can set a short inactivity timeout and/or better yet, use 'ctrl+alt+l' or activate the screensaver from within your session every time you step away.
Notice that these recommendations are no different from when you are not using a keyring (ie, you always want a strong login passphrase and to lock your screen).
[1] if you leave your computer powered on in an environment where it might be stolen (eg, a hotel room), software techniques cannot protect you. In general, in these environments the computer should be completely powered off and use disk encryption. Disk encryption as well as discussion to mitigate hardware, firmware, BIOS, cold-boot or 'evil maid' attacks are beyond the scope of this FAQ).
Design
Many common issues come up that may seem to be security design problems, but are actually done intentionally. Please review the Ubuntu Security Policies.
SecurityTeam/FAQ (last edited 2026-01-22 22:33:01 by seth-arnold)