FAQ

Official Support

  • What does official security support mean?
    • Members of the Ubuntu Security team are Canonical employees who provide security updates for supported software in the Ubuntu distribution. Security updates are in part prioritized based on severity of impact, exploitability and number of affected users.

  • What software is officially supported by the Ubuntu Security team?
    • Ubuntu is currently divided into four components: main, restricted, universe and multiverse. Packages in main and restricted are supported by the Ubuntu Security team for the life of an Ubuntu release, while packages in universe and multiverse are supported by the Ubuntu community.

  • Who can receive official support?
    • Official support is provided free of charge to all users of Ubuntu during the life of an Ubuntu release. You can see the release schedules in Releases.

  • How do seeds determine the length of official support?

    • The code that generates the "Supported" field in the Packages file for the main component is part of the Publisher.

    • For Ubuntu 10.04 LTS, the list of 5y supported packages is here.

  • How will support for Ubuntu Touch be provided?
    • Official support will be provided to Ubuntu Touch devices via system-image updates. The supported packages will be based on the ubuntu-touch seed (see above for more on seeds). The stable release branch will be supported along with the most current stabilization (aka, 'RTM') branch if one exists such that when the latest stabilization branch is released, it will become the new stable release branch at which point the old stable release and stabilization branch will be EOL. (Note: stabilization branches will be short-lived and won't overlap).

Repositories

  • How are the "-updates" and "-security" pockets different?
    • -updates includes things that have gone through the StableReleaseUpdates process, and contain various important bug fixes. 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.

  • 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 12.04 LTS, the Precise Pangolin, is simply precise, while the security pocket for Ubuntu 12.04 LTS is precise-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 update pockets enabled. Systems configured to use only the security pocket are also supported.

    • 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?
  • 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 maintain a list of known false positives here.

Packages

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.

Architectures

Ubuntu is built for many architectures. Officially supported architectures for a particular release of Ubuntu can be found in http://archive.ubuntu.com/ubuntu/dists/<release>/main/ and ported architectures (where maintenance is best-effort) are in http://ports.ubuntu.com/dists/<release>/main/.

Release

amd64

arm64

armel1

armhf1

hppa

i386

ia64

lpia

powerpc

ppc64el

sparc

Details

6.06 LTS (Dapper)2

yes

--

--

--

ports

yes

ports

--

yes

--

yes

N/A

6.10 (Edgy)2

yes

--

--

--

ports

yes

ports

--

yes

--

yes

N/A

7.04 (Feisty)2

yes

--

--

--

ports

yes

ports

--

ports

--

yes

N/A

7.10 (Gutsy)2

yes

--

--

--

ports

yes

ports

--

ports

--

yes

N/A

8.04 LTS (Hardy)2

yes

--

--

--

ports

yes

ports

yes3,6

ports

--

ports

N/A

8.10 (Intrepid)2

yes

--

--

--

ports

yes

ports

yes3

ports

--

ports

N/A

9.04 (Jaunty)2

yes

--

ports

--

ports

yes

ports

ports

ports

--

ports

N/A

9.10 (Karmic)2

yes

--

yes4

--

--

yes

ports

ports

ports

--

ports

N/A

10.04 LTS (Lucid)

yes

--

yes4,5

--

--

yes

ports

--

ports

--

ports

Release Manifest

10.10 (Maverick)2

yes

--

yes4

--

--

yes

--

--

ports

--

--

Release Manifest

11.04 (Natty)2

yes

--

yes4

--

--

yes

--

--

ports

--

--

Release Manifest

11.10 (Oneiric)2

yes

--

yes4

--

--

yes

--

--

ports

--

--

Release Manifest

12.04 LTS (Precise)

yes

--

ports

yes4

--

yes

--

--

ports

--

--

Release Manifest

12.10 (Quantal)2

yes

--

ports

yes4

--

yes

--

--

ports

--

--

Release Manifest

13.04 (Raring)2

yes

--

--

yes4

--

yes

--

--

ports

--

--

Release Manifest

13.10 (Saucy)2

yes

ports

--

yes4

--

yes

--

--

ports

--

--

Release Manifest

14.04 LTS (Trusty)

yes

ports

--

yes4

--

yes

--

--

ports

ports6

--

Release Manifest

14.10 (Utopic)

yes

ports

--

yes4

--

yes

--

--

ports

ports6

--

Release Manifest

  1. armel is ARMv5t on 9.04 and 12.10, ARMv6 on 9.10, and ARMv7 on 10.04 LTS through 12.04 LTS. armhf is ARMv7 starting with 12.04 LTS.
  2. Release has reached end of life and is no longer officially maintained
  3. While LPIA is listed in ports.ubuntu.com for this release, it should be considered a supported architecture
  4. While ARMEL and ARMHF are listed in ports.ubuntu.com for this release, they should be considered supported architectures
  5. Architecture is supported for 18 months on this LTS release
  6. While ppc64el is listed in ports.ubuntu.com for this release, it should be considered a supported architecture
  7. Pending final release sign-off

Endianness

Sometimes a security vulnerability affects a particular architecture or endianness. Most architectures in Ubuntu are little-endian, some are so-called bi-endian and some big-endian. In Ubuntu, the endianness of a particular architecture can be see in the following table:

Architecture (hardware name)

Little Endian

Big Endian

amd64 (x86_64)

yes

--

armel (armv5tel)

yes

--

armhf

yes

--

arm64

yes

--

hppa (parisc)

--

yes

i386 (i686)

yes

--

ia64

yes

--

lpia

yes

--

powerpc (ppc64)

--

yes

ppc64el

yes

--

sparc (sparc64)

--

yes

Software

SSH

  • When I run ssh HOST sudo CMD..., I can see the password as I type it. How do I fix that?

    • There is no "tty" allocated when running commands directly via ssh, please add the "-t" flag.

  • When I connect to my ssh server port, I can see a banner with the exact version I'm running. Can we include a patch to disable the version number?
    • There is an upstream bug that gets into detail about this feature, but Ubuntu does not want to carry the patches unless upstream approves.

    • Hiding the version number is Security through obscurity, which is not real security.

    • SSH clients, including OpenSSH, usually parse the version string in order to identify known bugs/features with a particular version of the server. Changing the values could introduce communication problems with certain clients. See compat.c in the OpenSSH source code.

Sudo

  • Why does Ubuntu disable the root account and use sudo instead?
    • See RootSudo for a thorough discussion, but simply put, sudo offers many benefits including (but not limited to):

      • protecting the user from accidentally damaging parts of the system
      • providing a log audit trail
      • preventing brute-force login and ssh attacks to a well known account
      • authentication timeouts
      • fine-grained granting of privileges
  • I am not prompted for my password when I run "sudo" for a second time!
    • sudo is 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 Apparmor or 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.

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:

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. 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)
  • When the PAM session is closed via the screensaver, all keyrings are locked, and the 'login' keyring is unlocked upon successful authentication to the screensaver
  • All keyrings are locked on logout of the user's session

