Security Checklist

Intent

This checklist is intended to be a starting point for the ApplicationReviewBoard to use when evaluating applications for PostReleaseApps. It is very important that while this checklist presents several items to think about, it should not be considered complete. Furthermore, this is not intended to catch malicious code (but may help in this regard). Malicious code can only be caught through detailed analysis and auditing, but can largely be prevented through social means (see below).

Checklist

• no listening network ports (loopback should be discouraged to avoid CSRF)
• should not require running as root at any time (ie, no "one-time configuration", etc)
• no setuid
• highly discourage setgid, and review very closely if must be used
• no privilege escalation (eg, sudo, su, sg, gksudo, gksu, pkexec, ...)
• no cron or at jobs (defeats sandboxing)
• no customizable maintainer scripts (ie, use debhelper only)
• no modifying of the system update mechanism. Eg
  • no modifying of /etc/apt/sources.list
  • no modifying files in or adding files to /etc/apt/sources.list.d
  • no adding PPAs
  • no modifying of/adding of keys/keyrings in /usr/share/keyrings (or via apt-key generally)
• no editing/adding to /etc
• no editing of/adding to system library configuration
• should follow Ubuntu Policy for package install and should be lintian clean for security/system relevant warnings and errors
• no editing of configuration that the application does not own (eg dotfiles, existing gconf keys)
• cannot install/upgrade software with this software
• carefully look at changes to mime handlers or mime-types
• no browser plugins/extensions (should use the Ubuntu archive instead)
• should not reimplement password/credentials storage (ie, use gnome-keyring/kwallet/etc if possible, but no access to other items stored in the keyring/wallet)
• restrict cross application information usage. eg, don't access firefox password database, GeoIP, etc
• use of dbus session should be closely examined (system bus should be even more scrutinized if not disallowed entirely)
• must build on the target Ubuntu release with default compiler/tools
• the application and all embedded libraries are considered part of the application. Eg, if embed libpng, then this embedded library must be maintained by the author. Should highly discourage use of embedded libraries where that library already exists in the archive for that release
• no modifying of system configuration such as update-motd, pam, kernel boot parameters, etc
• generally should not use /tmp, /var/tmp or /dev/shm but instead use a non-sticky/non-worldwritable scratch directory for this application only

• developer must sign a developer contract and preferably pay to have an application considered in PostReleaseApps (eg, $1 USD). Why?

  • makes sure the developer knows the requirements
  • discourages anonymity. People are less likely to do intentional harm if there is a fear of getting caught. Having a signed agreement with credit card and contact information is a strong social and psychological deterrent.

Some thoughts on implementation

These aren't meant to be comprehensive by any means, but are included here since some of these techniques came up during our discussion

• install in /opt to avoid interfering with the system, except where explicitly allowed (eg, desktop files)

• sandboxing should be encouraged (the types and methods were discussed in the UDS Natty session for appdevs-desktop-n-app-sandbox). Some of this could include namespaces, AppArmor profiling, separate X servers, wrappers, DAC, VMs, etc. These can be use separately or in combination.

• look at android xml for what permissions android developers are asking for a better understanding and for mistakes/improvements to PostReleaseApps

• look into running dpkg as non-root. This has not been tested in any way but there are some interesting benefits (and tradeoffs) to this technique. Some possibilities surrounding implementation include:
  • hard link dpkg to dpkg.extras
  • dpkg.extras runs as a dedicated, unprivileged user, installing things into somewhere in /opt that it owns
  • dpkg.extras has a completely separate /opt/var/lib/dpkg (etc, etc) hierarchy

  • dpkg.extras could be tightly confined by AppArmor to enforce installation policy

• a general purpose wrapper/launcher could be used to perform some static checks (eg, safeguard against running as root, with privileges, ...)

Other concerns

• Need to have a privacy policy in place (also make available as part of developer contract)
• Need to have a clear plan for when security vulnerabilities and violations of policy are found in the application. These terms should be part of the developer contract
• How to deal with things such as targeted advertisements?
• Where things can be automated, do so and make sure they are part of the future SDK
• What about major/minor upgrades. eg application at 1.0 is accepted, do we re-review that application? what if 1.1 or 2.0 or 1.0.1 is radically different? how will we check that?