Attachment 'secteamessen2015.html'

Download

Agenda for Security Team Meeting
--------------------------------

Participants:
 - carnil
 - jmm
 - raphael
 - luciano
 - thijs
 - fw

Starting: Sat, 17 Jan 2015 11:08:04 +0100
End: Sat, 17 Jan 2015 18:47:12 +0100

Workflow
========

- Improvements needed for dsa-needed.txt
  - like more automatisation?
  Nope.
  TODO: reduce to the minumum packages to dsa-needed review (bin/add-dsa-needed.sh --stdout)
  
  - The repo with embargoed issues isn't used much, what can we do to improve that?
  TODO: Add the hook to send commits to team alias
  
  The private TODO file: add the date and send the list to team alias. It is the place to put unresolved thing for FD. If stalled for months anyone should feel empowered to remove it as it's unlikely that we're going to pursue it further (perhaps after trying to get it forwarded to maintainer/upstream).

- Lots of uncaught spam to team alias (dozens per day). Investigate mesures.

 TODO(thijs): ask to DSA for solutions.

- Is RT abandoned, do we still need to clean up old issues from the security queues?
 TODO: empty these queues and remove them ASAP.

- Draft new people, possible candidates
 The bottleneck is not the tracker update, but check the affected packages and fix them, which is quite complicated.
 TODO: in the meeting notes announce ask for help.
 How can people contribute these days:
     - tracker is well-covered, mostly in the need of proposed wheezy updates and people NMUing packages for sloppily maintained packages in sid
     - check dsa-needed and propose a patch or offer testing.
     - ask people to prepare updates for no-dsa issues
     - find embedded code copies (in binary packages) and missing security patches
     - TODO: how to start contribution in security-team.d.o (e.g. process dsa-needed)
     - TODO: parse ./data/embedded-code-copies and crosscheck with unfixed issues. Create a view in the tracker for this.

- Opening up the security process further to allow maintainers of packages with frequent issues to release updates themselves. Needs a more detailed workplan:

  - Updates need to be reviewed/acked by sec team members

  - Requires changes to dak to no longer require access to security-master,
    e.g.  by using a mechanism similar to allowing a DM to upload and sending
    error messages to the signer of the upload (already requested by Thijs)

  - Requires changes to debian-security-announce

  - Same for DM uploads. TODO: contact ftp-masters/list masters for that (jmm will do it)

- Fix up DSA candidates script to only present packages with open issues not in
  dsa-needed and not tagged no-dsa
  DONE -- raphael

 - Handling of "old", unused, CVE ids in our CVE pools: we have ids from 2013, 2014. 2012's were REJECTED by MITRE after we notified them of the "leftovers"
     DONE: keep them

Tools
=====

- Compile a list of issues we want to see fixed
    TODO: Ping FTP masters, whether the reject mail can be sent to the mail address associated with the person who signed the upload (and additionally dak@s.d.o maybe)

- Make it simple to release packages for others to test, e.g. an aptable security queue, what is needed to implement that?
 -> Simpler approach by whitelisting desired source packages and their build which will be placed into an apt'able location?
    TODO: contact ftp-master about a solution

  security-proposed-update. Needs some sort of division between un/embargo packages
  TODO: Talk to FTP masters

- How can we leverage autopkgtest for testing security updates in jessie?
  debci instance with access similar the buildd's to security-master to autopkgtest packages uploaded to security-master. To be run in a different host. As a fist step the instance might only test the packages already released through security.d.o, later on modified to the internal repo for not yet published packages.

- Migrate to git during the weekend? Since most people are around and we'll be actively using all tools anyway, we can fix all fallout right-away.

 - hook scripts
 - gen-DSA vs push-time
 - split the tracker code and the tracker data
 - split the CVE list per year
 - name change to debian-security

    raphael's not convinced of dropping history

- Move remaining cronjobs (daily DSA mail, external check) to the role account
  - check-external: done, raphael's has now been disabled
  - dsa candidates: wip
  - daily dsa: ?
  - unknown packages: done

Tracker
=======

- Add a new status to differentiate between "no-dsa, if the maintainer wants to fix in a point update go ahead" and "no-dsa, was ignored because it's not possible to backport" (this is e.g. needed to cover non-backportable issues like CVE-2013-4148 et al. for KVM).
   TODO: Split from “no-dsa”: “unfeasible” (backport is not possible), “minor” (no action from security@, maintainer can fix it through s-p-u)

- Check open bugs in the BTS against security-tracker pseudo package

#508031: wontfix (DONE)
#769128: sounds doable this weekend → fw (DONE)

- Support for consistency checks on source package names, e.g linux-2.6/linux or all of the ruby packages, track package renames

  Cannot be easily fixed, deeply in the tracker core logic