This provides:

  • A good usability experience
  • Protection against access from anyone to keys when the user is not authenticated
  • Protection against other users on the system at all times

Some people may not like to use keyrings in general and there are certain environments where their use is not appropriate. Users can always choose to not store their passwords in the keyring at all. Furthermore, gnome-keyring behavior can be adjusted:

  • Temporarily by using seahorse and manually locking the unlocked keyring

  • Permanently by changing the passphrase of the 'login' keyring
  • Permanently by removing gnome-keyring from the PAM stack

Please note that by changing this behavior, programs that need access to the unlocked passwords will prompt you for the keyring passphrase whenever they need it.

In general, using a keyring does not weaken the security of the system. To use them safely1:

  • You should choose a strong login passphrase (eg, using a mixture of letters, numbers, capitalization and non-alphanumerics that is at least 8 (preferably 12 or more) characters long and not subject to a dictionary attack). This login passphrase should be memorized, and not written down.
  • You should always lock your screen when you step away from your system. You can set a short inactivity timeout and/or better yet, use 'ctrl+alt+l' or activate the screensaver from within your session every time you step away.
  • 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] 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.

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.
  • 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

Contact

  • How should private security issues be reported?
    • 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. 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.


CategorySecurityTeam

SecurityTeam/FAQ (last edited 2015-01-21 13:36:08 by mdeslaur)