SearchSecurity.com: "Linux patch problems: Your distro may vary"

Hi,

I just stumbled over an article from SearchSecurity.com
which was linked to
in a heise newsticker posting that tries to analyze how fast
distributions
react to security vulnerabilities:

	http://tinyurl.com/lplfb

Quick chart:

	Rank Distro                    Points/100
	---- ------------------------- ----------
	1.   Ubuntu                    76
	2.   Fedora Core               70
	3.   Red Hat Enterprise Linux  63
	4.   Debian GNU/Linux          61
	5.   Mandriva Linux            54
	6.   Gentoo Linux              39
	7.   Trustix Secure Linux      32
	8.   SUSE Linux Enterprise     32
	9.   Slackware Linux           30

Rank 6 out of 10 is not a great result -- at least we beat
SUSE ;)

Any comments or thoughts about this?
Can we become better?
Are we maybe better than the author pretends?
Does the security team currently face serious problems that
need to be
solved, be it inside or outside the security team?

I am just curious and would be glad to get some feedback

-- 
Regards,
Wolfram Schlich <wschlichgentoo.org>
Gentoo Linux * http://dev.gentoo.or
g/~wschlich/
-- 
gentoo-securitygentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Interesting study.  I like the premise of it.  However, I'm
not sure I
agree with their method.  From the article:

"For instance, if a distribution fixed an issue on the
earliest date, it
would receive a score of 100 for that issue; if it was the
last vendor to
fix the issue, it would get a score of 0. One can then
average the scores
after evaluating the 30 issues."

So this is just a ranking, with no quantitative results. 
What I'd really
like to know are the distributions' average response times
for the High
and Moderate vulnerabilities.

While Gentoo might be 6th, I'd like to know how much slower
Gentoo gets
out patches than Ubuntu, Fedora, and/or RHEL.


- -Vince


- --
Vincent Rivellino
GPG Key ID: 62BFEBE4
https://cuz.cx/gpg


On Mon, August 7, 2006 07:42, Wolfram Schlich wrote:
> Hi,
>
>
> I just stumbled over an article from SearchSecurity.com
which was linked
> to in a heise newsticker posting that tries to analyze
how fast
> distributions react to security vulnerabilities:
>
> http://tinyurl.com/lplfb
>
>
> Quick chart:
>
>
> Rank Distro                    Points/100
> ---- ------------------------- ----------
> 1.   Ubuntu                    76
> 2.   Fedora Core               70
> 3.   Red Hat Enterprise Linux  63
> 4.   Debian GNU/Linux          61
> 5.   Mandriva Linux            54
> 6.   Gentoo Linux              39
> 7.   Trustix Secure Linux      32
> 8.   SUSE Linux Enterprise     32
> 9.   Slackware Linux           30
>
>
> Rank 6 out of 10 is not a great result -- at least we
beat SUSE ;)
>
>
> Any comments or thoughts about this?
> Can we become better?
> Are we maybe better than the author pretends?
> Does the security team currently face serious problems
that need to be
> solved, be it inside or outside the security team?
>
> I am just curious and would be glad to get some
feedback 
> --
> Regards,
> Wolfram Schlich <wschlichgentoo.org>
> Gentoo Linux * http://dev.gentoo.or
g/~wschlich/
> --
> gentoo-securitygentoo.org mailing list
>
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFE12eKhUAfdmK/6+QRAm4sAJ9U4hDbql8b5Du7ELWTclnBdwXONACg
hkRk
PLfad2L0hjQZ99puzngf4nU=
=/aSm
-----END PGP SIGNATURE-----

-- 
gentoo-securitygentoo.org mailing list

On Monday 07 August 2006 13:42, Wolfram Schlich wrote:
> Hi,
>
> I just stumbled over an article from SearchSecurity.com
which was linked to
> in a heise newsticker posting that tries to analyze how
fast distributions
> react to security vulnerabilities:
>
> 	http://tinyurl.com/lplfb
>
> Quick chart:
>
> 	Rank Distro                    Points/100
> 	---- ------------------------- ----------
> 	1.   Ubuntu                    76
> 	2.   Fedora Core               70
> 	3.   Red Hat Enterprise Linux  63
> 	4.   Debian GNU/Linux          61
> 	5.   Mandriva Linux            54
> 	6.   Gentoo Linux              39
> 	7.   Trustix Secure Linux      32
> 	8.   SUSE Linux Enterprise     32
> 	9.   Slackware Linux           30
>
> Rank 6 out of 10 is not a great result -- at least we
beat SUSE ;)
>
> Any comments or thoughts about this?
> Can we become better?
> Are we maybe better than the author pretends?
> Does the security team currently face serious problems
that need to be
> solved, be it inside or outside the security team?

comment?
yes.

I would like to know, if they counted until the patch/fix
was announced or 
until it was available?

If you are using unstable (~arch) you will get a lot of
fixes BEFORE they are 
announced. So when the nice 'packet FOO is vulnerable,
upgrade to FOO+1' 
arrives, you think 'gee.. I updated to FOO+1 two nights
ago....'.

