Hi, * Michael S. Gilbert <michael.s.gilb...@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.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. > - 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 - n...@jabber.ccc.de - GPG: 0xA0A0AAAA For security reasons, all text in this mail is double-rot13 encrypted.
pgpXVPqb6psEq.pgp
Description: PGP signature
_______________________________________________ Secure-testing-team mailing list Secure-testing-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team