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 _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
