Bits from the Security Team
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Debian Security Team met on the first weekend of February at the
Linux Hotel in Essen (along with an FTP master for archive/dak-related
issues). Here's a summary of what was discussed and done. It also
lists various useful tasks for which volunteers are welcome in order
to speed things up.
Attendees: carnil, corsac, fw, jmm, luciano, geissert, ganneff
Debian Security Tracker
- -----------------------
* In some cases source packages get renamed, e.g. the source package
for the Linux kernel was called "linux-2.6" in oldstable and is
"linux" in stable and later. Other examples are the various Ruby
packages which got renamed from libfoo-ruby to ruby-foo. These
renames currently need to be tracked manually. We're planning to
automate these. If anyone wants to help and implement it, please see
#738172
* We've discussed whether older release information should be kept in
the database. There are some performance issues to be considered
since the tracker data gets rebuild with every commit, but adding
support for oldoldstable is still well within the limits of the
system running the Debian Security Tracker.
* debsecan is a tool which is closely related to the Security Tracker:
It uses the tracker data and outputs a list of all open
vulnerabilities affecting a given system. There's currently not much
development going into debsecan since people are busy with other
topics. If anyone is interested in joining the debsecan
maintenance/development (there's a certain level of interest since
several patches are submitted to the BTS), debsecan can be moved to
collab-maint. If anyone's interested please send a mail to
debian-security-tracker@lists.debian.org
* We're considering to periodically send notifications of open
vulnerabilities to maintainers. While we usually file bugs for all
security bugs sometimes issues fall through the cracks and an
additional reminder will be useful. We're planning to perform a test
run and check on how to proceed from there.
* There are quite some vulnerabilities which are addressed in Debian,
but for which no CVE identifier has been assigned. Since the CVE
assignments are monitored by other parties, getting IDs
assigned is useful for the open source community at large. They are
currently tracked at
https://security-tracker.debian.org/tracker/data/fake-names , if
anyone is interested in coordinating CVE assignments, please get in
touch with team@security.debian.org
* Currently dak doesn't send out error and upload processing messages
to uploaders to security-master. This is done to prevent information
leaks of erroneous uploads of embargoed vulnerabilities and public
mailing lists in the Maintainers: stanza of a package. Error
messages will be sent to the primary email address of the PGP key of
the uploaders (which prevents information leaks).
Security release workflow
- -------------------------
* We tried using Request Tracker for some time now. This hasn't
worked out to our satisfaction, so we have already switched to track
pending security updates with a text file in our Subversion
repository. We were still using RT for non-public issues, but we're
planning to track these in an external, private Subversion
repository in the future. Most of the documentation has already
been changed, a change to the developer's reference is pending.
* Historically we've included the vulnerability type and the scope of
a security issue in our DSAs. This has become mostly redundant and
confusing (and it's covered in the advisory text anyway), so we've
started to no longer include these in current advisories.
* The PGP key of the security team is currently handled in a traditional
manner. Our current key expires in September 2015 and we're planning
to move to smart cards for managing the key in the future.
* We're currently using Subversion. We discussed changing to git, but
git doesn't offer significant benefit for our purpose so we decided
to stick with it. However, we're planning a rename of the repository
which is still named after the secure-testing project which is no
longer active and is confusing people.
* Many packages are easily testable, but some packages are more
intricate to setup or they require special purpose hardware. We're
planning to keep a list of willing testers, so if you're running any
of the packages below and are available for tests, please send a
mail to team@security.debian.org:
pidgin, openjdk-6, openjdk-7, drupal6, drupal7, asterisk, quagga,
nginx, torque, openswan, roundcube, typo3, bind9, tomcat6/tomcat7,
mediawiki and gridengine.
Security archive
- ----------------
* In order to avoid bottlenecks and to open up the security process
further we're planning to allow maintainers which are not part of
the security team to release security updates on their own. This
applies to packages which have frequent vulnerabilities and where
the maintainers are involved in the update process anyway. The exact
details still need to be sorted out and some archive changes are
required as well. Currently the release of a security update
requires a login to security-master. We're planning for a mechanism
similar to the procedure to allow upload privileges to DM;
i.e. uploading a signed control message which triggers the actual
update (probably with some tool like dcut). In a later step the
advisory mail could be sent out by dak itself.
* In the past dak provided support for two distinct queues on
security-master; one public and one for private security
vulnerabilities. This feature is currently non-functional due to
changes in dak development in the past, but we're planning to
re-enable it again. This will allow us to make all public security
updates initially available through a separate apt source prior to
the release of a DSA (there's usually a delay between the initial
upload of a fixed package and the release, e.g. to sort out further
tests or to wait until all architectures are built). For non-private
issues making this change opens to wider testing of upcoming
security updates and furthermore earlier availability of updates for
Debian-derived distributions based on oldstable/stable.
* We had occasional problems of mismatched tarballs between
security-master and ftp-master. These are automatically detected and
rejected when the security update is later merged into stable. These
are now automatically detected and rejected when processing an
upload to the security queue. Code which checked these during the
upload was already available in dak and has been enabled during the
meeting.
Others
- ------
* We're tentatively aiming for another Security Team meeting at the
beginning of 2015. At that time Jessie will be in freeze which is a
good opportunity to plan for jessie/jessie+1.
* In some cases the scope of security support needs to be limited (e.g
webkit-based browsers in Wheezy) and sometimes packages need to
end-of-lifed before the security support time frame ends. Currently
this information needs to be retrieved from the release notes or
announcement mails. We'd like to see a more technical solution which
displays the unsupported packages for the installed packages on a
specific system. If anyone wants to work on such a script, please
contact team@security.debian.org and we can hash out the details.
* Our documentation is currently spread across (too) many
places. We're planning to create a one-stop site
http://security-team.debian.org which links all information wrt to
working/contributing on security, e.g. links to the security
tracker, introduction information, links to useful wiki pages etc.
Some preliminary work has already started - e.g. converting the docs
to MarkDown.
Distribution hardening
- ----------------------
* The distribution hardening using dpkg-buildflags is coming along
nicely. Coverage of security-sensitive packages and of all packages
with priority:standard or above is above 95%. Some packages still
need to be addressed or NMUed, please get in touch with
team@security.debian.org if you want to help out.
Coverage of the rest of the archive is also making nice progress, if
you're a maintainer and haven't fixed our packages yet, see
https://wiki.debian.org/HardeningWalkthrough for more documentation.
* GCC 4.9 introduces an improved version of stack protection
(-fstack-protector-strong). We're planning to propose this to the
dpkg-buildflags once GCC 4.9 is the default compiler.
* We're planning to request for hidepid to be enabled by default (to 1).
This will squash an entire class of information leaks. If you have any
comments or objections, please get in touch with us.
* Since Wheezy the Linux kernel features a security mechanism which
nullifies many symlink attacks (fs.protected_symlinks). We're
planning to treat any vulnerabilities which are rendered moot by
this protection as non-issues. If you're using custom Linux kernels
builds you need to enable this option. kfreebsd (currently a
technology preview) and Hurd (currently not a release arch) don't
implement this security feature. We welcome feedback from the
porters whether similar protections exist or whether they're
feasible within the jessie release time frame.
LTS
- ---
* At the moment it seems likely that an extended security support
timespan for squeeze is possible. The plan is to go ahead, sort out
the details as as it happens, and see how this works out and whether
it is going to be continued with wheezy.
The rough draft is that updates will be delivered via a separate
suite (e.g. squeeze-lts), where everyone in the Debian keyring can
upload in order to minimise bottlenecks and allow contributions by
all interested parties. Some packages will be exempted upfront due
to their volatile nature (e.g. some web applications) and others
might be expected to see important changes. The LTS suite will be
limited to amd64 and i386. The exact procedures will be sorted out
soon and announced in a separate mail.
* It needs to be pointed out that for this effort to be sustainable
actual contributions by interested parties are required. squeeze-lts
is not something that will magically fall from the sky. If you're
dependent/interested in extended security support you should make an
effort to contribute, either by contributing on your own or by
paying a Debian developer/consultant to contribute for you.
The security team itself is driving the effort, NOT doing it. Some team
members will contribute to it individually, however.
* Anyone interested in contributing, please get in touch with
team@security.debian.org. We'll setup an initial coordination list
with all interested parties. All policies / exact work will be
sorted out there.
Full minutes can be found at http://titanpad.com/secteamessen2014 and an
archived version can be found at
http://anonscm.debian.org/viewvc/secure-testing/doc/secteamessen2014-latest.txt?view=markup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJTF3RpAAoJEBDCk7bDfE42kJQP/Akej1h4rEhIsZUvD3NDLC0t
6LqZKio2b7COBja0XHLqw+hGozu+NM+HU24394Zwf5Qxim46FMpt3PDawIYMJAo+
5Kp5bCdHc62empqATROekgmMVaaFofX0dloGubYu1idRKELq9jgVuiIMbgaSEiQT
34zboutSd23tdRaXoGaPySN44qhzBn4aSX2KfdCk6c7sTQdUqQ1RaigakipJ7g74
5dpuQ7BACDIMRLh+MJTlLp03nJS2X7idu65ZODSBx7FfpMBcx4oKTXqeh2PX5h48
P9UYTbQJNkISBnislvMHZaizX8JTywdihjZq4K37+XIU6tYS5Ni/L89NZ4oNidTD
aR6faOaV7VOX3070POc8onEu8XrkEADYVtmLzAJllnqxwacgtypZPAiuK1U2l0dm
fAxI0evlU6UCAPhHL9Wl7k+pEJx0Vz4b6aencQEovLzYUdsVslmo4pmV/MSSDSLP
H5TjwIxAXX+aZUeOCloTC5NvmdX88RkAkvXqkGFEOubq5u5DsxHOT9WXI+WH+WKV
Balhu7uyV62L6YRg+tVkZgdTWTpmvcjHzAhwuM5hCq+lxBkYVoloZDpGgjnzMU8P
pM0d/Pn6kDX97OnadwNsMN+UCV0jocyN6JDT6gbplouC4909Lmu7zrHTSlW5aOeo
6RXwSvZbRu/DfsIz27Cc
=L2Ei
-----END PGP SIGNATURE-----
Reply to: