Roadmap

UDS Planning

Documentation

  • The Security Team FAQ needs to be filled with answers to the various questions Ubuntu gets about security.

  • The Security Team KnowledgeBase need more to be written. Many ideas have already been listed there.

Investigations

Several ideas for possible work come from investigating existing the installed set of packages.

  • setuid: which programs are setuid and what may be needed to improve them.

  • measure how many bits of randomness are actually being used in kernel ASLR, compared to other ASLR implementations.
  • review ideas from brainstorm.

AppArmor Confinement

The following profiles have been identified and prioritized as targets for AppArmor confinement. A number of profiles already exist and are not included in this list. Please note that a high priority does not indicate a committment to develop the profile during the current development cycle.

  • Top priority
  • Secondary priority
    • nmbd (see blueprint)

    • winbind (see blueprint)

    • smbd (example profile which is opt-in only and disabled by default) (see blueprint and bug #545061)

    • spamassassin (spamd)
    • acroread (likely not possible due to constraints of agreement with Adobe)
    • openvpn
  • Tertiary priority
    • dnsmasq (exists in apparmor-profiles)
    • awstats
    • analog (in progress)

    • mailman
    • asterisk (universe)
    • exim4
    • nagios/nrpe
    • openssh-server (not easy, as users can spawn anything)
    • pidgin
    • empathy (in progress)

    • mail clients
    • eog
    • totem (in progress (preliminary))

    • skype WONT FIX (likely not possible due to constraints of agreement. People can use the profile shipped in /usr/share/apparmor-profiles/extras - see #226624)

    • ekiga
    • rhythmbox
  • Unspecified priority
    • portmap (low-effort)
    • rpc.statd (low-effort)
    • scripts that people tend to give sudo access. For example: apache2ctl, initscripts
    • munin

There is also a list of AppArmor items to work on on the upstream roadmap page.

Unscheduled Wishlist Items

This area can be used to list ideas for future security work, or link to bugs that describe "Wishlist" issues.

  • deroot auditd
  • review existing AppArmor profiles for "/bin/bash ix" and network rules to look out for unexpected network access by bash (cups, evince).

  • ARM kernel security features need work.

  • more PIE applications
    • xserver-xorg
      • avoid CPU bound apps
      • Clamav is already contained and is too cpu-bound to use PIE
      • Sasl?
      • Cyrus is too cpu-bound
      • Vlc (not in main), cpu-bound, but riddled with problems and little maintenance within Ubuntu
      • archivers
    • Security team could make available a PPA for PIE testing, and the community could do performance testing
    • possibly add comment in the binary that won't get stripped
  • get default Private home directory set up, even if ecryptfs not in use:
    • https://launchpad.net/bugs/353231

    • internationalization issues, would need to be added to the list of folders that are already translated (xdg)
    • user confusion: Is the private directory encrypted or not?
    • (taken from security-m-private-directory)

      • research freedesktop.org specs for correct usage of Public directory
      • figure out reasonable directory/symlink layout for shared directory
      • talk to ubuntu one about integration
      • create wiki page explaining the case for 700 home dirs
      • present changes to tech board
      • implement changes in maverick packaging
  • work through blockers of filesystem capabilities and implement (taken from the security-m-dpkg-fscaps blueprint):

    • verify each filesystem used by installer can handle extended attributes
    • pursue adding xattr support to squashfs
    • drive tar xattr/acl patches into upstream
    • make sure tar gracefully handles restoring to a filesystem that lacks xattr/acl support
    • find a way to have "dpkg-deb -c" display xattrs sanely
    • drive cpio xattr/acl patches into upstream
    • pursue adding -AX to -a in rsync upstream
    • identify common code pattern upstreams can use to validate caps, drop privs, etc
    • engage Debian on defining best practices of fscaps
    • document how a package maintainer should handle adding fscaps to their package
    • implement "ping" as working example of fscaps done with Debian packaging
  • find origin of random "screen does not lock" bugs:
  • fix remaining executable stacks

  • ufw improvements
    • fail2ban integration
    • ufw-notify (eg app-indicators or something like apparmor-notify)
    • enable ufw by default (https://bugs.launchpad.net/bugs/382938)

      • new application profiles open by default, but configurable
      • look into things like port 25 if mail-transport-agent is installed
    • network-manager integration (create a new network, open it up)
    • dynamically detect outbound connections and somehow prompt (be careful with desktop DoS!)
    • simple gui to turn on and off, turn on off and application selectors (location? control center applets). Talk to gufw about this
    • D-Bus/policykit integration
    • manage FORWARD
      • NAT
      • port redirections
      • masquerading
    • QoS
    • dh_ufw
    • support 'tables'. Eg 'ufw table <blacklist> file /etc/ufw/blacklist.txt ; ufw deny <blacklist>'

    • configurable limit parameters
    • mac address filtering
    • location-based firewall support (http://osdir.com/ml/networkmanager-list/2011-03/msg00030.html)

  • unified method to ask security questions
  • approach upstream glibc about futility of fwrite checks when lacking fprintf and fclose checks
  • automated Debian-security fetch/try/build system (mom, ubuntuwire (rcbugs), pitti may have some)
    • Get a report with some debdiffs the security team could review
    • At least open a bug with a failed/fuzzed debdiff that could be used as a starting point for community work
    • https://bugs.launchpad.net/bugs/382945

  • Containers
    • look into containerized-packages (as in apt-get install apache-chroot). Special attention on virtual hosting, updating and adding packages and modules. Another option would be to develop an apparmor profile and/or selinux policy.
    • containerize schroot (taken from security-m-schroot-containters blueprint)

      • develop CLONE_NEWPID schroot helper
      • develop test cases for CLONE_NEWPID and schroot
      • package CLONE_NEWPID schroot helper
      • document CLONE_NEWPID schroot helper
      • send helper patches to upstream schroot
  • Modify debsecan package to grab CVE reports from USN
  • Modify apt-listbugs package to check package CVE's from USN.
  • Improved use of cryptography integrated well with Ubuntu
    • Encrypted swap by default on all installations
    • eCryptfs + SELinux/AppArmor integration, to protect encrypted data from root
  • Sweeping, static analysis of all of main (then universe)
  • Security Certification / Documentation
  • Implement more useful SAK that does not kill a running X server/session (Secure Attention Key: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=Documentation/SAK.txt;hb=HEAD). The current SAK implementation closes everything that has /dev/console open, including entire tty7 (graphical display), while the Windows implementation is more useful because there is an option to require Ctrl-Alt-Del prior to entering any log on password (initial log on, re-log on after returning from screensaver, etc.). LP: #1037653

  • add/expand checks in checksecurity
  • 2-factor authentication (taken from security-m-2-factor-auth blueprint):

    • write wiki page detailing types of 2 factor auth
    • create howto for remote access one-time password: HOTP/yubikey (new) or opie s/key (old)
    • create howto for USB key storage of ecryptfs key
    • create howto for smartcard storage of gpg and ssh keys
    • create howto for fingerprint reader authentication
    • investigate two factor auth to Active Directory
    • add appropriate howtos to official documentation
    • ecryptfs support

  • wiki documentation for authorization (taken from security-m-wiki-authorization)

  • wiki documentation for authentication (taken from security-m-wiki-authentication)

  • community USNs (taken from security-m-community-usns)

    • generate template in usn-tool for community USNs
    • define the manual process for processing a community USN
    • investigate/implement an automated process for generating community USNs based on changes mailing lists
  • guard against authentication spoofing (taken from security-m-authentication-spoofing)

    • add random aboutme picture selection at user creation
    • add aboutme picture to policykit dialog box
    • add aboutme picture to gksu dialog box
  • Rid the archive of MD5 and SHA1 in a security context
    • problem is defining what is being used in a security context.
    • Look at all functions in crypto libraries that use MD5 then scan the archive for these things.
    • Perhaps define how to make this more discoverable-- could print errors, but this is risky and too many false positives. Could also spew if the environment variable is set. May take a couple of months.
  • implement something better than md5 in debsums
    • make sure packages in main make use of debsums at build time
  • document a central syslog logging server setup
  • verify and update aide documentation
  • document recommended 2-factor mechanism
    • examine available hardware tokens and find something sufficiently cheap to recommend

Not Interested

  • hardened default config (Bastille-like). Check the compatibility of debian-bastille. Status: reviewed. what can be done in a default install is already being done

  • grsecurity features. Status: reviewed. many features are upstreamed already, remaining viable options are now planned in the kernel hardening roadmap.

Community Participation

These are some ideas that came out during the community growth meeting at UDSKarmic:

  • for the SecurityTeam

    • more IRC workshops
    • blog more
    • always participate in Ubuntu Developer Week
    • participate with Hall of Fame or 5-a-day
    • work even more closely with Debian
  • Encourage community involvement:
    • some focused event like suspend/resume with kernel team or maybe hug days. This could be done with apparmor profiles ('Apparmor Week')
    • participate with security documentation
    • testing
      • automated test cases could be created for each release (autohotkey for Windows allows to replay GUI actions for testing a PoC)
      • perhaps look into applications to replay actions
    • have a ppa to pull profiles from profile repositories and make them available
    • make testing very easy
      • make-test-tarball is a start, but also need to create VMs easily. vm-tools is a start, but needs to be even easier (maybe grab an image from somewhere...)
    • talk to server team about a survey about features. many of these will likely be security features
  • Disseminating information
    • communicating the security team's needs can be handled (in part) by the community team
    • communication about needed apparmor profiles could be improved
    • maybe talk about what our needs are (eg universe, apparmor profiles, etc)
    • have harvest better integrate with security fixes (talk to dholbach and jorge)

    • focus and ask what is keeping people from adopting Ubuntu
      • we should also identify several areas where we become experts and give all the information-- eg if a salesperson is in front of a potential client and is asked 'tell me about all your logging software' or 'tell me all the ways you handle user credentials and authentication'
  • look into USN-C (community USN) and a way to attach the name of the committer/uploader as a way to increase involvement (though better reputation)

Sub-Topics


CategorySecurityTeam

SecurityTeam/Roadmap (last edited 2012-08-20 14:51:30 by jdstrand)