Hi, I am a PhD student at Deakin University. I am also a recent member to the Debian testing security team. As part of my research I have been looking at Linux security.
Debian maintain a security tracker http://security-tracker.debian.org/tracker/ . I think RHEL maintains security tracking but I do not know the details. Fedora as far as I know do not publicly and actively maintain security tracking once an advisory is released.
A simple report I generated last year was tracking of packages and the CVEs that they reference in an advisory. I did that by scraping the public mailing list archive of advisories/updates and grepping for CVE references. I have made a report from last year publicly available https://github.com/silviocesare/Privileged-Programs/blob/master/SecurityAdvi... . This might be useful on the Fedora wiki.
A report I made of Debian's SUID/SGID programs from all packages in the repository is here https://github.com/silviocesare/Privileged-Programs/tree/master/Debian5.05 . I suspect Fedora already has such a list in line with the Fedora 15 target of removing SUID/SGID programs from the distribution.
Another report I made which may or may not be useful to the security team is a list of packages between Debian and Fedora that are roughly equivalent, irrespective of what the package names are https://github.com/silviocesare/Equivalent-Packages/blob/master/NearestNeigh... . There are some false positives and false negatives due to the fact that the list is automatically generated. This equivalent packages list might be useful on the Fedora wiki even if it's not a fit in the security section. I will do another report for Fedora 14 against more Linux distributions if there is interest.
These links are just small things I've been working on, but I hope someone in the Fedora project may find them useful. I should also note that this work is all rather preliminary for now.
Please CC me on responses and if there is a more active or appropriate forum to raise these types of discussions then please advise.
-- Silvio Cesare Deakin University
On 04/01/11 08:11, Silvio Cesare wrote:
Hi, I am a PhD student at Deakin University. I am also a recent member to the Debian testing security team. As part of my research I have been looking at Linux security. Debian maintain a security tracker http://security-tracker.debian.org/tracker/ . I think RHEL maintains security tracking but I do not know the details. Fedora as far as I know do not publicly and actively maintain security tracking once an advisory is released.
Security issues are usually tracked in bugzilla, with the ticket for each issue aliased to its CVE number when known, e.g.:
http://bugzilla.redhat.com/CVE-2010-4221
Cheers, Paul.
On Tue, 4 Jan 2011 19:11:16 +1100 Silvio Cesare wrote:
I think RHEL maintains security tracking but I do not know the details.
There are per-product errata listing pages available on Red Hat Network and can be accessed without having to log in via: https://rhn.redhat.com/errata/
You can also list all errata for specific CVE id by accessing URL as: https://rhn.redhat.com/errata/CVE-20XX-YYYY.html
CVE pages aim to combine released errata info with additional info (bug link, impact rating and scoring, possible statements) at the single place: https://www.redhat.com/security/data/cve/
Fedora as far as I know do not publicly and actively maintain security tracking once an advisory is released.
Bodhi search can be used to locate updates referencing specific CVE id, assuming it was assigned at the time update was released. E.g. example for CVE-2010-4221 that Paul used: https://admin.fedoraproject.org/updates/search/CVE-2010-4221
Update system does not allow changing CVE list for update requests. All info about released updates is usually removed form Bodhi shortly after Fedora version EOL. So unlike RHN, you won't find there info on EOLed versions.
A simple report I generated last year was tracking of packages and the CVEs that they reference in an advisory. I did that by scraping the public mailing list archive of advisories/updates and grepping for CVE references. I have made a report from last year publicly available https://github.com/silviocesare/Privileged-Programs/blob/master/SecurityAdvi... .
I suspect this list is likely to be affected by this issue: https://fedorahosted.org/bodhi/ticket/351
Update system allows referencing multiple builds in one update request, but when such request to turned to email notifications, there's separate mail sent for each build. Firefox updates are good example, as they usually contain half dozen of builds or more (firefox + xulrunner, and bunch of apps using gecko libs that required rebuild).
This might be useful on the Fedora wiki.
Such list is going to get outdated soon. Tools that can be used to re-generate the list may be more useful to those that want to do similar stats.
Another report I made which may or may not be useful to the security team is a list of packages between Debian and Fedora that are roughly equivalent, irrespective of what the package names are https://github.com/silviocesare/Equivalent-Packages/blob/master/NearestNeigh...
Out of curiosity, how should Similarity number be interpreted?
On Thu, Jan 6, 2011 at 6:10 AM, Tomas Hoger thoger@redhat.com wrote:
Another report I made which may or may not be useful to the security team is a list of packages between Debian and Fedora that are roughly equivalent, irrespective of what the package names are
https://github.com/silviocesare/Equivalent-Packages/blob/master/NearestNeigh...
Out of curiosity, how should Similarity number be interpreted?
I compare the contents of source packages between distributions. The more similar the source packages the higher the similarity. If the sources are identical, then the similarity is 1, if they are completely unrelated the similarity is 0.
This is how equivalent packages can be determined irrespective of the package names - based on similarity between their sources. A threshold is set to say if two packages are equivalent based on their similarity.
I added some more content yesterdyay in the git repo to show similarity between packages within a distribution. This could be useful to find otherwise duplicated sources - a seperate source package could be created that is made common to the two highly similar packages. I haven't really gone down that track before, so take it for what you may..
--
Tomas Hoger / Red Hat Security Response Team
-- Silvio
security@lists.fedoraproject.org
-
Paul Howarth -
Silvio Cesare -
Tomas Hoger