Re: Gaps in security coverage?
On Mon, 2018-11-05 at 20:52 -0600, John Goerzen wrote: > That is good advice, thanks. I've been a DD for a long while, but it's > been awhile (years) since I've been involved in the security process and > wasn't quite sure what the flow was anymore. It is still mostly the same but the security team try to distribute more work to the package maintainers especially for unstable. > What kind of automated sources are you talking about here? Where do I > find the source that might be relevant? I might be able to pitch in > here. Basically if you follow the manual commits to the security tracker repo and think about how to automate each commit. The Mitre CVE data is automatically imported but there are various sources of non-CVE data or per-project data that has lower latency. I wrote down some possible sources of data in check-external/sources.ini but never got around to going further and the security team didn't seem to like the idea at all so I've basically dropped it for now. Also, a much more important task is restructuring the git repo so that it doesn't cause responsiveness and resource usage issues with salsa. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Gaps in security coverage?
On Tue, Nov 06 2018, Paul Wise wrote: > On Mon, Nov 5, 2018 at 10:29 PM John Goerzen wrote: > >> Hi folks, > > FTR, in case you were trying to contact the Debian Security Team > directly I suggest using secur...@debian.org or > t...@security.debian.org instead, debian-security is more of a general > security discussion list than a Debian Security Team list. Hi Paul, Thanks - I did intend it to go here, understanding that difference; I had no particular reason to make it more private. [ snips ] > Personally, I think running debsecan, looking at each item, pinging > bug reports and maintainers, doing stable updates and unstable NMUs, > pushing patches upstream etc would be a great help. That is good advice, thanks. I've been a DD for a long while, but it's been awhile (years) since I've been involved in the security process and wasn't quite sure what the flow was anymore. > Also, debsecan itself could use a lot of help, the maintenance of it > and addition of new features currently falls on already-busy security > team folks. > > In addition some more automation of ingestion of security info into > the security tracker would free up security team time that is > currently spent on manually updating the security-tracker data. What kind of automated sources are you talking about here? Where do I find the source that might be relevant? I might be able to pitch in here. Thanks again, John
Re: Gaps in security coverage?
On Mon, Nov 5, 2018 at 10:29 PM John Goerzen wrote: > Hi folks, FTR, in case you were trying to contact the Debian Security Team directly I suggest using secur...@debian.org or t...@security.debian.org instead, debian-security is more of a general security discussion list than a Debian Security Team list. > So I recently started running debsecan on one of my boxes. It's a > fairly barebones server install, uses unattended-upgrades and is fully > up-to-date. I expected a clean bill of health, but didn't get that. I > got pages and pages and pages of output. Some of it (especially kernel > related) I believe may be false positives, but not all. Some of it > simply isn't patched yet. That has been the normal state of things since I started running debsecan many many years ago. > Diving into it a bit, it seems that somehow we fell down a bit with > stretch. The first hit on my list is this one: > > https://security-tracker.debian.org/tracker/CVE-2011-5325 > > Marked fixed in jessie, vulnerable in stretch. And indeed when looking > at the bug report 802702, I don't see any such changelog entries > pertaining to this in my stretch version. You can see at the bottom of this issue: [stretch] - busybox (Minor issue) This means that the security team determined it is not an important enough issue for them to fix in stable, but the maintainer could still fix it in a point release if they cared. > 1) Is this a symptom of a bad process or of not enough volunteers? In > other words, could we have marked these security bugs fixed in jessie as > RC for stretch somehow until they were also fixed there? I would guess mostly a lack of volunteers and also we need to give package maintainers more responsibility for fixing the issues. > 2) Is there a need for more help with security in general? If so, what > kinds of volunteering would be appreciated? First rule of FLOSS (that also applies to Debian): more help is needed in almost every area of almost every project. >From the help Debian page: https://www.debian.org/intro/help You can help track, find and fix security issues within the packages in Debian. https://security-tracker.debian.org/tracker/data/report https://www.debian.org/security/audit/ https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security You can also help harden packages, repositories and images and other things. https://wiki.debian.org/Hardening https://wiki.debian.org/Hardening/RepoAndImages https://wiki.debian.org/Hardening/Goals Personally, I think running debsecan, looking at each item, pinging bug reports and maintainers, doing stable updates and unstable NMUs, pushing patches upstream etc would be a great help. Also, debsecan itself could use a lot of help, the maintenance of it and addition of new features currently falls on already-busy security team folks. In addition some more automation of ingestion of security info into the security tracker would free up security team time that is currently spent on manually updating the security-tracker data. -- bye, pabs https://wiki.debian.org/PaulWise
Gaps in security coverage?
Hi folks, So I recently started running debsecan on one of my boxes. It's a fairly barebones server install, uses unattended-upgrades and is fully up-to-date. I expected a clean bill of health, but didn't get that. I got pages and pages and pages of output. Some of it (especially kernel related) I believe may be false positives, but not all. Some of it simply isn't patched yet. Diving into it a bit, it seems that somehow we fell down a bit with stretch. The first hit on my list is this one: https://security-tracker.debian.org/tracker/CVE-2011-5325 Marked fixed in jessie, vulnerable in stretch. And indeed when looking at the bug report 802702, I don't see any such changelog entries pertaining to this in my stretch version. So, the questions - 1) Is this a symptom of a bad process or of not enough volunteers? In other words, could we have marked these security bugs fixed in jessie as RC for stretch somehow until they were also fixed there? 2) Is there a need for more help with security in general? If so, what kinds of volunteering would be appreciated? Thanks, John
