I''m at debconf9. Are any of you here too? luciano
Hi, * Luciano Bello <luciano at debian.org> [2009-07-23 22:34]:> I''m at debconf9. Are any of you here too?Yes I am sitting in the hacklab currently. How many of s are/will be present? Does it make sense to schedule a BoF? I know at least Moritz is going to join us. Who else will be here? Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0xA0A0AAAA For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090724/7733af76/attachment.pgp>
* Nico Golde <debian-secure-testing+ml at ngolde.de> [2009-07-24 11:02-0400]:> Hi, > * Luciano Bello <luciano at debian.org> [2009-07-23 22:34]: > > I''m at debconf9. Are any of you here too? > > Yes I am sitting in the hacklab currently. How many of s > are/will be present? Does it make sense to schedule a > BoF? I know at least Moritz is going to join us. Who else > will be here?I''m here, Rhonda is here, Maulkin is here, some of the buildd, ftp-master, RM folks are here (sgran, zobel, luk, aba, Ganneff, weasel, others), and some people who have been involved in some capacity at some point (madduck, joeyh... it could be very useful. m -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090724/fb79f8a1/attachment.pgp>
El Vie 24 Jul 2009, Nico Golde escribi?:> Yes I am sitting in the hacklab currently. How many of s > are/will be present? Does it make sense to schedule a > BoF? I know at least Moritz is going to join us. Who else > will be here?Talking with Micah last night, we''re thinking in a BoF to talk about security work-flow. I can schedule it if you are agree. Luciano
El Vie 24 Jul 2009, Luciano Bello escribi?:> Talking with Micah last night, we''re thinking in a BoF to talk about security work-flow. > I can schedule it if you are agree.Micah started a pool in order to agree a proper time slot. http://www.doodle.com/h7bsbevbgvcwvx37 luciano
Hi, * Luciano Bello <luciano at debian.org> [2009-07-25 16:46]:> El Vie 24 Jul 2009, Luciano Bello escribi?: > > Talking with Micah last night, we''re thinking in a BoF to talk about security work-flow. > > I can schedule it if you are agree. > > Micah started a pool in order to agree a proper time slot. > http://www.doodle.com/h7bsbevbgvcwvx37Nice, thank you guys for the initiative! Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0xA0A0AAAA For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090725/12e6306c/attachment.pgp>
* Micah Anderson <micah at riseup.net> [2009-07-24 11:40-0400]:> * Nico Golde <debian-secure-testing+ml at ngolde.de> [2009-07-24 11:02-0400]: > > Hi, > > * Luciano Bello <luciano at debian.org> [2009-07-23 22:34]: > > > I''m at debconf9. Are any of you here too? > > > > Yes I am sitting in the hacklab currently. How many of s > > are/will be present? Does it make sense to schedule a > > BoF? I know at least Moritz is going to join us. Who else > > will be here? > > I''m here, Rhonda is here, Maulkin is here, some of the buildd, > ftp-master, RM folks are here (sgran, zobel, luk, aba, Ganneff, weasel, > others), and some people who have been involved in some capacity at some > point (madduck, joeyh... it could be very useful.So the doodle results are giving us a number of options, including 6 minutes ago. I think we should pass on that one, and instead schedule it a day or two from now so that everyone has some time to realize the situation. So, I''ll make unilateral decision that we will do this on the 29th at 4pm (16:00). I suspect that this is more intended to be a discussion amongst the involved security folks, rather than a general purpose BoF or presentation. However, would anyone have an objection to scheduling it on penta? That would mean other people would show up, which could be a distraction, or a recruiting opportunity, depending on how you see it. 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? micah -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090726/2f71533b/attachment.pgp>
Hi, * Micah Anderson <micah at riseup.net> [2009-07-26 15:24]:> * Micah Anderson <micah at riseup.net> [2009-07-24 11:40-0400]: > > * Nico Golde <debian-secure-testing+ml at ngolde.de> [2009-07-24 11:02-0400]:[...]> So the doodle results are giving us a number of options, including 6 > minutes ago. I think we should pass on that one, and instead schedule it > a day or two from now so that everyone has some time to realize the > situation. > > So, I''ll make unilateral decision that we will do this on the 29th at > 4pm (16:00).Great!> I suspect that this is more intended to be a discussion amongst the > involved security folks, rather than a general purpose BoF or > presentation. However, would anyone have an objection to scheduling it > on penta? That would mean other people would show up, which could be a > distraction, or a recruiting opportunity, depending on how you see it. > > 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. That''s what comes to my mind. Any other ideas? Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0xA0A0AAAA For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090726/209a265c/attachment.pgp>
>> 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)
On Sun, Jul 26, 2009 at 09:21:29PM +0200, Stefan Fritsch wrote:> - how to push for enabling more hardening compile options in > squeezeI think it should be done. All the patches are well tested in Ubuntu -- it just takes a tiny change to the gcc packaging (the patches are in the package, they just aren''t applied when building for Debian). I''ve chased any issues that they uncovered through the BTS and most maintainers were quick to fix problems. Some notes from the Ubuntu roll-out: https://wiki.ubuntu.com/CompilerFlags -Kees -- Kees Cook @debian.org
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@ ? Also, is there a chance that the BoF will be recorded? I''d be interested in seeing the video. Live stream could be too hard I guess :( Thanks to everyone for spending your holidays on security work. ;) Cheers Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090727/05f095d3/attachment-0001.pgp>
> * Micah Anderson <micah at riseup.net> [2009-07-24 11:40-0400]: > So, I''ll make unilateral decision that we will do this on the 29th at > 4pm (16:00).I have mailed schedule at debconf.org. Hopefully this is the right way to do it. Stefan
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
Hi, * Michael S. Gilbert <michael.s.gilbert at gmail.com> [2009-07-28 05:25]: [...]> i as well will not be at debconf, but i do have some thoughts that > may be interesting to bring up in your discussion: >[...]> - better tracking of non-numbered CVEs; using unique numbers instead of > XXXX so DSAs can be linked permanently (Florian suggested DSN-YYYYY)Not need to discuss this in my opinion, we need that, someone just needs to implement that :)> - 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.I talked to Don Armstrong yesterday about this, it''s on his todo list.> - 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 am not sure about execshield, the last thing I heard from grsecurity is http://grsecurity.net/news.php#grsec2112, not sure if the situation changed so far. Other than that, I think we should stick with easier to achieve goals like gcc compiler flags for security hardening first before rolling out such a huge patch.> - 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. >There is no 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.htmlTo be honest I know of none package other than flash in non-free which isn''t supported but also uses hashes to verify the files that uses that. There may be others but I am pretty sure they aren''t very widely in use.> - 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.I still disagree, if people got root on your system you almost always screwed. But no need to discuss this now on the list. Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0xA0A0AAAA For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090728/9b45f276/attachment.pgp>
On Mon, Jul 27, 2009 at 11:23:58PM -0400, Michael S. Gilbert wrote:> On Mon, 27 Jul 2009 12:05:35 +1000 Steffen Joeris wrote:> - 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?The NX emulation bits of exec_shield cannot be sensibly merged into the Debian kernel and the rest has been merged into mainline more or less. It''s only affecting legacy i386 CPUs anyway. Cheers, Moritz
El Lun 27 Jul 2009, Stefan Fritsch escribi?:> I have mailed schedule at debconf.org. Hopefully this is the right way to do it.It''s possible to avoid BoF room? It''s too hot, especially at that hour. luciano
On tiisdei 28 July 2009, Nico Golde wrote:> > 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 > > To be honest I know of none package other than flash in > non-free which isn''t supported but also uses hashes to > verify the files that uses that. There may be others but I > am pretty sure they aren''t very widely in use.msttcorefonts downloads font .cabs but checks their hash before extracting them. Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090728/cbbf205a/attachment.pgp>
2009/7/28 Luciano Bello <luciano at debian.org>:> El Lun 27 Jul 2009, Stefan Fritsch escribi?: >> I have mailed schedule at debconf.org. Hopefully this is the right way to do it. > > It''s possible to avoid BoF room? It''s too hot, especially at that hour.I think nobody is actually using BOF room really but leaves some trace (sheet of paper) where people assemble. If you find a spare slot in the schedule of one of the task rooms which fits better - just write to schedule at debconf.org and we try whyt we can do. Kind regards and thanls for your activity at DebConf Andreas. -- http://fam-tille.de