Re: Bits from the Security Team
A lot of this is really great news, thanks for your work!
On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote:
> * In some cases source packages get renamed,.... 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
The debbugs maintainers were going to implement something like this
and Don already has some code apparently so it would be a good idea to
co-ordinate there.
> * We've discussed whether older release information should be kept in
> the database.
This might be useful for folks still using EOL releases.
> * debsecan is a tool which is closely related to the Security Tracker:
I've 3 patches pending for debsecan so I'd definitely appreciate a
move to collab-maint.
> * There are quite some vulnerabilities which are addressed in Debian,
> but for which no CVE identifier has been assigned.
Perhaps we could encourage those submitting security bugs to
X-Debbugs-CC the oss-sec list?
Reading LWN I sometimes note the same issue happens for other
distributions. Does the security team monitor the advisory
announcements of upstreams and other distributions and auto-correlate
those with CVEs?
> * 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.
>From when alioth was having repository issues, it appears having the
full history locally is useful so git would still be a net win. Also
is the SHA-1 hash chain not useful?
> * 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....
The backports archive has a whitelist mechanism, would that be useful?
> * 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.
>From memory some folks not in the security team who wanted to come
missed the last meeting. It would be great to get more people at the
next one.
> * 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.
A mechanism for this already exists/existed, some links:
https://lists.alioth.debian.org/pipermail/debtags-devel/2008-June/001795.html
https://bugs.debian.org/436161
http://anonscm.debian.org/viewvc/debtags/vocabulary/trunk/security-team?view=markup
> * 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
Any reason not to use the wiki?
https://wiki.debian.org/Teams/Security
> * The distribution hardening using dpkg-buildflags is coming along
> nicely.
Unfortunately this doesn't apply to binaries compiled outside of the
package building system. It would be great if we could adopt the
Ubuntu approach of just enabling the flags in GCC itself. Even better
would be to get GCC upstream to finally enable them by default.
> * Since Wheezy the Linux kernel features a security mechanism which
> nullifies many symlink attacks .... 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.
I expect it would be a good idea to directly consult the porting lists
for these ports, not all porters may have read the full mail.
> * At the moment it seems likely that an extended security support
> timespan for squeeze is possible.
> The rough draft is that updates will be delivered via a separate
> suite (e.g. squeeze-lts)
Why not just use the existing suite for this?
Other things:
The information at www.d.o/security could use some updates.
The Ubuntu security folks have a tool called ubuntu-security-tools
that they use for auditing new packages coming in and packages where
flaws are discovered. I expect it would be a lot of work to do that
for Debian but it might be worth it.
git clone bzr::lp:ubuntu-security-tools
Is there much collaboration/synergy with the Ubuntu security team or
those of any other derivatives?
Will security team members be at DebConf14?
Is the team filtering debian-devel-changes and looking for words like
security, overflow, attack etc? This might turn up some things that
don't have CVEs but should.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: