FAQ
Size: 926
Comment:
|
Size: 51788
Comment: Update cve tracker link
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
#acl ubuntu-security:read,write,delete,revert All:read | |
Line 5: | Line 6: |
{{{ This page is still very much a place-holder. If you have time, please update it with more information. }}} |
== Standard Support == * What does standard security support mean? * [[http://www.canonical.com|Canonical]] employees working on the Ubuntu Security Team provide [[SecurityTeam/KnowledgeBase#Announcements|security updates]] for supported software in the Ubuntu distribution. Security updates are in part [[https://people.canonical.com/~ubuntu-security/priority.html|prioritized based on severity of impact, exploitability and number of affected users]]. * Previously referred to as "Official Support" * What software is supported by the Ubuntu Security team? * Ubuntu is currently divided into four components: `main`, `restricted`, `universe` and `multiverse`. All binary packages in `main` and `restricted` are supported by the Ubuntu Security team for the [[TimeBasedReleases|life of an Ubuntu release]], while binary packages in `universe` and `multiverse` are supported by the Ubuntu community. * Who can receive standard support? * Standard Support is provided free of charge to all users of Ubuntu during the [[https://wiki.ubuntu.com/Releases|life of an Ubuntu release]]. * How do [[https://wiki.ubuntu.com/SeedManagement|seeds]] impact standard support? * Seeds determine in which component a package resides. All binary packages in the `main` and `restricted` components receive support for the [[https://wiki.ubuntu.com/Releases|life of an Ubuntu release]]. * The `Supported` field in the `Packages` file for the `main` and `restricted` components may be inaccurate, especially in the case of non-LTS releases. Today, all releases have unified support lengths. * What is extended support? * [[https://ubuntu.com/pro|Ubuntu Pro]] customers may receive additional security support beyond what is freely available via standard support. * [[https://ubuntu.com/esm|ESM]] customers (ESM is included in Ubuntu Pro) can receive security updates for high and critical CVEs (common vulnerabilities and exposures) for the the entire collection of software packages shipped with Ubuntu, including the Ubuntu Universe repository, for 10 years. * A FAQ specifically about the security patches included in Ubuntu Pro is available [[https://discourse.ubuntu.com/t/ubuntu-pro-faq/|here]]. * How will support for Ubuntu Touch be provided? * As of 2017/06/15, Ubuntu Touch no longer receives security support. * How will support for Ubuntu Core be provided? * Ubuntu Core 15 security updates will be provided via its [[https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages|PPA overlay]] only. Ubuntu Core 16 inherits security updates from Ubuntu 16.04. Ubuntu Core 16 snaps are automatically refreshed via the [[https://snapcraft.io/docs/core/usage|snap automated update]] mechanism. == Repositories and Updates == === How are the "-updates" and "-security" pockets different? === ==== TLDR; ==== * {{{-updates}}} includes things that have gone through the [[StableReleaseUpdates]] process, and contain various important bug fixes. Anything built for "-updates" is built on top of which ever version of a package is newest between "-updates" and "-security", so that nothing in "-updates" will introduce security regressions. * {{{-security}}} includes only [[SecurityTeam/UpdateProcedures|updated packages]] that contain security-related fixes, and are built to not require anything from "-updates". Anything built for "-security" is built on top of which ever version of a package is newest between "-updates" and "-security", so that nothing in "-security" will introduce bug regressions. When the security team prepares updates for the "-security" pocket they take whichever is the highest version from either the "-updates" OR the "-security" pocket and then patch that and release it to the "-security" pocket. As such, "-security" can end up containing some changes from "-updates". This is due to the nature of package versioning and to ensure that for all users (regardless of whether they have only "-security" or both "-security" + "-updates" enabled) that they can always upgrade to the security updated version (ie. the version number has to be strictly greater than anything prior to that from both "-updates" and "-security"). When doing security updates, any required dependencies that are not already in the "-security" pocket are also copied over from the "-updates" pocket as needed. === 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 16.04 LTS, the Xenial Xerus, is simply `xenial`, while the security pocket for Ubuntu 16.04 LTS is `xenial-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`. [[SecurityTeam/UpdateProcedures|UpdateProcedures]] gives the process used for creating security updates. * '''proposed''': built with `release`, `security`, `updates` and `proposed` * '''updates''': as a matter of Ubuntu policy, packages in `updates` are not directly built, but rather copied from `proposed` after they have been tested. See [[StableReleaseUpdates|StableReleaseUpdates]] for details. If a special circumstance warrants building a package in `updates` without going through `proposed` first, it would be built with `release`, `security` and `updates` (also, the default configuration for unofficial PPAs is to build with this configuration). * '''backports''': built with `release`, `security`, `updates` and `backports`. See [[UbuntuBackports|UbuntuBackports]] for details. === What repositories and pockets should I use to make sure my systems are up to date? === * By default, Ubuntu systems have both the `security` and `updates` pockets enabled. Systems configured to use only the `security` pocket are also supported. (This requires installing from the original release media, as the point release media contains packages from the `updates` pocket and will result in difficulties running with only the `security` pocket enabled.) * While packages are copied from `security` to `updates` frequently, it is recommended that systems always have the `security` pocket enabled, and use `security.ubuntu.com` for this pocket. For all other pockets feel free to use `archive.ubuntu.com` or an [[https://launchpad.net/ubuntu/+archivemirrors|archive mirror]]. This combination will ensure you are able to download important updates immediately while taking advantage of the mirror network or `archive.ubuntu.com` for all other downloads. Ubuntu systems are configured in this manner by default. === How do I automatically install security updates? === See https://help.ubuntu.com/community/AutomaticSecurityUpdates === There is a security update available that claims it is a "Fake sync from Debian" -- should I be concerned? === No. During the development cycle, source packages that have not been modified by Ubuntu developers are copied from Debian by Launchpad to Ubuntu automatically in a process referred to as "syncing". For some security updates that Debian publishes for its released versions, the Ubuntu Security Team will copy these updates to the corresponding Ubuntu release where the Ubuntu version does not differ from Debian. However, the same launchpad process is not used, as there are additional consistency checks and review the Ubuntu Security Team performs before copying, and the tool that is used to do this is called fake-sync, because it is intended to mimic Launchpad's "syncing" behavior. These "fake-synced" updates should only appear for packages in the '''universe''' and '''multiverse''' pockets. === When I run a virus scanner on my local Ubuntu Archive Mirror, it claims there are malware/trojans/viruses in it. What is going on? === Several packages in the Ubuntu Archive produce false positives since they contain examples of malware that do not pose a risk. Much of this has been discussed in [[https://launchpad.net/bugs/592871|Bug 592871]]. * The Ubuntu Security Team [[https://git.launchpad.net/ubuntu-cve-tracker/tree/README.virus|maintains a list of known false positives]]. |
Line 11: | Line 66: |
* The license to mod_security did not allow for redistribution, so it was removed from Debian and Ubuntu after Dapper (6.06): | * The license to mod_security did not allow for redistribution, so it was removed from Debian and Ubuntu after 6.06 (Dapper): |
Line 14: | Line 69: |
== Things to Flesh Out == * difference between -updates and -security * versioning * builds * links to various security policies |
* The licensing issue has been resolved and mod_security is back in the archive as of Ubuntu 9.04 (Jaunty): * https://bugs.launchpad.net/ubuntu/+source/libapache-mod-security/+bug/247268 == Versions == Ubuntu, like most other Linux distros, 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]]. Sometimes external security vendors doing software version scanning against Ubuntu systems do not check actual package versions, leading to false positives in their scan reports. For an authoritative source of what packages may have outstanding vulnerabilities, the [[https://ubuntu.com/security/cves/|Ubuntu CVE Tracker]] can be consulted. == Architectures == Ubuntu is built for many architectures. Ubuntu officially supports i386^5^, amd64, armhf, arm64, ppc64el, s390x, and riscv64. Packages for i386 and amd64 are hosted on {{{http://archive.ubuntu.com/ubuntu/dists/<release>/}}} and packages for all other architectures are hosted on {{{http://ports.ubuntu.com/dists/<release>/}}}. ||<rowbgcolor="#F1F1DD"> '''Release''' || '''amd64''' || '''arm64''' || '''armhf^1^''' || '''i386^5^''' || '''powerpc''' || '''ppc64el''' || '''s390x''' || '''riscv64''' || '''Details''' || ||14.04 LTS (Trusty)^2^ || yes || ports || yes^3^ || yes || ports || yes^3^ || -- || -- || [[http://iso.qa.ubuntu.com/qatracker/series/42/manifest|Release Manifest]] || ||16.04 LTS (Xenial)^2^ || yes || yes^3^ || yes^3^ || yes || ports || yes^3^ || yes^3^ || -- || [[http://iso.qa.ubuntu.com/qatracker/series/56/manifest|Release Manifest]] || ||18.04 LTS (Bionic)^2^ || yes || yes^3^ || yes^3^ || yes || -- || yes^3^ || yes^3^ || -- || [[http://iso.qa.ubuntu.com/qatracker/series/64/manifest|Release Manifest]] || ||20.04 LTS (Focal) || yes || yes^3^ || yes^3^ || yes^5^ || -- || yes^3^ || yes^3^ || yes || [[http://iso.qa.ubuntu.com/qatracker/series/69/manifest|Release Manifest]] || ||22.04 LTS (Jammy) || yes || yes^3^ || yes^3^ || yes^5^ || -- || yes^3,6^ || yes^3^ || yes || [[http://iso.qa.ubuntu.com/qatracker/series/73/manifest|Release Manifest]] || ||23.04 (Lunar)^7^ || yes || yes^3^ || yes^3^ || yes^5^ || -- || yes^3,6^ || yes^3^ || yes || [[http://iso.qa.ubuntu.com/qatracker/series/78/manifest|Release Manifest]] || ||23.10 (Mantic) || yes || yes^3^ || yes^3^ || yes^5^ || -- || yes^3,6^ || yes^3^ || yes || [[http://iso.qa.ubuntu.com/qatracker/series/78/manifest|Release Manifest]] || 0. armhf is ARMv7 0. Release has reached end of standard security support. [[https://ubuntu.com/esm|Extended support may be purchased for 14.04 LTS, 16.04 LTS and 18.04 LTS]]. 0. While the architecture is listed in ports.ubuntu.com for this release, it should be considered a supported architecture 0. Architecture is supported for 18 months on this LTS release 0. Only a limited set of packages is supported for i386 on Ubuntu 19.10 onwards 0. [[https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668|22.04 and newer drop support for Power8 and require Power9 or newer]] 0. Release has reached end of life. === Endianness === Sometimes a security vulnerability affects a particular architecture or endianness. When an issue affects only a single architecture or endianness, we will try to indicate this in our CVE tracker. Most issues affect all architectures. 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: ||<rowbgcolor="#F1F1DD"> '''Architecture (hardware name)''' || '''Little Endian''' || '''Big Endian''' || ||amd64 (x86_64) || yes || -- || ||armhf || yes || -- || ||arm64 || yes || -- || ||i386 (i686) || yes || -- || ||powerpc (ppc64) || -- || yes || ||ppc64el || yes || -- || ||riscv64 || yes || -- || ||s390x || -- || 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 [[https://bugzilla.mindrot.org/show_bug.cgi?id=764|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 [[http://en.wikipedia.org/wiki/Security_through_obscurity|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 designed 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). * add the above 'sudo -k' to ${HOME}/.bash_logout to automatically expire timestamps when the associated shell exits. However, note that this will only work for shells that are started as login shells; gnome-terminal by default does not start shells this way. Either edit the profile configuration through the gui or run the following command to configure gnome-terminal to start shells as login shells: {{{ for dir in $(gconftool-2 --all-dirs /apps/gnome-terminal/profiles) ; do if [ "$(gconftool-2 -g ${dir}/login_shell 2> /dev/null)" = "false" ] ; then gconftool-2 -s -t bool ${dir}/login_shell true fi done }}} Different shells and terminals may have different behaviors, see their manpages for more 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 * protecting specific applications with [[https://help.ubuntu.com/community/AppArmor|Apparmor]] or [[SELinux|SELinux]] === 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. (This still won't protect against bootable media or removing the hard drive. To protect against these, select Full Disk Encryption when installing Ubuntu.) === 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 [[https://wiki.ubuntu.com/Security/Features#ports|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 [[https://wiki.ubuntu.com/UbuntuFirewallSpec|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 Display Manager (gdm) === * How do I disable the face browser at the login screen? * `gdm` 2.28, as included in Ubuntu 9.10 and later, has been rewritten and does not have the `gdmsetup` graphical configuration tool the previous versions had. `gdm` now stores its settings using GConf. To disable the face browser, use the following command: `sudo -u gdm gconftool-2 --set --type boolean /apps/gdm/simple-greeter/disable_user_list true` * Here are some links with more information: * [[https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/445123|Ubuntu bug]] ("No GUI option to disable face browser") * [[https://bugzilla.gnome.org/show_bug.cgi?id=597673|Upstream bug]] ("There's no simple way to disable the face browser") * [[https://bugzilla.gnome.org/show_bug.cgi?id=587750|Upstream bug to re-implement `gdmsetup`]] ("GDM rewrite needs a configuration GUI panel similar to 2.20 (gdmsetup)") === gnome-keyring === '''Q:''' Does using ```gnome-keyring``` weaken security? '''A:''' For most users in typical environments, no. Proper [[https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy|use of gnome-keyring should increase security]] by encouraging users to store passwords securely in the keyring rather than resorting to other less secure means of storing their passwords (eg, sticky notes on the monitor or a plain text file somewhere on disk). Basically, [[https://wiki.gnome.org/Projects/GnomeKeyring|gnome-keyring]] can store passwords for you (by integrating with [[https://specifications.freedesktop.org/secret-service/latest/|SecretService]] on modern releases of Ubuntu). The passwords are stored in encrypted 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``` and ```man mlock```). Gnome/Ubuntu integration does a few things (see the [[https://wiki.gnome.org/Projects/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) * 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^2,3^: * 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. * Do not use shared login accounts Notice that ''these recommendations are no different from when you are not using a keyring'' (ie, you always want a strong login passphrase, to lock your screen, and never share your login account). [1] While the [[https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy|upstream documentation]] implied keyrings may be locked at various times when the computer is locked (as of 2020/02/26, "Hunkering down and discarding all secrets when your computer is locked"), keyrings are not locked/unlocked on screenlock/screenunlock since programs in the user's session may require access to the keyring during screenlock (eg, an email client). It is possible to [[https://wiki.gnome.org/Projects/GnomeKeyring/SecurityFAQ|configure gnome-keyring]] to lock/unlock the keyring when going into/coming out of suspend and/or hibernate. [2] 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. [3] [[https://wiki.gnome.org/Projects/GnomeKeyring/SecurityFAQ|gnome-keyring FAQ]] === Firefox AppArmor profile === * Why is the profile disabled by default? * Starting with Ubuntu 9.10, firefox ships an AppArmor profile. It is known to work well in the default Ubuntu installation with extensions, plugins and helper applications provided in the Ubuntu archive. Firefox, like all browsers, is a very complex piece of software that can do much more than simply surf web pages. As such, enabling the profile in the default install could affect the overall usability of Firefox in Ubuntu, which could end up ''decreasing'' the security of the overall system. Users who know nothing about App``Armor who encounter App``Armor denials might turn off App``Armor entirely, losing the protections afforded by the [[https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles|existing profiles]]. Enabling the profile for all users must be very carefully considered. * Could the user be prompted on upgrade to enable the profile? * Asking the user on upgrade or installation is not a valid option for Ubuntu, because the question could be confusing and boils down to "''do you want better security?''" People will almost always answer "yes", which is essentially the same as enabling the profile by default. Adding a low priority debconf question which can be preseeded might be implemented in a future release. * Will the profile be enabled by default in a future release of Ubuntu? * Possibly. As mentioned, Firefox is a very complex application on its own, and when you consider third-party plugins, extensions, helper applications and Ubuntu derivatives, it becomes very difficult to ensure that the profile provides the proper level of usability and confinement. It is known to work well in the default Ubuntu installation with extensions, plugins and helper applications provided in the Ubuntu archive. If the profile can be shown to work for the vast majority of users in Ubuntu and its derivatives, and App``Armor user-space tools mature to the point that they are usable by regular users, enabling the profile by default can be considered. * What does the profile protect against? * The goals of the profile are to provide a good usability experience with strong additional protection. The profile allows for the use of plugins and extensions, various helper applications, and access to files in the user's HOME directory, removable media and network filesystems. The profile prevents execution of arbitrary code, malware, reading and writing to sensitive files such as ssh and gpg keys, and writing to files in the user's default PATH. It also prevents reading of system and kernel files. All of this provides a level of protection far exceeding that of normal UNIX permissions. * In Ubuntu 10.10 the default shipped profile is the same as above, but its use of includes allows for much greater flexibility for tightly confining firefox. /etc/apparmor.d/usr.bin.firefox is a very restricted profile, but includes both /etc/apparmor.d/local/usr.bin.firefox and /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox. /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox contains other include files for tasks such as multimedia, productivity, etc and the file can be manipulated via the ```aa-update-browser``` command. /etc/apparmor.d/local/usr.bin.firefox is used for site-specific adjustments (see /etc/apparmor.d/local/README for details and caveats). A future release of Ubuntu may allow debconf configuration for /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox to allow preseeding. * How do I enable or disable the profile? * The profile can be enabled by using {{{sudo aa-enforce /etc/apparmor.d/usr.bin.firefox}}} (use ```/etc/apparmor.d/firefox-3.5``` in Ubuntu 9.10). The profile can be temporarily disabled by performing {{{sudo apparmor_parser -R /etc/apparmor.d/usr.bin.firefox}}} and permanently disabled with {{{sudo apparmor_parser -R /etc/apparmor.d/usr.bin.firefox ; sudo ln -s /etc/apparmor.d/usr.bin.firefox /etc/apparmor.d/disable/usr.bin.firefox}}}. See the [[https://help.ubuntu.com/community/AppArmor|Ubuntu AppArmor documentation]] for more details on using App``Armor. * The profile doesn't work for me, what should I do? * See DebuggingApparmor for how to diagnose, report and fix bugs in App``Armor profiles. You may also disable the profile (see above). * Can I adjust the profile? * Certainly! You can add additional access rules or remove rules in the profile for your requirements. For ```firefox```, simply adjust the profile ```/etc/apparmor.d/usr.bin.firefox``` and reload it with ```sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.bin.firefox```. See the [[https://help.ubuntu.com/community/AppArmor|Ubuntu AppArmor documentation]] for more details on using App``Armor. If you feel your additions would benefit all Ubuntu users, please consult DebuggingApparmor and file a bug. Keep in mind /etc/apparmor.d/usr.bin.firefox is a Debian conffile, which means on certain package upgrades, you will be prompted for what to do with the changes. In Ubuntu 10.10 you can fine-tune the profile using the aforementioned ubuntu-browsers.d abstraction mechanism and also adjust /etc/apparmor.d/local/usr.bin.firefox and avoid being prompted on upgrade. === Update Manager doesn't prompt for security updates === * Why does `update-manager` no longer prompt for the user's password? * As of Ubuntu 11.10, `update-manager` no longer prompts for the user's password to apply updates. This was decided to improve usability and to make it easier for users to apply security updates and therefore increase system security. The rationale is as follows: * Like in previous releases, by default only people in the `admin` group are allowed access to perform security updates. * Only updates for already installed software can be applied without a password. Installing additional software still requires people to enter their password. * The password prompt had become an irritant for some people such that they would just press 'Cancel' instead of installing the updates. The password prompt decreased system security for those users. * People that did dutifully apply updates became conditioned to enter their privileged password perhaps daily. When the user is prompted for the password, it should mean something and the frequency of `update-manager` updates meant that some people no longer thought about why they were entering their password. For these users, the password prompt had the potential to reduce security. For environments where this change is deemed not appropriate, this functionality can be disabled by the administrator via !PolicyKit or by creating users that are not in the admin group (a recommended practice to begin with). === NetworkManager system connections === * Why does !NetworkManager now store its connection information in /etc? * As of Ubuntu 11.10, !NetworkManager defaults to having connections "Available to all users" which stores connection information in /etc/NetworkManager/system-connections. Files in this directory are set so that only the root user is able to read them. If you prefer your connection information to be stored in your keyring, uncheck "Available to all users" in !NetworkManager for this connection. === SHA512-crypt as default === * Why does Ubuntu use the SHA512-crypt key derivation function by default when storing passwords? * Starting with Ubuntu 8.10, Ubuntu moved from the old (and now untrusted) MD5-crypt key derivation function in glibc crypt() to the [[http://www.akkadia.org/drepper/SHA-crypt.txt|SHA512-crypt glibc crypt() key derivation function]] (hereafter known as SHA512-crypt) with an 8 character salt and default 5000 rounds (adjustable) to increase CPU requirements (aka, key stretching. Note, [[http://tools.ietf.org/html/rfc2898|PBKDF1 and PBKDF2 are NIST approved methods to apply key-stretching by using key derivation functions]]). A requirement for glibc was to use a standards-based algorithm and since the SHA512 hash algorithm is recommended by NIST, it is suitable for use in applications with US-based requirements and thus added to glibc. Other algorithms exist however. Bcrypt is based on the blowfish cipher and was designed to be computationally expensive (being computationally expensive is desirable in a password hashing algorithm because it helps slow down brute-force attacks since an attacker can make fewer guesses per second). Like SHA512-crypt, bcrypt is adaptable by having an adjustable cost (similar to the adjustable rounds in SHA512-crypt). Bcrypt is often cited as a better choice than SHA512-crypt (indeed OpenSUSE uses bcrypt by default) because it is slower to compute on CPUs and GPUs. It is not meaningfully slower in certain other situations however, which has led to the creation of [[http://www.tarsnap.com/scrypt/scrypt.pdf|scrypt]]. Neither bcrypt nor scrypt have received review by NIST, and are therefore not on their recommended list. Which is best? This is subjective-- scrypt is more computationally expensive than bcrypt, but is too new to recommend. bcrypt is more computationally expensive than SHA512-crypt, but is not on the NIST recommended list. SHA512-crypt with its 5000 rounds of key-stretching and widespread review of its hashing algorithm is standards-approved, is considered good enough for the foreseeable future and is considered a safe default. Ubuntu will continue to monitor other algorithms such as scrypt or a new SHA-3-based key derivation function and move away from SHA512-crypt when a more appropriate alternative is available (note: there is [[http://csrc.nist.gov/groups/ST/hash/policy.html|currently no reason to migrate away from SHA-2 to SHA-3]]). === curl === * curl in Ubuntu 14.04 LTS and newer drops support for weak ciphers, including rc4, 64 bit ciphers, 56 bit export ciphers, and 40 bit export ciphers. If the server cannot be upgraded to support modern cipher suites, the ```--ciphers``` command line option can be used to connect using weak ciphers: ```curl --ciphers RC4-SHA:RC4-MD5 https://foo.example.com/``` === OpenSSL === * All supported versions of Ubuntu have been patched to prevent the "heartbleed" bug (CVE-2014-0160). Ubuntu 14.04 LTS did not receive a wholesale OpenSSL version update because 1.0.1g was provided very late in the Ubuntu 14.04 LTS development and testing schedule; backporting only the security fix to our 1.0.1f-1ubuntu2 packages allowed us to avoid a regression that was introduced in upstream OpenSSL 1.0.1g. === webkit === Due to various upstreams' release models, support for webkit is limited to new upstream minor version releases only. === WebKitGTK === While attempts will be made to update to new upstream major versions when possible, new dependency requirements may prevent doing so. Currently, newer versions require a more recent version of GCC than is available in Ubuntu 16.04 LTS, and more recent versions of ICU and CMake in Ubuntu 18.04 LTS. === mozjs === The GNOME desktop requires the SpiderMonkey javascript engine from Mozilla, which is packaged as mozjs38, mozjs52, mozjs68, mozjs78, mozjs91, etc, and interfaces with it via gjs. Mozilla does not provide separate security maintenance for the SpiderMonkey project and instead irregularly releases new versions which break backwards compatibility of JavaScript language features (used by gnome-shell, extensions, applications) and the C++ API (used by gjs). Fixes for vulnerabilities are not always marked and the project progresses at a rapid pace making it prohibitive to backport security fixes. Because of this, security support for mozjs is provided by providing new versions of mozjs as they become available. === grub, grub2, grub2-unsigned, grub2-signed === Sometimes people ask why we have chosen to `ignore` CVEs on the `grub2` package. The grub packaging is very complicated. The `grub2` source package is mostly used with BIOS / CSM mode booting, which has no security boundaries. Without any security boundaries, there's no point to calling any given bugs in the code as "security bugs". Any bugs that allow bypassing secure boot are eligible for security fixes, and those will happen in the `grub2-signed` and `grub2-unsigned` packages. (The split is an artifact of the build process; it is not necessary for users to understand why there are two source packages. In short, the unsigned variant is built first and then the signed variant packages those binaries after they are signed outside the build environment.) == Hardening Guide == The default installation of Ubuntu should make reasonable security / usability tradeoffs for most users. It is our goal that you can use Ubuntu without worrying about security and also not be artificially restricted in what you can do with your computer. However, these tradeoffs may not be ideal for all users. Some people may wish to subscribe to Ubuntu Pro in order to deploy industry-standard security benchmarks like [[https://ubuntu.com/security/certifications|FIPS or CIS benchmarks or DISA STIGs]]. We've collected some suggestions for proactive hardening steps that system administrators can apply without committing fully to the more comprehensive security policies. We suggest considering: * [[https://help.ubuntu.com/community/SSH/OpenSSH/Configuring#Disable_Password_Authentication | Disable SSH password authentication]]. Weak passwords are a leading cause of security breaches. It is far safer to use SSH keys or certificates for authentication to SSH servers. * Raise the `vm.mmap_rnd_compat_bits` and `mmap_rnd_bits` settings. Ubuntu uses Address Space Layout Randomization to change some deterministic attacks into probabilistic attacks by randomizing the addresses uses for executables and libraries. Different architectures will have different allowed ranges and the defaults must be chosen in mind of the total amount of memory required by the process with the most stringent combination of alignment requirements and size requirements. Your workload may allow you to raise these values and increase the value of the probabilistic defense. Your workload may require larger contiguous chunks of memory than is available with defaults and require you to lower these values. * Set BIOS "user" and "administrator" passwords, if available, to prevent disabling Secure Boot. Be careful -- recovering from lost BIOS passwords may be painful or impossible. * Enable Full Disk Encryption during installation. Be careful -- recovering from a lost disk unlock password may be painful or impossible. You will need to enter a password during the Ubuntu startup process, so it is most applicable to laptops used for travel. * Configure the screen-locker to lock the screen after a period of inactivity. While it is better to explicitly lock your desktop when walking away, the screen lock on idle time can help if you forget. * Install and configure `bolt` to limit the functionality of Thunderbolt devices on your computer, which expose raw PCIe through a convenient port. Be careful -- this can prevent you from using your computer if not configured correctly. * Install and configure `usbauth` or `usbguard` to limit the functionality of USB devices on your computer. Be careful -- this can prevent you from using your computer if not configured correctly. * Install and configure a firewall. [[https://wiki.ubuntu.com/UncomplicatedFirewall|UFW]] is an easy front-end to help you get started if you don't already have a favorite. * Set sysctl `dev.tty.legacy_tiocsti` if your kernel has it available to prevent the use of the `TIOCSTI` ioctl. This is probably safe -- there are very few legitimate uses of this ioctl in the world. * List unused network protocols, drivers, line disciplines, via `/etc/modprobe.d` settings to prevent automatic kernel module loading these features. == Vulnerabilities == * What does CVE stand for? * [[http://cve.mitre.org/about/terminology.html|Common Vulnerabilities and Exposures]]. From their FAQ: CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration." == Unofficial Software == * Should I manually install software from third-party web sites? * Software contained in the Ubuntu archive has been specifically packaged to work well and integrate properly with the system. Software installation tools that come bundled with Ubuntu, such as the Ubuntu Software Centre and Update Manager, validate packages when they are installed to make sure they are secure and have not been manipulated or trojaned during their download. Also, a large subset of packages in the archive are officially supported by the Ubuntu Security Team and get timely updates for security issues that may arise. Installing a package from an untrusted source is not recommended for the following reasons: * Packages from unknown sources may be knowingly trojaned or contain malware. * Packages that are installed without signature verification can be manipulated during download to add trojans or malware. * Manually installed packages may prevent your Ubuntu installation from properly updating itself, or from updating to a newer release. * Manually installed packages may not be specifically adapted for Ubuntu, and may break integration and interaction with other packages. * Manually installed packages do not get automatic security updates, potentially resulting in system compromise when a vulnerability is discovered. * Is installing software from a PPA secure? * Packages installed from a properly configured PPA benefits from signature verification, so they cannot be manipulated by a malicious third-party while they are being downloaded. * There are no security verifications done on packages in PPAs. When you install a package from a PPA, you are implicitly trusting the owner of the PPA. There are no mechanisms in place to prevent the owner of a PPA from publishing malicious, trojaned, or simply broken packages. * Installing packages from a PPA may prevent your Ubuntu installation from properly updating itself, or from updating to a newer release. * Packages from a PPA may not get security updates, potentially resulting in system compromise when a vulnerability is discovered. * I have discovered a cool replacement for Ubuntu Software Centre/Update Manager that is not in the archives. Is it safe to use? * The same warnings that apply to manually installed software also apply. * Some package installation tools have been known to use options that may break your system, such as the use of "--force" during package installation. * Package installation is a delicate process and some package installation tools do not resolve dependencies in the same manner as the recommended ones. This may cause issues with installed software and with system integrity. == Design == * What are Ubuntu's security policies? * Many common issues come up that may seem to be security design problems, but are actually done intentionally. Please review the [[SecurityTeam/Policies|Ubuntu Security Policies]]. * How do I write secure software? * There is no single answer, but some good resources are: * David Wheeler's [[http://www.dwheeler.com/secure-programs/|Secure Programming for Linux and Unix HOWTO -- Creating Secure Software]] (fantastic to start with) * Mozilla's [[https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines|secure web coding guidelines]] * OWASP's [[https://www.owasp.org/index.php/Category:How_To|Application Security How-To Articles]] * [[http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426|The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities]] * [[http://www.trapkit.de/books/bhd/en.html|A Bug Hunter's Diary: A Guided Tour Through the Wilds of Software Security]] * CERT's [[https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard|C Coding Standard]] == GPG Keys used by Ubuntu == * What GPG keys are used to verify Ubuntu distributions? * The Ubuntu Archives are signed with keys:{{{ pub rsa4096/871920D1991BC93C 2018-09-17 [SC] F6ECB3762474EDA9D21B7022871920D1991BC93C uid [ unknown] Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com> pub 4096R/3B4FE6ACC0B21F32 2012-05-11 Key fingerprint = 790B C727 7767 219C 42C8 6F93 3B4F E6AC C0B2 1F32 uid Ubuntu Archive Automatic Signing Key (2012) <ftpmaster@ubuntu.com>}}} * The Ubuntu ISO Images are signed with keys:{{{ pub 1024D/FBB75451 2004-12-30 Key fingerprint = C598 6B4F 1257 FFA8 6632 CBA7 4618 1433 FBB7 5451 uid Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com> pub 4096R/EFE21092 2012-05-11 Key fingerprint = 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092 uid Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>}}} * The Ubuntu Cloud Images checksums are signed with key:{{{ pub 4096R/7DB87C81 2009-09-15 Key fingerprint = D2EB 4462 6FDD C30B 513D 5BB7 1A5D 6C4C 7DB8 7C81 uid UEC Image Automatic Signing Key <cdimage@ubuntu.com>}}} * The Ubuntu Cloud Images simplestreams are signed with key:{{{ pub rsa4096 2012-10-27 [SC] 4A3C E3CD 565D 7EB5 C810 E2B9 7FF3 F408 476C F100 uid Ubuntu Cloud Image Builder (Canonical Internal Cloud Image Builder) <ubuntu-cloudbuilder-noreply@canonical.com> sub rsa4096 2012-10-27 [E]}}} * The ddebs debug package repositories are signed with key:{{{ pub 4096R/5FDFF622 2016-03-21 [expires: 2021-03-20] Key fingerprint = F2ED C64D C5AE E1F6 B9C6 21F0 C8CA B659 5FDF F622 uid Ubuntu Debug Symbol Archive Automatic Signing Key (2016) <ubuntu-archive@lists.ubuntu.com> pub 1024D/428D7C01 2008-09-02 Key fingerprint = 2512 191F EF87 29D6 E5AF 414D ECDC AD72 428D 7C01 uid Ubuntu Debug Symbol Archive Automatic Signing Key <ubuntu-archive@lists.ubuntu.com> sub 2048g/A2C2A7A5 2008-09-02}}} * The Kernel PPA packages are signed with key:{{{ pub 2048R/17C622B0 2008-05-01 Key fingerprint = 60AA 7B6F 3043 4AE6 8E56 9963 E50C 6A09 17C6 22B0 uid Kernel PPA <kernel-ppa@canonical.com>}}} * The Ubuntu Archive Master key, used for Signing key rotations is:{{{ pub rsa4096/0x0BFB847F3F272F5B 2007-11-09 [SC] Key fingerprint = 153F 1C9E F139 5FBF 0035 2E8D 0BFB 847F 3F27 2F5B uid Ubuntu Archive Master Signing Key <ftpmaster@ubuntu.com>}}} * The Ubuntu Extended Security Maintenance archive is signed with:{{{ pub rsa4096/67C7A026 2017-04-21 [SC] Key fingerprint = 74AE 092F 7629 ACDF 4FB1 7310 B4C2 AF7A 67C7 A026 uid Ubuntu Extended Security Maintenance Automatic Signing Key <esm@canonical.com> uid Ubuntu ESM <prodstack-cdo@canonical.com> sub rsa4096/80EE65B3 2017-04-21 [E]}}} * The Ubuntu FIPS archive is signed with:{{{ pub rsa4096/8D13028C 2017-01-09 [SC] Key fingerprint = A166 8774 12DA C26E 73CE BF3F F6C2 8017 8D13 028C uid Launchpad PPA for ubuntu-advantage}}} * The Canonical OEM Vendor Archives are signed with key:{{{ pub rsa2048 2008-08-07 [SC] 236252602787D6BDC2336849F9FDA6BED73CDC22 uid [ unknown] Canonical Archive Automatic Signing Key <ftpmaster@canonical.com>}}} == Contact == * How can I contact the Ubuntu Security team about issues that are already publicly disclosed? * Public discussions can take place in the following locations: * the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened| Ubuntu Hardened email list]] ([[ https://lists.ubuntu.com/archives/ubuntu-hardened/ | list archives ]]), * {{{ #ubuntu-security }}} on {{{ irc.libera.chat }}} ([[ https://irclogs.ubuntu.com/latest/%23ubuntu-security.txt | publicly logged]]), * the [[https://discourse.ubuntu.com/c/security/33| Ubuntu Security section of the Ubuntu Discourse]], * by reaching out directly to security@ubuntu.com . * How should private security issues be reported? * The preferred method of reporting a security issue is through [[https://bugs.launchpad.net/ubuntu/+filebug|Launchpad]]. Launchpad offers a "Private Security" mode that will only be visible to members of the security team and select administrators. Note that Launchpad will send an unencrypted mail with the contents of the bug report to the reporter. If this is not desired, a direct email can be sent. * All security team members can be reached at security@ubuntu.com. GPG can be used to encrypt these messages. Please use the following key: || Name || Key ID || Key Fingerprint || || security@ubuntu.com || [[https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&op=index&search=0x407260F7616ECE4D9D12462798E9740DC34539E0|98E9740DC34539E0]] || `4072 60F7 616E CE4D 9D12 4627 98E9 740D C345 39E0` || * Please also see our [[ https://ubuntu.com/security/disclosure-policy | disclosure and embargo policy ]] * Additionally, the GPG key ids for the security team members can be found on their individual Launchpad pages which are linked to on [[https://launchpad.net/~ubuntu-security/+members#active|the security team's page]]. We will keep this list of keys updated as needed: <<Include(SecurityTeam/GPGKeyTable)>> |
Standard Support
- What does standard security support mean?
Canonical employees working on the Ubuntu Security Team 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.
- Previously referred to as "Official Support"
- What software is supported by the Ubuntu Security team?
Ubuntu is currently divided into four components: main, restricted, universe and multiverse. All binary packages in main and restricted are supported by the Ubuntu Security team for the life of an Ubuntu release, while binary packages in universe and multiverse are supported by the Ubuntu community.
- Who can receive standard support?
Standard Support is provided free of charge to all users of Ubuntu during the life of an Ubuntu release.
How do seeds impact standard support?
Seeds determine in which component a package resides. All binary packages in the main and restricted components receive support for the life of an Ubuntu release.
The Supported field in the Packages file for the main and restricted components may be inaccurate, especially in the case of non-LTS releases. Today, all releases have unified support lengths.
- What is extended support?
Ubuntu Pro customers may receive additional security support beyond what is freely available via standard support.
ESM customers (ESM is included in Ubuntu Pro) can receive security updates for high and critical CVEs (common vulnerabilities and exposures) for the the entire collection of software packages shipped with Ubuntu, including the Ubuntu Universe repository, for 10 years.
A FAQ specifically about the security patches included in Ubuntu Pro is available here.
- How will support for Ubuntu Touch be provided?
- As of 2017/06/15, Ubuntu Touch no longer receives security support.
- How will support for Ubuntu Core be provided?
Ubuntu Core 15 security updates will be provided via its PPA overlay only. Ubuntu Core 16 inherits security updates from Ubuntu 16.04. Ubuntu Core 16 snaps are automatically refreshed via the snap automated update mechanism.
Repositories and Updates
How are the "-updates" and "-security" pockets different?
TLDR;
-updates includes things that have gone through the StableReleaseUpdates process, and contain various important bug fixes. Anything built for "-updates" is built on top of which ever version of a package is newest between "-updates" and "-security", so that nothing in "-updates" will introduce security regressions.
-security includes only updated packages that contain security-related fixes, and are built to not require anything from "-updates". Anything built for "-security" is built on top of which ever version of a package is newest between "-updates" and "-security", so that nothing in "-security" will introduce bug regressions.
When the security team prepares updates for the "-security" pocket they take whichever is the highest version from either the "-updates" OR the "-security" pocket and then patch that and release it to the "-security" pocket. As such, "-security" can end up containing some changes from "-updates". This is due to the nature of package versioning and to ensure that for all users (regardless of whether they have only "-security" or both "-security" + "-updates" enabled) that they can always upgrade to the security updated version (ie. the version number has to be strictly greater than anything prior to that from both "-updates" and "-security").
When doing security updates, any required dependencies that are not already in the "-security" pocket are also copied over from the "-updates" pocket as needed.
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 16.04 LTS, the Xenial Xerus, is simply xenial, while the security pocket for Ubuntu 16.04 LTS is xenial-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, updates and proposed
updates: as a matter of Ubuntu policy, packages in updates are not directly built, but rather copied from proposed after they have been tested. See StableReleaseUpdates for details. If a special circumstance warrants building a package in updates without going through proposed first, it would be built with release, security and updates (also, the default configuration for unofficial PPAs is to build with this configuration).
backports: built with release, security, updates and backports. See UbuntuBackports for details.
What repositories and pockets should I use to make sure my systems are up to date?
By default, Ubuntu systems have both the security and updates pockets enabled. Systems configured to use only the security pocket are also supported. (This requires installing from the original release media, as the point release media contains packages from the updates pocket and will result in difficulties running with only the security pocket enabled.)
While packages are copied from security to updates frequently, it is recommended that systems always have the security pocket enabled, and use security.ubuntu.com for this pocket. For all other pockets feel free to use archive.ubuntu.com or an archive mirror. This combination will ensure you are able to download important updates immediately while taking advantage of the mirror network or archive.ubuntu.com for all other downloads. Ubuntu systems are configured in this manner by default.
How do I automatically install security updates?
See https://help.ubuntu.com/community/AutomaticSecurityUpdates
There is a security update available that claims it is a "Fake sync from Debian" -- should I be concerned?
No. During the development cycle, source packages that have not been modified by Ubuntu developers are copied from Debian by Launchpad to Ubuntu automatically in a process referred to as "syncing". For some security updates that Debian publishes for its released versions, the Ubuntu Security Team will copy these updates to the corresponding Ubuntu release where the Ubuntu version does not differ from Debian. However, the same launchpad process is not used, as there are additional consistency checks and review the Ubuntu Security Team performs before copying, and the tool that is used to do this is called fake-sync, because it is intended to mimic Launchpad's "syncing" behavior. These "fake-synced" updates should only appear for packages in the universe and multiverse pockets.
When I run a virus scanner on my local Ubuntu Archive Mirror, it claims there are malware/trojans/viruses in it. What is going on?
Several packages in the Ubuntu Archive produce false positives since they contain examples of malware that do not pose a risk. Much of this has been discussed in Bug 592871.
The Ubuntu Security Team maintains a list of known false positives.
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, like most other Linux distros, 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.
Sometimes external security vendors doing software version scanning against Ubuntu systems do not check actual package versions, leading to false positives in their scan reports. For an authoritative source of what packages may have outstanding vulnerabilities, the Ubuntu CVE Tracker can be consulted.
Architectures
Ubuntu is built for many architectures. Ubuntu officially supports i3865, amd64, armhf, arm64, ppc64el, s390x, and riscv64. Packages for i386 and amd64 are hosted on http://archive.ubuntu.com/ubuntu/dists/<release>/ and packages for all other architectures are hosted on http://ports.ubuntu.com/dists/<release>/.
Release |
amd64 |
arm64 |
armhf1 |
i3865 |
powerpc |
ppc64el |
s390x |
riscv64 |
Details |
14.04 LTS (Trusty)2 |
yes |
ports |
yes3 |
yes |
ports |
yes3 |
-- |
-- |
|
16.04 LTS (Xenial)2 |
yes |
yes3 |
yes3 |
yes |
ports |
yes3 |
yes3 |
-- |
|
18.04 LTS (Bionic)2 |
yes |
yes3 |
yes3 |
yes |
-- |
yes3 |
yes3 |
-- |
|
20.04 LTS (Focal) |
yes |
yes3 |
yes3 |
yes5 |
-- |
yes3 |
yes3 |
yes |
|
22.04 LTS (Jammy) |
yes |
yes3 |
yes3 |
yes5 |
-- |
yes3,6 |
yes3 |
yes |
|
23.04 (Lunar)7 |
yes |
yes3 |
yes3 |
yes5 |
-- |
yes3,6 |
yes3 |
yes |
|
23.10 (Mantic) |
yes |
yes3 |
yes3 |
yes5 |
-- |
yes3,6 |
yes3 |
yes |
- armhf is ARMv7
Release has reached end of standard security support. Extended support may be purchased for 14.04 LTS, 16.04 LTS and 18.04 LTS.
- While the architecture is listed in ports.ubuntu.com for this release, it should be considered a supported architecture
- Architecture is supported for 18 months on this LTS release
- Only a limited set of packages is supported for i386 on Ubuntu 19.10 onwards
22.04 and newer drop support for Power8 and require Power9 or newer
- Release has reached end of life.
Endianness
Sometimes a security vulnerability affects a particular architecture or endianness. When an issue affects only a single architecture or endianness, we will try to indicate this in our CVE tracker. Most issues affect all architectures. 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 |
-- |
armhf |
yes |
-- |
arm64 |
yes |
-- |
i386 (i686) |
yes |
-- |
powerpc (ppc64) |
-- |
yes |
ppc64el |
yes |
-- |
riscv64 |
yes |
-- |
s390x |
-- |
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 designed 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).
add the above 'sudo -k' to ${HOME}/.bash_logout to automatically expire timestamps when the associated shell exits. However, note that this will only work for shells that are started as login shells; gnome-terminal by default does not start shells this way. Either edit the profile configuration through the gui or run the following command to configure gnome-terminal to start shells as login shells:
for dir in $(gconftool-2 --all-dirs /apps/gnome-terminal/profiles) ; do if [ "$(gconftool-2 -g ${dir}/login_shell 2> /dev/null)" = "false" ] ; then gconftool-2 -s -t bool ${dir}/login_shell true fi done
Different shells and terminals may have different behaviors, see their manpages for more 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. (This still won't protect against bootable media or removing the hard drive. To protect against these, select Full Disk Encryption when installing Ubuntu.)
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 Display Manager (gdm)
- How do I disable the face browser at the login screen?
gdm 2.28, as included in Ubuntu 9.10 and later, has been rewritten and does not have the gdmsetup graphical configuration tool the previous versions had. gdm now stores its settings using GConf. To disable the face browser, use the following command: sudo -u gdm gconftool-2 --set --type boolean /apps/gdm/simple-greeter/disable_user_list true
- Here are some links with more information:
Ubuntu bug ("No GUI option to disable face browser")
Upstream bug ("There's no simple way to disable the face browser")
Upstream bug to re-implement `gdmsetup` ("GDM rewrite needs a configuration GUI panel similar to 2.20 (gdmsetup)")
gnome-keyring
Q: Does using gnome-keyring weaken security?
A: For most users in typical environments, no. Proper use of gnome-keyring should increase security by encouraging users to store passwords securely in the keyring rather than resorting to other less secure means of storing their passwords (eg, sticky notes on the monitor or a plain text file somewhere on disk).
Basically, gnome-keyring can store passwords for you (by integrating with SecretService on modern releases of Ubuntu). The passwords are stored in encrypted 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 and man mlock).
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)
- 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 safely2,3:
- 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.
- Do not use shared login accounts
Notice that these recommendations are no different from when you are not using a keyring (ie, you always want a strong login passphrase, to lock your screen, and never share your login account).
[1] While the upstream documentation implied keyrings may be locked at various times when the computer is locked (as of 2020/02/26, "Hunkering down and discarding all secrets when your computer is locked"), keyrings are not locked/unlocked on screenlock/screenunlock since programs in the user's session may require access to the keyring during screenlock (eg, an email client). It is possible to configure gnome-keyring to lock/unlock the keyring when going into/coming out of suspend and/or hibernate.
[2] 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.
Firefox AppArmor profile
- Why is the profile disabled by default?
Starting with Ubuntu 9.10, firefox ships an AppArmor profile. It is known to work well in the default Ubuntu installation with extensions, plugins and helper applications provided in the Ubuntu archive. Firefox, like all browsers, is a very complex piece of software that can do much more than simply surf web pages. As such, enabling the profile in the default install could affect the overall usability of Firefox in Ubuntu, which could end up decreasing the security of the overall system. Users who know nothing about AppArmor who encounter AppArmor denials might turn off AppArmor entirely, losing the protections afforded by the existing profiles. Enabling the profile for all users must be very carefully considered.
- Could the user be prompted on upgrade to enable the profile?
Asking the user on upgrade or installation is not a valid option for Ubuntu, because the question could be confusing and boils down to "do you want better security?" People will almost always answer "yes", which is essentially the same as enabling the profile by default. Adding a low priority debconf question which can be preseeded might be implemented in a future release.
- Will the profile be enabled by default in a future release of Ubuntu?
Possibly. As mentioned, Firefox is a very complex application on its own, and when you consider third-party plugins, extensions, helper applications and Ubuntu derivatives, it becomes very difficult to ensure that the profile provides the proper level of usability and confinement. It is known to work well in the default Ubuntu installation with extensions, plugins and helper applications provided in the Ubuntu archive. If the profile can be shown to work for the vast majority of users in Ubuntu and its derivatives, and AppArmor user-space tools mature to the point that they are usable by regular users, enabling the profile by default can be considered.
- What does the profile protect against?
- The goals of the profile are to provide a good usability experience with strong additional protection. The profile allows for the use of plugins and extensions, various helper applications, and access to files in the user's HOME directory, removable media and network filesystems. The profile prevents execution of arbitrary code, malware, reading and writing to sensitive files such as ssh and gpg keys, and writing to files in the user's default PATH. It also prevents reading of system and kernel files. All of this provides a level of protection far exceeding that of normal UNIX permissions.
In Ubuntu 10.10 the default shipped profile is the same as above, but its use of includes allows for much greater flexibility for tightly confining firefox. /etc/apparmor.d/usr.bin.firefox is a very restricted profile, but includes both /etc/apparmor.d/local/usr.bin.firefox and /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox. /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox contains other include files for tasks such as multimedia, productivity, etc and the file can be manipulated via the aa-update-browser command. /etc/apparmor.d/local/usr.bin.firefox is used for site-specific adjustments (see /etc/apparmor.d/local/README for details and caveats). A future release of Ubuntu may allow debconf configuration for /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox to allow preseeding.
- How do I enable or disable the profile?
The profile can be enabled by using sudo aa-enforce /etc/apparmor.d/usr.bin.firefox (use /etc/apparmor.d/firefox-3.5 in Ubuntu 9.10). The profile can be temporarily disabled by performing sudo apparmor_parser -R /etc/apparmor.d/usr.bin.firefox and permanently disabled with sudo apparmor_parser -R /etc/apparmor.d/usr.bin.firefox ; sudo ln -s /etc/apparmor.d/usr.bin.firefox /etc/apparmor.d/disable/usr.bin.firefox. See the Ubuntu AppArmor documentation for more details on using AppArmor.
- The profile doesn't work for me, what should I do?
See DebuggingApparmor for how to diagnose, report and fix bugs in AppArmor profiles. You may also disable the profile (see above).
- Can I adjust the profile?
Certainly! You can add additional access rules or remove rules in the profile for your requirements. For firefox, simply adjust the profile /etc/apparmor.d/usr.bin.firefox and reload it with sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.bin.firefox. See the Ubuntu AppArmor documentation for more details on using AppArmor. If you feel your additions would benefit all Ubuntu users, please consult DebuggingApparmor and file a bug. Keep in mind /etc/apparmor.d/usr.bin.firefox is a Debian conffile, which means on certain package upgrades, you will be prompted for what to do with the changes. In Ubuntu 10.10 you can fine-tune the profile using the aforementioned ubuntu-browsers.d abstraction mechanism and also adjust /etc/apparmor.d/local/usr.bin.firefox and avoid being prompted on upgrade.
Update Manager doesn't prompt for security updates
Why does update-manager no longer prompt for the user's password?
As of Ubuntu 11.10, update-manager no longer prompts for the user's password to apply updates. This was decided to improve usability and to make it easier for users to apply security updates and therefore increase system security. The rationale is as follows:
Like in previous releases, by default only people in the admin group are allowed access to perform security updates.
- Only updates for already installed software can be applied without a password. Installing additional software still requires people to enter their password.
- The password prompt had become an irritant for some people such that they would just press 'Cancel' instead of installing the updates. The password prompt decreased system security for those users.
People that did dutifully apply updates became conditioned to enter their privileged password perhaps daily. When the user is prompted for the password, it should mean something and the frequency of update-manager updates meant that some people no longer thought about why they were entering their password. For these users, the password prompt had the potential to reduce security.
For environments where this change is deemed not appropriate, this functionality can be disabled by the administrator via PolicyKit or by creating users that are not in the admin group (a recommended practice to begin with).
NetworkManager system connections
Why does NetworkManager now store its connection information in /etc?
As of Ubuntu 11.10, NetworkManager defaults to having connections "Available to all users" which stores connection information in /etc/NetworkManager/system-connections. Files in this directory are set so that only the root user is able to read them. If you prefer your connection information to be stored in your keyring, uncheck "Available to all users" in NetworkManager for this connection.
SHA512-crypt as default
- Why does Ubuntu use the SHA512-crypt key derivation function by default when storing passwords?
Starting with Ubuntu 8.10, Ubuntu moved from the old (and now untrusted) MD5-crypt key derivation function in glibc crypt() to the SHA512-crypt glibc crypt() key derivation function (hereafter known as SHA512-crypt) with an 8 character salt and default 5000 rounds (adjustable) to increase CPU requirements (aka, key stretching. Note, PBKDF1 and PBKDF2 are NIST approved methods to apply key-stretching by using key derivation functions). A requirement for glibc was to use a standards-based algorithm and since the SHA512 hash algorithm is recommended by NIST, it is suitable for use in applications with US-based requirements and thus added to glibc.
Other algorithms exist however. Bcrypt is based on the blowfish cipher and was designed to be computationally expensive (being computationally expensive is desirable in a password hashing algorithm because it helps slow down brute-force attacks since an attacker can make fewer guesses per second). Like SHA512-crypt, bcrypt is adaptable by having an adjustable cost (similar to the adjustable rounds in SHA512-crypt). Bcrypt is often cited as a better choice than SHA512-crypt (indeed OpenSUSE uses bcrypt by default) because it is slower to compute on CPUs and GPUs. It is not meaningfully slower in certain other situations however, which has led to the creation of scrypt. Neither bcrypt nor scrypt have received review by NIST, and are therefore not on their recommended list.
Which is best? This is subjective-- scrypt is more computationally expensive than bcrypt, but is too new to recommend. bcrypt is more computationally expensive than SHA512-crypt, but is not on the NIST recommended list. SHA512-crypt with its 5000 rounds of key-stretching and widespread review of its hashing algorithm is standards-approved, is considered good enough for the foreseeable future and is considered a safe default. Ubuntu will continue to monitor other algorithms such as scrypt or a new SHA-3-based key derivation function and move away from SHA512-crypt when a more appropriate alternative is available (note: there is currently no reason to migrate away from SHA-2 to SHA-3).
curl
curl in Ubuntu 14.04 LTS and newer drops support for weak ciphers, including rc4, 64 bit ciphers, 56 bit export ciphers, and 40 bit export ciphers. If the server cannot be upgraded to support modern cipher suites, the --ciphers command line option can be used to connect using weak ciphers: curl --ciphers RC4-SHA:RC4-MD5 https://foo.example.com/
OpenSSL
- All supported versions of Ubuntu have been patched to prevent the "heartbleed" bug (CVE-2014-0160). Ubuntu 14.04 LTS did not receive a wholesale OpenSSL version update because 1.0.1g was provided very late in the Ubuntu 14.04 LTS development and testing schedule; backporting only the security fix to our 1.0.1f-1ubuntu2 packages allowed us to avoid a regression that was introduced in upstream OpenSSL 1.0.1g.
webkit
Due to various upstreams' release models, support for webkit is limited to new upstream minor version releases only.
WebKitGTK
While attempts will be made to update to new upstream major versions when possible, new dependency requirements may prevent doing so. Currently, newer versions require a more recent version of GCC than is available in Ubuntu 16.04 LTS, and more recent versions of ICU and CMake in Ubuntu 18.04 LTS.
mozjs
The GNOME desktop requires the SpiderMonkey javascript engine from Mozilla, which is packaged as mozjs38, mozjs52, mozjs68, mozjs78, mozjs91, etc, and interfaces with it via gjs. Mozilla does not provide separate security maintenance for the SpiderMonkey project and instead irregularly releases new versions which break backwards compatibility of JavaScript language features (used by gnome-shell, extensions, applications) and the C++ API (used by gjs). Fixes for vulnerabilities are not always marked and the project progresses at a rapid pace making it prohibitive to backport security fixes. Because of this, security support for mozjs is provided by providing new versions of mozjs as they become available.
grub, grub2, grub2-unsigned, grub2-signed
Sometimes people ask why we have chosen to ignore CVEs on the grub2 package. The grub packaging is very complicated. The grub2 source package is mostly used with BIOS / CSM mode booting, which has no security boundaries. Without any security boundaries, there's no point to calling any given bugs in the code as "security bugs". Any bugs that allow bypassing secure boot are eligible for security fixes, and those will happen in the grub2-signed and grub2-unsigned packages. (The split is an artifact of the build process; it is not necessary for users to understand why there are two source packages. In short, the unsigned variant is built first and then the signed variant packages those binaries after they are signed outside the build environment.)
Hardening Guide
The default installation of Ubuntu should make reasonable security / usability tradeoffs for most users. It is our goal that you can use Ubuntu without worrying about security and also not be artificially restricted in what you can do with your computer. However, these tradeoffs may not be ideal for all users. Some people may wish to subscribe to Ubuntu Pro in order to deploy industry-standard security benchmarks like FIPS or CIS benchmarks or DISA STIGs.
We've collected some suggestions for proactive hardening steps that system administrators can apply without committing fully to the more comprehensive security policies. We suggest considering:
Disable SSH password authentication. Weak passwords are a leading cause of security breaches. It is far safer to use SSH keys or certificates for authentication to SSH servers.
Raise the vm.mmap_rnd_compat_bits and mmap_rnd_bits settings. Ubuntu uses Address Space Layout Randomization to change some deterministic attacks into probabilistic attacks by randomizing the addresses uses for executables and libraries. Different architectures will have different allowed ranges and the defaults must be chosen in mind of the total amount of memory required by the process with the most stringent combination of alignment requirements and size requirements. Your workload may allow you to raise these values and increase the value of the probabilistic defense. Your workload may require larger contiguous chunks of memory than is available with defaults and require you to lower these values.
- Set BIOS "user" and "administrator" passwords, if available, to prevent disabling Secure Boot. Be careful -- recovering from lost BIOS passwords may be painful or impossible.
- Enable Full Disk Encryption during installation. Be careful -- recovering from a lost disk unlock password may be painful or impossible. You will need to enter a password during the Ubuntu startup process, so it is most applicable to laptops used for travel.
- Configure the screen-locker to lock the screen after a period of inactivity. While it is better to explicitly lock your desktop when walking away, the screen lock on idle time can help if you forget.
Install and configure bolt to limit the functionality of Thunderbolt devices on your computer, which expose raw PCIe through a convenient port. Be careful -- this can prevent you from using your computer if not configured correctly.
Install and configure usbauth or usbguard to limit the functionality of USB devices on your computer. Be careful -- this can prevent you from using your computer if not configured correctly.
Install and configure a firewall. UFW is an easy front-end to help you get started if you don't already have a favorite.
Set sysctl dev.tty.legacy_tiocsti if your kernel has it available to prevent the use of the TIOCSTI ioctl. This is probably safe -- there are very few legitimate uses of this ioctl in the world.
List unused network protocols, drivers, line disciplines, via /etc/modprobe.d settings to prevent automatic kernel module loading these features.
Vulnerabilities
- What does CVE stand for?
Common Vulnerabilities and Exposures. From their FAQ:
- CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."
Unofficial Software
- Should I manually install software from third-party web sites?
- Software contained in the Ubuntu archive has been specifically packaged to work well and integrate properly with the system. Software installation tools that come bundled with Ubuntu, such as the Ubuntu Software Centre and Update Manager, validate packages when they are installed to make sure they are secure and have not been manipulated or trojaned during their download. Also, a large subset of packages in the archive are officially supported by the Ubuntu Security Team and get timely updates for security issues that may arise. Installing a package from an untrusted source is not recommended for the following reasons:
- Packages from unknown sources may be knowingly trojaned or contain malware.
- Packages that are installed without signature verification can be manipulated during download to add trojans or malware.
- Manually installed packages may prevent your Ubuntu installation from properly updating itself, or from updating to a newer release.
- Manually installed packages may not be specifically adapted for Ubuntu, and may break integration and interaction with other packages.
- Manually installed packages do not get automatic security updates, potentially resulting in system compromise when a vulnerability is discovered.
- Software contained in the Ubuntu archive has been specifically packaged to work well and integrate properly with the system. Software installation tools that come bundled with Ubuntu, such as the Ubuntu Software Centre and Update Manager, validate packages when they are installed to make sure they are secure and have not been manipulated or trojaned during their download. Also, a large subset of packages in the archive are officially supported by the Ubuntu Security Team and get timely updates for security issues that may arise. Installing a package from an untrusted source is not recommended for the following reasons:
- Is installing software from a PPA secure?
- Packages installed from a properly configured PPA benefits from signature verification, so they cannot be manipulated by a malicious third-party while they are being downloaded.
- There are no security verifications done on packages in PPAs. When you install a package from a PPA, you are implicitly trusting the owner of the PPA. There are no mechanisms in place to prevent the owner of a PPA from publishing malicious, trojaned, or simply broken packages.
- Installing packages from a PPA may prevent your Ubuntu installation from properly updating itself, or from updating to a newer release.
- Packages from a PPA may not get security updates, potentially resulting in system compromise when a vulnerability is discovered.
- I have discovered a cool replacement for Ubuntu Software Centre/Update Manager that is not in the archives. Is it safe to use?
- The same warnings that apply to manually installed software also apply.
- Some package installation tools have been known to use options that may break your system, such as the use of "--force" during package installation.
- Package installation is a delicate process and some package installation tools do not resolve dependencies in the same manner as the recommended ones. This may cause issues with installed software and with system integrity.
Design
- What are Ubuntu's security policies?
Many common issues come up that may seem to be security design problems, but are actually done intentionally. Please review the Ubuntu Security Policies.
- How do I write secure software?
- There is no single answer, but some good resources are:
David Wheeler's Secure Programming for Linux and Unix HOWTO -- Creating Secure Software (fantastic to start with)
Mozilla's secure web coding guidelines
The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities
A Bug Hunter's Diary: A Guided Tour Through the Wilds of Software Security
CERT's C Coding Standard
- There is no single answer, but some good resources are:
GPG Keys used by Ubuntu
- What GPG keys are used to verify Ubuntu distributions?
The Ubuntu Archives are signed with keys:
pub rsa4096/871920D1991BC93C 2018-09-17 [SC] F6ECB3762474EDA9D21B7022871920D1991BC93C uid [ unknown] Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com> pub 4096R/3B4FE6ACC0B21F32 2012-05-11 Key fingerprint = 790B C727 7767 219C 42C8 6F93 3B4F E6AC C0B2 1F32 uid Ubuntu Archive Automatic Signing Key (2012) <ftpmaster@ubuntu.com>
The Ubuntu ISO Images are signed with keys:
pub 1024D/FBB75451 2004-12-30 Key fingerprint = C598 6B4F 1257 FFA8 6632 CBA7 4618 1433 FBB7 5451 uid Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com> pub 4096R/EFE21092 2012-05-11 Key fingerprint = 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092 uid Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>
The Ubuntu Cloud Images checksums are signed with key:
pub 4096R/7DB87C81 2009-09-15 Key fingerprint = D2EB 4462 6FDD C30B 513D 5BB7 1A5D 6C4C 7DB8 7C81 uid UEC Image Automatic Signing Key <cdimage@ubuntu.com>
The Ubuntu Cloud Images simplestreams are signed with key:
pub rsa4096 2012-10-27 [SC] 4A3C E3CD 565D 7EB5 C810 E2B9 7FF3 F408 476C F100 uid Ubuntu Cloud Image Builder (Canonical Internal Cloud Image Builder) <ubuntu-cloudbuilder-noreply@canonical.com> sub rsa4096 2012-10-27 [E]
The ddebs debug package repositories are signed with key:
pub 4096R/5FDFF622 2016-03-21 [expires: 2021-03-20] Key fingerprint = F2ED C64D C5AE E1F6 B9C6 21F0 C8CA B659 5FDF F622 uid Ubuntu Debug Symbol Archive Automatic Signing Key (2016) <ubuntu-archive@lists.ubuntu.com> pub 1024D/428D7C01 2008-09-02 Key fingerprint = 2512 191F EF87 29D6 E5AF 414D ECDC AD72 428D 7C01 uid Ubuntu Debug Symbol Archive Automatic Signing Key <ubuntu-archive@lists.ubuntu.com> sub 2048g/A2C2A7A5 2008-09-02
The Kernel PPA packages are signed with key:
pub 2048R/17C622B0 2008-05-01 Key fingerprint = 60AA 7B6F 3043 4AE6 8E56 9963 E50C 6A09 17C6 22B0 uid Kernel PPA <kernel-ppa@canonical.com>
The Ubuntu Archive Master key, used for Signing key rotations is:
pub rsa4096/0x0BFB847F3F272F5B 2007-11-09 [SC] Key fingerprint = 153F 1C9E F139 5FBF 0035 2E8D 0BFB 847F 3F27 2F5B uid Ubuntu Archive Master Signing Key <ftpmaster@ubuntu.com>
The Ubuntu Extended Security Maintenance archive is signed with:
pub rsa4096/67C7A026 2017-04-21 [SC] Key fingerprint = 74AE 092F 7629 ACDF 4FB1 7310 B4C2 AF7A 67C7 A026 uid Ubuntu Extended Security Maintenance Automatic Signing Key <esm@canonical.com> uid Ubuntu ESM <prodstack-cdo@canonical.com> sub rsa4096/80EE65B3 2017-04-21 [E]
The Ubuntu FIPS archive is signed with:
pub rsa4096/8D13028C 2017-01-09 [SC] Key fingerprint = A166 8774 12DA C26E 73CE BF3F F6C2 8017 8D13 028C uid Launchpad PPA for ubuntu-advantage
The Canonical OEM Vendor Archives are signed with key:
pub rsa2048 2008-08-07 [SC] 236252602787D6BDC2336849F9FDA6BED73CDC22 uid [ unknown] Canonical Archive Automatic Signing Key <ftpmaster@canonical.com>
Contact
- How can I contact the Ubuntu Security team about issues that are already publicly disclosed?
- Public discussions can take place in the following locations:
#ubuntu-security on irc.libera.chat (publicly logged),
by reaching out directly to security@ubuntu.com .
- Public discussions can take place in the following locations:
- How should private security issues be reported?
The preferred method of reporting a security issue is through Launchpad. Launchpad offers a "Private Security" mode that will only be visible to members of the security team and select administrators. Note that Launchpad will send an unencrypted mail with the contents of the bug report to the reporter. If this is not desired, a direct email can be sent.
All security team members can be reached at security@ubuntu.com. GPG can be used to encrypt these messages. Please use the following key:
Name
Key ID
Key Fingerprint
4072 60F7 616E CE4D 9D12 4627 98E9 740D C345 39E0
Please also see our disclosure and embargo policy
Additionally, the GPG key ids for the security team members can be found on their individual Launchpad pages which are linked to on the security team's page. We will keep this list of keys updated as needed:
Name
Key ID
Key Fingerprint
7684 0A6F FB3D EA51 B723 185F 0EB3 E83D 2911 7223
50C4 A0DD CF31 E452 CEB1 9B51 6569 D855 A744 BE93
EDC4 830F BD39 AB6A C510 47FB 052F 3670 18D5 C3D8
4150 10F1 BA23 C8C7 20DF B1F5 F321 7259 9D8D 2E97
44DF FFE4 C1A0 08E8 3229 E205 611F BDEC D594 6E0F
7FE7 9B44 5728 C8EA 0042 839E 45BC E75B 840B 1F69
88E9 530B CBDD C200 517B 5EB0 F498 D2D9 DE7D AD9C
0ADC B2CF A6B3 532E 8064 1CD2 9067 88EB 31A7 37FF
9027 4443 94FA 0EEB 52BD E0B2 6D4A 7990 BDE2 CC66
4EA3 825A D96C 4A31 335B B054 CD43 2CBF 7079 04EC
5F23 95C9 FCE8 A660 78A8 E9CD CCAA CB01 128F 5657
6C18 C4CA F651 E847 3C66 0340 8A8F 7B1C 0099 3172
F763 837E FAF2 4ADB F356 7E5A 0DC9 8647 D37D 791E
8F06 E0BA C079 6B7E D5A3 63D2 538B 7C0D CCB5 A3C9
62BC A077 1D46 0DE7 3D4D 5F04 6741 9E45 C339 9EDD
7317 6FE2 0082 13C5 BD9E BB79 6B5F 8F2F E775 FC48
0382 7EEE 014E 2DAC 02CC 74F2 EDD0 EA1F DFCF E8FA
9B69 3D74 4080 2E8A 6FF8 03DE 1349 8F03 2CCF E9DA
2E2E 2F98 F570 6567 69BA A76A 96F7 70C7 39BC 5ACE
DEFD 03E6 3B26 5010 AA4D CE9D A875 0498 61C3 818F
B35E BCD3 5C67 17BC 0ADE B08A EC87 3ACE D468 723C
D968 2DBE 6C26 7206 8404 B967 080B CAD5 0BC3 E920
00F6 164E 9C2D 21BA FBC4 7E0E 58DA D120 A693 9167
A3A5 5CBD 534E 85F9 6B33 C3C6 46D9 8A9C 81D6 DFDE
842F 72F5 7740 1503 C2BD 85DC 8469 9748 68A4 9E75
E6B9 3048 B0BD 9EDA BCE3 0DFD EC3B 6B6A 6F60 C8C3
DBE9 37BD 8468 F721 CD47 59A7 C660 2BC7 B86A 3ED0
05C3 18FA 7C12 D826 3BD6 C516 738B DD02 ABDD 96C6
7C87 9CFE E766 6FEB 92D1 9CCF 33D6 780C 08BD 8BCD
71FB F17B E7E5 2D0C 2A2C 9144 F0B6 1460 B04C 4B56
CA76 B8FF 6BEE F559 25BE 3A65 27BC 4FFA 4459 39B8
DBAC A8CC 694B BD8F 0F2E 64BD 0BE7 6EF9 F3A3 884C
AEE1 7FB5 A55E 0900 0C57 E8FB 199C 5BF4 DFD6 0328
4C1F E720 3CBD 9EF0 9280 0523 DE05 D098 EFD3 AF7C
2B1C 3DC8 E80A A9A9 FBFE 4FB6 703A AD91 046C D76E
77A8 B91B 62C9 FE75 F70F 6F82 A3BF F616 8D21 7C0C
91DF 7C99 D15C 9D07 4FEE F424 B86A EDCE 8B7B A4E7
B7C2 A106 6F3E 7C3B 03F6 9594 635C 65FF 1ED4 BA87
B203 D9C0 E11E 6265 8015 CC5A E02C CF71 9653 F2E4
47F2 2AE7 A275 4291 722B F090 F6E1 40F6 DB35 9E58
0B76 30B2 A7E6 6D8F B18F 466C 3E3A 8051 6A22 B394
95D9 DED1 53BE 79BA D4A7 C773 BB05 ADC4 298B 2829
F389 8AB3 3FCF 5009 FB61 7FB2 AA11 2B18 F162 8D3F
Group key receival:
gpg --keyserver keyserver.ubuntu.com --recv-keys 0EB3E83D29117223 6569D855A744BE93 052F367018D5C3D8 F32172599D8D2E97 611FBDECD5946E0F 45BCE75B840B1F69 F498D2D9DE7DAD9C 906788EB31A737FF 6D4A7990BDE2CC66 CD432CBF707904EC D9BDA4C843430A68 8A8F7B1C00993172 0DC98647D37D791E 538B7C0DCCB5A3C9 67419E45C3399EDD 6B5F8F2FE775FC48 EDD0EA1FDFCFE8FA 13498F032CCFE9DA 96F770C739BC5ACE A875049861C3818F EC873ACED468723C 080BCAD50BC3E920 58DAD120A6939167 46D98A9C81D6DFDE 8469974868A49E75 EC3B6B6A6F60C8C3 C6602BC7B86A3ED0 738BDD02ABDD96C6 33D6780C08BD8BCD F0B61460B04C4B56 27BC4FFA445939B8 0BE76EF9F3A3884C 199C5BF4DFD60328 DE05D098EFD3AF7C 703AAD91046CD76E A3BFF6168D217C0C B86AEDCE8B7BA4E7 635C65FF1ED4BA87 F6E140F6DB359E58 E02CCF719653F2E4 3E3A80516A22B394 BB05ADC4298B2829 AA112B18F1628D3F
SecurityTeam/FAQ (last edited 2024-07-12 08:16:38 by 0xnishit)