So there is a difference between: fix is available for
unstable, fix is 
available for stable, fix is announced.

And I would like to know, which of the three got into that
'statistic'.
-- 
gentoo-securitygentoo.org mailing list

2006/8/7, Wolfram Schlich <listswolfram.schlich.org>:
> Hi,
>
> I just stumbled over an article from SearchSecurity.com
which was linked to
> in a heise newsticker posting that tries to analyze how
fast distributions
> react to security vulnerabilities:
>
>         http://tinyurl.com/lplfb
>
> Quick chart:
>
>         Rank Distro                    Points/100
>         ---- ------------------------- ----------
>         1.   Ubuntu                    76
>         2.   Fedora Core               70
>         3.   Red Hat Enterprise Linux  63
>         4.   Debian GNU/Linux          61
>         5.   Mandriva Linux            54
>         6.   Gentoo Linux              39
>         7.   Trustix Secure Linux      32
>         8.   SUSE Linux Enterprise     32
>         9.   Slackware Linux           30
>
> Rank 6 out of 10 is not a great result -- at least we
beat SUSE ;)
>
> Any comments or thoughts about this?
> Can we become better?
> Are we maybe better than the author pretends?
> Does the security team currently face serious problems
that need to be
> solved, be it inside or outside the security team?

Working with many distros - I have noticed only one minus of
gentoo -
emerge system. That's why gentoo is placed 6th...

-- 
Wojciech Ziniewicz            |  jid:zethchrome.pl
http://silenceproject.org       | http://zetho.wordpress.com

-- 
gentoo-securitygentoo.org mailing list

Hi there,

On Monday 07 August 2006 13:42, Wolfram Schlich wrote:
> Any comments or thoughts about this?
> Can we become better?
> Are we maybe better than the author pretends?
> Does the security team currently face serious problems
that need to be
> solved, be it inside or outside the security team?
>
> I am just curious and would be glad to get some
feedback 
I saw the article a few days back and here is a short
summary of what I think 
about it:

- I'm a bit disappointed with the result.

- The Security Team is short on staff so we're not as
speedy as we once 
was :-/

- The scores are not weighted to take severity into account.

- No exact references are given to the vulnerabilities in
question making it 
hard to check.

- Secunia release dates are not the same as Gentoo release
dates as Secunia 
seldom work during weekends.

- Unstable uses usually get the fix hours or even days
before the GLSA is 
issued.

- My own non-scientific research indicates that we're not
that bad compared to 
other community distributions like Debian (at least when you
compare the 
latest GLSAs with the high severity rating).

If you want to help out the Security Team and have some
relevant skills please 
consult the link in my signature or send me a private email.

-- 
Sune Kloppenborg Jeppesen (Jaervosz)
Operational Manager
Gentoo Linux Security Team
http://security.gentoo.org

Hi!

On Mon, Aug 07, 2006 at 10:11:23PM +0200, Sune Kloppenborg
Jeppesen wrote:
> - Unstable uses usually get the fix hours or even days
before the GLSA is 
> issued.

Why? I think security is important enough to force at least
SOME admins to
upgrade packet from current "stable, with security
hole" to "unstable, without
security hole"... but for this admins must know about
this security hole
as soon as fix for it become available, no matter in x86 or
~x86.

-- 
			WBR, Alex.

"Stefan Cornelius" <stefan.corneliusgmail.com> writes:

> The maintainer provides a new ebuild, but (s)he is not
allowed to
> stable of for any architecture, unless (s)he is a
member of that
> architecture team. So often you have a fixed ebuild
within the first
> day, but testing and stabling takes some time. (But
sometime, you
> also have to wait weeks for a patch. But that is
another story).
>
> If this is update is so important to admins, they are
welcome to
> monitor our bugzilla activity to get 0-sec
announcements of fixed
> ebuilds.

Another possibility is that the version in ~arch already has
the fix,
so that there might not be a new ebuild. There might be
other reasons,
such as dependencies on other ~arch packages, for a delay in
stabilising the version with the fix. In these cases it
would be
useful to have a security announcement stating the ~arch
version is
not vulnerable and giving the reasons why the package cannot
be made
stable in a timely manner. This would give the
administrators enough
information to make their own risk assessment as to whether
to upgrade to
the ~arch version (and all it dependencies) or keep running
the
vulnerable version until the fix is put into stable.
-- 
gentoo-securitygentoo.org mailing list

On Wednesday 09 August 2006 07:53, Eilverijus Kondratas
wrote:
> ) I don't think that this calculation can be used for
future
> planings: " what system will be better".
Statisticaly we should
> apply "z" or atleast "t"
statistics instead of simple average.
>
> Generaly speaking, calculations given in an article are
the simplest
> ones tought in primary school. I did not find anything
from
> advanced statistics according to which the rating could
be applied.

So, perhaps we should request the data-set from the authors
and apply some 
more (re)gressive statistics to the problem.

Regards,

  - Brian
-- 
gentoo-securitygentoo.org mailing list