Roadmap

Differences between revisions 137 and 138
Revision 137 as of 2010-11-16 22:35:28
Size: 12952
Editor: pool-71-114-238-221
Comment:
Revision 138 as of 2010-11-17 15:20:50
Size: 14056
Editor: pool-71-114-238-221
Comment:
Deletions are marked like this. Additions are marked like this.
Line 147: Line 147:
 * wiki documentation for authorization (taken from [[https://blueprints.launchpad.net/ubuntu/+spec/security-m-wiki-authorization|security-m-wiki-authorization]])
  * review current authorization mechanisms in Ubuntu
  * review current wiki documentation for authorization mechanisms in Ubuntu
  * update https://wiki.ubuntu.com/Security/Privileges accordingly
 * wiki documentation for authentication (taken from [[https://blueprints.launchpad.net/ubuntu/+spec/security-m-wiki-authentication|security-m-wiki-authentication]])
  * review current authentication mechanisms in Ubuntu
  * review current wiki documentation for authentication mechanisms in Ubuntu
  * create/update https://wiki.ubuntu.com/Security/Authenticaion accordingly
Line 159: Line 167:
 * community USNs (taken from [[https://blueprints.launchpad.net/ubuntu/+spec/security-m-community-usns|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

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)
    • squid (possibly P2 (talk to elmo)) (contributed profile in LP: #497790)

    • awstats
    • analog (in progress)

    • mailman
    • asterisk (universe)
    • exim4
    • nagios/nrpe
    • openssh-server (not easy, as users can spawn anything)
    • pidgin
    • empathy
    • mail clients (thunderbird, kmail, evolution) -- difficult
    • eog
    • totem
    • 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

Unscheduled Wishlist Items

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

  • ARM kernel security features need work.

  • more PIE applications
    • totem, xserver-xorg, pidgin
      • avoid CPU bound apps
      • Clamav is already contained and is too cpu-bound to use PIE
      • Sasl?
      • Cyrus is too cpu-bound
      • Totem (Gstreamer) - very cpu-bound - needs testing to determine if performance impact is acceptable
      • 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?
  • work through blockers of filesystem capabilities and implement

  • find origin of random "screen does not lock" bugs:
  • fix remaining executable stacks

  • ufw improvements
    • fail2ban integration
    • ufw-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
    • possibly use hashlimits for 'limit' command to better support ip6tables
    • 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
  • 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

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

  • 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
  • wiki documentation for authorization (taken from security-m-wiki-authorization)

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

  • fscaps (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
  • 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

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:
    • perhaps a "Universe packages of the week?" (only if you are also available (we'll be in #ubuntu-security on ...))
    • 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 2022-01-04 22:38:06 by rodrigo-zaiden)