[Secure-testing-team] debconf9

[Nico Golde]

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.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 - 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>