[Secure-testing-team] debconf9

[Michael S. Gilbert]

On Mon, 27 Jul 2009 12:05:35 +1000 Steffen Joeris wrote:

> On Mon, 27 Jul 2009 05:21:29 am Stefan Fritsch wrote:
> > >> Since I haven't been involved recently, nor was it my idea to organize
> > >> this BoF, I also dont have particular agenda items in mind. So, topics
> > >> for an agenda?
> > >
> > > I have a few points in mind which may be nice to discuss:
> > > - more members for testing-security, how do we get new
> > >   people in? I think we have becoming pretty good in
> > >   maintaing the tracker recently but we really lack of
> > >   people who also fix bugs and write patches
> > > - testing migration, almost no one cares about testing
> > >   migration at the moment which is one of the reasons we
> > >   don't have security support for testing at the moment
> > > - testing security support, what needs to be done and how
> > >   can we solve the current problems.
> > > - Debian as a CNA, while we can assign CVE ids the current
> > >   workflow is far from perfect, we have large delays
> > >   sometimes getting CVE ids and I think binding this to one
> > >   person is a rather bad idea.
> >
> > - how to push for enabling more hardening compile options in
> >   squeeze
> > - moving infrastructure to the new KVM instance (currently the
> >   testing-security infrastructure is spread over three non
> >   debian.org hosts)
> > - tracking of packages that got into testing/unstable from
> >   proposed upgrades (and how to detect if the maintainer uploads
> >   a vulnerable version again)
> Although I am not at debconf9, I'd have one point, which could be discussed, 
> where I am not sure how to address it:
> 
> - Discuss on how to make it clear again that (old)stable needs to be supported 
> by developers. It is no issue to admit that backporting is hard or there are 
> other issues with the code, but every developer should be able to help testing 
> their packages on (old)stable. It happens too often that we have to test some 
> random services we've never used and then we might miss a crucial testing 
> scenario.
> -- My input: Maybe add something to the devref and prepare a mail to d-d-a@ ?

i as well will not be at debconf, but i do have some thoughts that
may be interesting to bring up in your discussion:

- getting someone onto the webkit security team since there are an
awefully large amount of disclosed but untriageable webkit CVEs. they
either continue to restrict access to CVEs even after disclosure, or
they just do a really bad job of tracking CVEs in their bts (i searched
and found only one open reference to a CVE in their entire source tree
and zero bugs with CVE references)
- better tracking of non-numbered CVEs; using unique numbers instead of
XXXX so DSAs can be linked permanently (Florian suggested DSN-YYYYY)
- better stable/oldstable bug tracking; it's a chore to tag multiple
affected versions in the current bts when initially submitting the bug
since you can only tag one version (a solution would be for the bts to
accept multiple 'version:' tags, and there is no way to tag as 'fixed:'
in the original bug submission (e.g. when a bug is fixed in unstable,
but not stable).  all of this is possible with a follow-up email to
control, but it is a chore, and it takes too much time often to wait
for the bug number to get assigned.
- execshield or grsecurity by default to harden the kernel.  i brought
this up to the kernel team, but they consider it to be a hinderance and
undesirable since it is non-vanilla.  however, it would be very useful
since, for example, fedora was immune to the /dev/mem rootkit issue due
to their use of execshield. maybe Dann Frazier would have
interest/clout to push for this?
- i would also concur with Steffen Joeris; something needs to be done
to get developers to actually spend time/effort on stable/oldstable.  i
always use a line like "please work with the security team to prepare
updates for stable" in security bug reports, but only a few times has
the maintainer actually taken the initiative to start a dialog and
prepare patches to help the security team.  99% of the time, it seems,
the security team has to act alone to address security issues.
security should be everyone's job.
- external scripts/data as a security threat.  i got into a bit of
a debate a while back with Steffen on this.  some packages fetch
scripts/data from the web, which create a vector for pushing malicious
code onto users systems.  the problem is that these scripts bypass the
dpkg key signing/verification/authentication mechanism.  a solution
would be to require verification against signed known hashes of the
external files (the hashes could be part of the signed debian package).
i personally would like to go through and file RC bugs on all these
problematic packages, but there has yet to be any consensus on the
issue: http://lists.debian.org/debian-devel/2009/02/msg00461.html
- renewed philosophy on rootkits.  i have seen rootkit issues get
considered minor because of the "you've already lost if they've got
root" philosophy. however, i don't particularly agree, and maybe i need
to further write down a clearer philosophy, but part of protecting your
system/data is knowing that you have been compromised, and rootkits
take that away.

well, hopefully some of this is of interest.  i would also like to see
video/outcome of the bof.

have fun!

mike