- Automatically add <end-of-life> tags for unsupported packages
  sounds doable this weekend → fw

- Add a view "all unfixed bugs without a recorded bug" to simplify filing bugs

  sounds doable this weekend → fw (DONE)

- More systematic tracking of CVE requests?

  As a stop-gap measure, file Debian bugs for things without a CVE identifier.
  -> Provides a more reliable TMP-name
  Note linking the CVE-request.

- Automating more tasks:
  + dropping "NOTE: to be rejected" when an issue is marked as REJECTED
  Not really worth the effort, just an additional line. raphael will "easily fix that" -- done
  + script to automatically merge data/next-{oldstable-,}point-update.txt
  Wontfix: each need to be double-checked and happens only every few months
  + get an overview of newly reported bugs in the Debian BTS which have tag security (if one submits a bug not over reportbug we do not get a copy)?
  This already exists more or less with the usertag "tracked" (see tracker introduction), but this needs someone who cleans up the existing data (>200 possible changes currently displayed)
  + Automatically group/reorder unassigned CVE-$year-XXXX item to have them in one place and get a better overview?
  Wontfix: This can happen if/when we split the list file by year.

Documentation
=============

- Work on proper documentation how people can contribute

- What would you like to see in security-team.d.o?

Avoid duplication.
- remove "Problematic packages"
- "If you are a user/maintainer, go here"

- Remove mentions of the "testing security team" since that doesn't seem to exist anymore
in org/TODO there is a list of backlinks to the webpage. Please update there.
https://wiki.debian.org/DebianNetDomains
jmm: Contacted Nico to get rid of the DNS entry testing-security.debian.net

- Fix and upload harden-doc (securing debian manual)
  DONE (thijs)

Distribution hardening
======================

- What new hardening features should we tackle for stretch (= the next release)?
  + PIE on at least amd64 (i386)
  Upcoming changes in GCC 5.0 along with changes in binutils will make the overhead negligable. Fedora 22 is aiming at enabling PIE more widespread, so we could build on top of that:
    https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code

- systemd hardening features; identify a set of important packages
Wait for the stretch development cycle to have progressed a bit more

- improve detection of hardened build flags, maybe write the flags used into an ELF section? This way it could be more reliably checked whether correct flags were used (e.g. for binaries using fortified source, but not using any of the functions covered by it)

  -grecord-gcc-switches writes DWARF data, so it's only useful with  automatic *-dbg package generation (which would be pretty useful in its  own right)

- hidepid by default
No work planned, some resistance since it breaks existing semantics
Bugs? We could use the adm group for gid= procfs mount option

- Root-less Xorg
Initial steps at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748203

- Disable default group staff/mode 2775 ownership of /usr/local. Ask base-files maintainer shortly after jessie release to enable last part of this transition.

jessie
======

- Discuss list of open problematic packages (if not resolved by then)
  * Docker
    TODO: → fw
  * MariaDB/MySQL: Both in jessie as transitional situation; one needs to go in stretch. Make this demand clear early in the release cycle.
  Fix jessie release notes since they currently state that all are supported
  * OpenStack (identify which are the packages to be removed from jessie)

- Start getting required in place for jessie-security:
  - buildds
    - build queues
    - build instances
  - security-master
   - it already exists, but has architectures that are no longer in jessie: ia64, kfreebsd-{amd64,i386}, sparc
  TODO: Contact debian-wb-team@lists.debian.org and maybe make a test upload

- Get more prominence/exposure for 'needrestart'?
  - put it into the release notes
  - tasksel bug

LTS
===

- Review; what is working well, how is it keeping up, we can we do to help?

Good commitment of the people involved. Good response time.
Even with 25% of funding, the support covers more packages than other distros.

- What tool changes need to be made?
Starting with Wheezy it woul be good to make the fixed packages availablde through security.debian.org
Need to phase out packages.qa.d.o which doesn't know about lts.

Others
======

- Distribute the new security team key on what?
    TODO: Create a new key at the meeting, so that people can sign it
    Make the key more long-lived than three years

- Check status of spu notifications and restore this if possible

TODO: Poke jmw on the status again (jmm)

- Finetune DSA mails/template, e.g. add team@security.debian.org as contact address (note contact address is in DSA template already)
  * Get rid of inline signing? Presumed not currently possible with listmaster infra. Test this hypothesis and if valid, ask listmaster if possible to fix


Attached Files

To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
  • [get | view] (2018-05-24 01:43:00, 12.4 KB) [[attachment:secteamessen2015.html]]
 All files | Selected Files: delete move to page copy to page

You are not allowed to attach a file to this page.