Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
[Henri Salo] > Has there been any progress with this project? I am glad to help if > there is something I can do? This is needed in my opinion. You could try to run the scripts I created in the debian-security svn repository, and see how they could be improved. I have not had time to work much on this issue for a long time, and this is unlikely to change any time soon. :( You can try to add CPE info to a few packages to test the proposal, and see if it make tracking easier. But first and foremost, you can try to figure out what need to be done to move the idea forward, as I lack the time to do so myself. :( If you want more direct feedback from me, we could meet on IRC to exchange knowledge. Otherwise, you can ask using email. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929203142.gf20...@ulrik.uio.no
Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
[Michael Gilbert] >> Are you aware of my proposal to do this, mentioned on debian-security >> and also drafted on http://wiki.debian.org/CPEtagPackagesDep >? > > Does this actually cover embedded code copies? The spec probably > needs to get something like an "XBS-Embeds-Source-From-CPE" tag for > that. I did not have embedded code copies in mind when I wrote the draft, but it would be handled by just listing both the upstream CPE and the embedded CPE separated with commas. > Even so, do you think maintainers are really going to go through the > trouble to keep these tags accurately populated? I suppose its worth > it to try, but I have my doubts. Inaccurate information can be worse > than no information. At least with embedded-code-copies, we have a > centralized record that's kept up to date by security-involved people. I suspect it will be done if we can provide mechanism that make it useful for the maintainers to include the CPE codes and keep them updated. One idea would be to automatically show all CVEs that might affect the package on the packages.qa.debian.org page, to make it easier to track security issues. I hope to come up with other and perhaps better ideas to motivate people to provide CPE codes with the packages. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702215911.gd32...@ulrik.uio.no
Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
[Silvio Cesare] > I recently ran the tool and cross referenced identified code copies with > Debian's security tracking of affected packages by CVE. I did this for all > CVEs in 2010, 2011, and 2012. This sound like a job that could become a bit easier if we tagged Debian packages with the CPE ids assosiated with CVEs, to make it easier to figure out which Debian package are affected by a given CVE. Are you aware of my proposal to do this, mentioned on debian-security and also drafted on http://wiki.debian.org/CPEtagPackagesDep >? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fly5n2kps1@login1.uio.no
Re: When are security updates effective?
[Dann Frazier] > Would this help? > http://lists.debian.org/debian-devel/2006/08/msg00629.html Getting all packages requiring an reboot to call /usr/share/update-notifier/notify-reboot-required or touch /var/run/reboot-required would definitely be a step in the right direction, and handle kernel upgrades quite well. I like that part of the proposal. But for user applications, it would be enough to log out and in again, and that should be handled too. And it will get more complicated for multiuser machines (like LTSP thin clients or multiseat installations), where each logged in user need to log out. So each users session need to keep track of when he logged in and check if some changes requiring a logout has happened since then. Should not be too hard, though. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SELinux
[David Pastern] > Interesting question. Sadly, for a long, long while, the > development process of Debian has been slower than a dead snail > nailed to the floor. As a participant in that process, I have not had that experience. > The inability, or indecision to actually include new technologies > seems to be highly present across Debian itself. Strange, never had that experience either. :) > That said - when Debian implements things, it usually implements > them a helluva lot better than other distributions. We will see. sysvinit got SELinux support a few days ago. a lot of SELinux related packages was uploaded recently as well, and I believe several if not most of the packages in need to patches to work with SELinux are already in the debian archive with these patches included. I suspect what is needed, is someone working focused on fixing the remaining issues, and making sure everything work as it should. The mechanism is almost ready, now we need to tune it to work out of the box. For example, it would be great if someone used the usertags mechanism to flag all the SELinux related bugs in BTS, to make it easier to track what issues remain to be fixed before SELinux work out of the box in sid and etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad press again...
[Frans Pop] > IMO the status of the security team is not changed by that mail: if > it was delegated before that time, it still is, and similar if it > was not. Personally, I only find it reasonable that all groups in Debian with special privileges within the Debian community are delegates. It avoid the danger of small kings of the hill protecting their turf from contributions and improvements. Here at the university, I've seen way to many professors and system administrators trying their best to avoid improvements and change by protecting their turf in innovative ways, to believe that Debian will be protected from the same problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad press again...
[Martin F Krafft] >> And prospective security team members should start working in the >> testing security team. There are no need to keep secrets (all is done >> in public), > > Which doesn't address the problem that embargoed bugs are possibly > handled suboptimally in Debian. > > And it does not address the problem that our security infrastructure > went down for a while and we found out about it from a German news > magazine. True, it does not address those problems, and we should try to address them. But it does address other related problems, and we will be a lot better of if all the _public_ security issues in debian were solved, and having a proven security framework for testing and unstable might make it easier to adjust the framework used for stable to make it better. If all the public issues are solved, I believe it is easier to address the handling of non-public ones. In short, I see no downsides to helping out the testing security team while we at the same time try to address the issues with stable security work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad press again...
[Florian Weimer] > Correct me if I'm wrong, but the current team doesn't seem to want > new members. I've been told that the current stable security team consist of one person doing the work, Martin Schulze. If this "team" do not want new members, something strange is afoot. And prospective security team members should start working in the testing security team. There are no need to keep secrets (all is done in public), and enough work for several people (just check out http://spohr.debian.org/~joeyh/testing-security.html> :), and it is a good place to demonstrate ones capacity in this area. :) Total holes unfixed: 93 Total holes fixed in unstable but not testing: 135 (+3 on some arches) Total number of kernel image packages not up to date: 0 Number of TODO lines in records: 153 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad press again...
[Florian Weimer] > I don't think so. Joey seems to be satisfied with this situation, > and apart from unanswered email messages to <[EMAIL PROTECTED]>, > there are few complaints, AFAIK. I'm not sure if the satisfaction of Martin Schulze is a good measuring stick to judge the quality of the stable security work. The count of open security issues in stable and oldstable is probably a better measuring meter, and it does not look too good. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
security hole in sshd in oldstable?
Are there known security holes in sshd in oldstable (woody)? Yesterday, I was told that one of the machines I administrate were rooted, and that this was the springboard used to crack the reporters machine. He was told this on IRC by the person claiming to do the breakin. The person breaking in also said the way in was through sshd. The machine I administrate run debian/woody, and uses sshd 3.4p1-1.woody.3. Are there known remotely exploitable security holes in this version? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
[Noah Meyerhans] >> How about actually maintaining them? > > That's exactly what I think we should do. Is this "we" as in you, or "we" as in someone else? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Security Support in Place
[Sven 'Rae the Git' Grounsell] > Also, you are IMHO ignoring, that Debian is one of the _very_ few > distros, that provides _seamless_ upgrades between even major > releases. This is a slight exaggeration, as this do not really work very seamlessly for packages where the configuration was changed. I get a lot of conffile questions during upgrades when trying to upgrade my woody servers to sarge, and I would not call that seamless. And for desktops, I ran into several problems with the package selection when upgrading. apt-get and aptitude wanted to remove several of the packages instead instead of upgrading them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Security Support in Place
[Martin Wodrich] >> IIRC security-support for sarge started befor its release. > > But only one month before the release. That depends on your definition of support. The testing security team was working hard to secure it a long time before sarge was released. http://secure-testing.alioth.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad press related to (missing) Debian security - action
[Alvin Oga] > i don't want any handholding ... other than access the the resources > and info and/or question answer .. > - in my case, i'd like to create test-sec.debian.org > for which i cannot do anything about it unless i do get > some handholding and it's purpse to supplement the security > patches that i see is lacking in "testing" > ( 2 or 3 months behind current releases is too far back for me ) Everybody have access to the resources used by the testing security team. If you start submitting updates there, I am sure your effort will have positive effect. There is no reason for you to wait for a debian.org domain name. If you want a new APT repository, you can create it anywhere, and if it proves to be a good idea it can be made available as test-sec.debian.org or something similar some time in the future. The information about the testing security team is available from http://secure-testing.alioth.debian.org/>, and the subversion repository used to track security issues is publicly available. Patch submission into BTS can be done by anyone, and NMUs can be prepared by anyone for review and upload by any Debian developer. I am convinced several of the Debian developers in the testing security team are willing to do uploads. And, when the issue is completely investigated and the patch is available, the work left for the stable security team will be much reduced. :) So, no need to wait, just go ahead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
