Links/new content that may be useful to Fedora

[Silvio Cesare]

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/SecurityA...
.
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/NearestNe...
.
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

[Paul Howarth]

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.

[Tomas Hoger]

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/SecurityA...
> . 
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/NearestNe...
Out of curiosity, how should Similarity number be interpreted?

-- 
Tomas Hoger / Red Hat Security Response Team

[Silvio Cesare]

On Thu, Jan 6, 2011 at 6:10 AM, Tomas Hoger <thoger(a)redhat.com&gt; 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/NearestNe...
>
>  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