[gentoo-security] No GLSA since January?!?

[gentoo-security] No GLSA since January?!?

[Christian Kauhaus]

Hi,

I'm wondering that may favorite Linux distro hasn't had any security 
announcements since January. In my opinion this is really problematic. At our 
company we try to convince prospective customers to host their applications on 
our Gentoo servers. When asked about security incident handling, I have to 
say: "They state 'Security is a primary focus' on their website, but they 
don't inform their users." Not very convincing.

So what is the roadblock that hinders GLSA creation? Is there any way to get 
the GLSAs into working order again?

Regards

Christian

-- 
Dipl.-Inf. Christian Kauhaus <>< · kc@gocept.com · systems administration
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
Zope and Plone consulting and development

Re: [gentoo-security] No GLSA since January?!?

[Christoph Jasinski]

Dear Christian

Everything is secure. No reason to write GLSAs or to panic. ;)


Chris

Am 26.08.2011 um 18:12 schrieb Christian Kauhaus:

> Hi,
> 
> I'm wondering that may favorite Linux distro hasn't had any security announcements since January. In my opinion this is really problematic. At our company we try to convince prospective customers to host their applications on our Gentoo servers. When asked about security incident handling, I have to say: "They state 'Security is a primary focus' on their website, but they don't inform their users." Not very convincing.
> 
> So what is the roadblock that hinders GLSA creation? Is there any way to get the GLSAs into working order again?
> 
> Regards
> 
> Christian
> 
> -- 
> Dipl.-Inf. Christian Kauhaus <>< · kc@gocept.com · systems administration
> gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
> http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
> Zope and Plone consulting and development
> 

Re: [gentoo-security] No GLSA since January?!?

[JD Horelick]

On 26 August 2011 12:43, Christoph Jasinski <Krzysiek@gmx.net> wrote:
> Dear Christian
>
> Everything is secure. No reason to write GLSAs or to panic. ;)
>
>
> Chris
>
> Am 26.08.2011 um 18:12 schrieb Christian Kauhaus:
>
>> Hi,
>>
>> I'm wondering that may favorite Linux distro hasn't had any security announcements since January. In my opinion this is really problematic. At our company we try to convince prospective customers to host their applications on our Gentoo servers. When asked about security incident handling, I have to say: "They state 'Security is a primary focus' on their website, but they don't inform their users." Not very convincing.
>>
>> So what is the roadblock that hinders GLSA creation? Is there any way to get the GLSAs into working order again?
>>
>> Regards
>>
>> Christian
>>
>> --
>> Dipl.-Inf. Christian Kauhaus <>< · kc@gocept.com · systems administration
>> gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
>> http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
>> Zope and Plone consulting and development
>>
>
>
>

I'm sorry, but I disagree with that. I've been an (unofficial) x86
Archtester for only 2 weeks or so and since then, i've seen more than
a few stabilizations needed to address security issues. Also, i've
noticed this same problem of not seeing many/any GLSA's in recent
history. As an example, in the past month, Debian has had 13 security
advisories. I personally doubt that we (Gentoo) don't have to worry
about ANY of those 13 advisories...

Re: [gentoo-security] No GLSA since January?!?

[Daniel A. Avelino]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

Alex.

May be a call for volunteers more "intense" could improve the manpower. This
could be a more
easy start point to address, no?.
I work too in some [smaller] security processes and can figure out what kind
of work are you talking about.

As Kauhaus pointed, may be somethings should be automated but again, this is
a hard job to
implement and to keep results trustable.

I'd started following this list recently and yet does not know how
work fluxes are performed here but, may be, this could be a good place to
start a review of GLSA processes, what
do you think about this?


Regards,


Daniel A. Avelino

I thought its time

On Fri, Aug 26, 2011 at 1:57 PM, JD Horelick <jdhore1@gmail.com> wrote:

> On 26 August 2011 12:43, Christoph Jasinski <Krzysiek@gmx.net> wrote:
> > Dear Christian
> >
> > Everything is secure. No reason to write GLSAs or to panic. ;)
> >
> >
> > Chris
> >
> > Am 26.08.2011 um 18:12 schrieb Christian Kauhaus:
> >
> >> Hi,
> >>
> >> I'm wondering that may favorite Linux distro hasn't had any security
> announcements since January. In my opinion this is really problematic. At
> our company we try to convince prospective customers to host their
> applications on our Gentoo servers. When asked about security incident
> handling, I have to say: "They state 'Security is a primary focus' on their
> website, but they don't inform their users." Not very convincing.
> >>
> >> So what is the roadblock that hinders GLSA creation? Is there any way to
> get the GLSAs into working order again?
> >>
> >> Regards
> >>
> >> Christian
> >>
> >> --
> >> Dipl.-Inf. Christian Kauhaus <>< · kc@gocept.com · systems
> administration
> >> gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
> >> http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
> >> Zope and Plone consulting and development
> >>
> >
> >
> >
>
> I'm sorry, but I disagree with that. I've been an (unofficial) x86
> Archtester for only 2 weeks or so and since then, i've seen more than
> a few stabilizations needed to address security issues. Also, i've
> noticed this same problem of not seeing many/any GLSA's in recent
> history. As an example, in the past month, Debian has had 13 security
> advisories. I personally doubt that we (Gentoo) don't have to worry
> about ANY of those 13 advisories...
>
>

[-- Attachment #2: Type: text/html, Size: 3255 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

On Friday 26 August 2011 14:18:20 Daniel A. Avelino wrote:
> Alex.
> 
> May be a call for volunteers more "intense" could improve the manpower. This
> could be a more
> easy start point to address, no?.

Well, the staffing needs page IS the point for making such calls. It's not 
that we haven't had people contacting us about helping, it's that they usually 
disappear shortly after that again after they've seen the tasks at hand.

> I work too in some [smaller] security processes and can figure out what kind
> of work are you talking about.
> 
> As Kauhaus pointed, may be somethings should be automated but again, this is
> a hard job to
> implement and to keep results trustable.
> 

Automation is a key thing I've been introducing in the new tools and processes 
for sending advisories.
I'd rather not focus on a temporary automated system however, knowing that 
we're about to get back to the/near the status quo.

> I'd started following this list recently and yet does not know how
> work fluxes are performed here but, may be, this could be a good place to
> start a review of GLSA processes, what
> do you think about this?

You can find the relevant info on our websites [1]

The thing is, the basic idea cannot be changed. We will always have a flow 
issue -> bug -> fix -> stabling -> advisory.

Specifically, the current goal is, to have the advisory drafting starting 
earlier and using the information we've already entered into our bugzilla and 
CVE tracker in a much more integrated way. It's a bit hard to explain, you'd 
best see for yourself (by joining us of course! ;)). 

Alex

[1] http://www.gentoo.org/proj/en/security/

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security / Ruby

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Daniel A. Avelino]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Fri, Aug 26, 2011 at 2:57 PM, Alex Legler <a3li@gentoo.org> wrote:

> On Friday 26 August 2011 14:18:20 Daniel A. Avelino wrote:
> > Alex.
> >
> > May be a call for volunteers more "intense" could improve the manpower.
> This
> > could be a more
> > easy start point to address, no?.
>
> Well, the staffing needs page IS the point for making such calls. It's not
> that we haven't had people contacting us about helping, it's that they
> usually
> disappear shortly after that again after they've seen the tasks at hand.
>
> I know how it works!


> > I work too in some [smaller] security processes and can figure out what
> kind
> > of work are you talking about.
> >
> > As Kauhaus pointed, may be somethings should be automated but again, this
> is
> > a hard job to
> > implement and to keep results trustable.
> >
>
> Automation is a key thing I've been introducing in the new tools and
> processes
> for sending advisories.
> I'd rather not focus on a temporary automated system however, knowing that
> we're about to get back to the/near the status quo.
>
> When I think about automation, I had in mind something that could help
developers to find
vulnerabilities in a more fast way [searching and confronting CVE, for
example] and  start a
"call for solution" process. I work with solutions of this type for WEB
vulnerabilities discover
and some tools are very interesting to reduce the correction time.

By the way, I will start to read about what a Padawan should know instead of

make speculations prematurelly. :D

Thank you very much for the explanations.

Daniel A. Avelino

[-- Attachment #2: Type: text/html, Size: 2262 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Friday 26 August 2011 15:22:40 Daniel A. Avelino wrote:
> > When I think about automation, I had in mind something that could help
> 
> developers to find
> vulnerabilities in a more fast way [searching and confronting CVE, for
> example] and  start a
> "call for solution" process. I work with solutions of this type for WEB
> vulnerabilities discover
> and some tools are very interesting to reduce the correction time.
> 

We already use CVE as one of our sources of vulnerability intelligence. 
Finding issues is also not the real issue here.
Also, actual issue correction is not our job, it's the responsibility of the 
package maintainer.

Can you share details about the utilities you are using?

Alex

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security / Ruby

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Daniel A. Avelino]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

Alex.

For WEB vulnerability discovering, one of the most important to us is Nessus
to
search and confronting against CVE database. Sometimes, Nessus find some
vulnerable packages in our Gentoo boxes and when we go to emerge -UDN this,
there is not the updated version even when the fixes are available [in other
distros
for example].

The Core Impact

http://www.coresecurity.com/

do a great job too but we only tested the demo version. [That is great too].

There is other interesting tool [not really WEB related but...] the Secunia
PSI

http://secunia.com/vulnerability_scanning/online/

that do a great job in search unupdated packages but Windows only.

Reading your last answer, I had the impression we are talking about
different things but I think
I can connect them. My apologies to speculate without read the complete team
work documentation
but even if issue correction is not our job as you said, I think we could
pressure package maintainers
to update its packages since we (in thesis) have more visibility about
packages vulnerabilities that can be fixed but
aren't fixed yet. This could be impact even in GLSA's update for example.

So, if we have a automatic mechanism that searchs into vulnerabilities
databases - CVE - for example and find what
packages have issues that was already fixed, we could, for example, label
packages
with some flag that tells users and developers that this package needs
review to fix some vulnerability.

I thought this is an interesting point to discuss because this could in
principle force updates to be more
fast and more Bugzilla-free. I have nothing against Bugzilla but the process
as a whole takes too much time
and we could in principle search vulnerabilities databases and provide
developers and users with informations
about how their systems security are.

Thanks again.

Daniel

On Fri, Aug 26, 2011 at 3:44 PM, Alex Legler <a3li@gentoo.org> wrote:

> On Friday 26 August 2011 15:22:40 Daniel A. Avelino wrote:
> > > When I think about automation, I had in mind something that could help
> >
> > developers to find
> > vulnerabilities in a more fast way [searching and confronting CVE, for
> > example] and  start a
> > "call for solution" process. I work with solutions of this type for WEB
> > vulnerabilities discover
> > and some tools are very interesting to reduce the correction time.
> >
>
> We already use CVE as one of our sources of vulnerability intelligence.
> Finding issues is also not the real issue here.
> Also, actual issue correction is not our job, it's the responsibility of
> the
> package maintainer.
>
> Can you share details about the utilities you are using?
>
> Alex
>
> --
> Alex Legler <a3li@gentoo.org>
> Gentoo Security / Ruby

[-- Attachment #2: Type: text/html, Size: 3401 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

On Friday 26 August 2011 18:12:00 Christian Kauhaus wrote:
> Hi,
> 
> I'm wondering that may favorite Linux distro hasn't had any security
> announcements since January. In my opinion this is really problematic. At
> our company we try to convince prospective customers to host their
> applications on our Gentoo servers. When asked about security incident
> handling, I have to say: "They state 'Security is a primary focus' on their
> website, but they don't inform their users." Not very convincing.
> 

That's the issue with an all-volunteer team. We lost some active members and 
with that quite some momentum. The remainder of the team currently focuses on 
getting issues fixed, which actually works quite well. Users who are watching 
our alias in Bugzilla were informed about all updates.

Making advisories with the available tool and process set was very time-
intensive, I've been working on making that drafting process faster. The goal 
we currently have is to wrap up the pending advisories in September with a few 
large grouped advisories and resume sending advisories after that as usual.

Compared to other distributions, our advisories have been rather detailed with 
lots of manually researched information. I'm not sure if we can keep up this 
very high standard with the limited manpower, but we'll try our best.

For quite some time now, there has also been a staffing request on the 
website, with low-to-medium success (yielding 1 new team member). Most people 
interested didn't think the job came with that much boring work. (No, we're 
not hacking stuff all day)

> So what is the roadblock that hinders GLSA creation? Is there any way to get
> the GLSAs into working order again?

tl;dr: Get more people to do boring work.

Alex

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security / Ruby

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Christian Kauhaus]

Am 26.08.2011 18:55, schrieb Alex Legler:
> Compared to other distributions, our advisories have been rather detailed with
> lots of manually researched information. I'm not sure if we can keep up this
> very high standard with the limited manpower, but we'll try our best.

I see the point. I think it would be an achievement over the current situation 
(which is: no current GLSAs at all) to send out less detailed GLSAs. Even 
something short as: "$PACKAGE has vulnerabilities, they are fixed in $VERSION, 
for details see $CVE" would be immensely helpful.

Is the any viable way to get it at least to this point? Probably the largest 
part of such a task could be automated. This would lift the burden from the 
security maintainers.

Regards

Christian

-- 
Dipl.-Inf. Christian Kauhaus <>< · kc@gocept.com · systems administration
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
Zope and Plone consulting and development

Re: [gentoo-security] No GLSA since January?!?

[Joost Roeleveld]

On Friday, August 26, 2011 07:06:35 PM Christian Kauhaus wrote:
> Am 26.08.2011 18:55, schrieb Alex Legler:
> > Compared to other distributions, our advisories have been rather
> > detailed with lots of manually researched information. I'm not sure if
> > we can keep up this very high standard with the limited manpower, but
> > we'll try our best.
> I see the point. I think it would be an achievement over the current
> situation (which is: no current GLSAs at all) to send out less detailed
> GLSAs. Even something short as: "$PACKAGE has vulnerabilities, they are
> fixed in $VERSION, for details see $CVE" would be immensely helpful.
> 
> Is the any viable way to get it at least to this point? Probably the largest
> part of such a task could be automated. This would lift the burden from the
> security maintainers.

I agree on this.
I don't (yet) know enough to actually help in this. I tend to follow 
advisories and try to keep my machines as much up-to-date as possible.

More brief GSLAs like what Christian mentioned are, for the majority, 
sufficient. If someone really needs more information, there is always google.

Maybe only list if it's a "local-only" exploit, eg. if local shell-access 
needs to be available already, or if it's also usable to abuse from remote. 
The latter being more troublesome as there are no valid user-accounts on my 
server and I trust all my users (me and my wife).

--
Joost

Re: [gentoo-security] No GLSA since January?!?

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

On Friday 26 August 2011 20:00:15 Joost Roeleveld wrote:
> On Friday, August 26, 2011 07:06:35 PM Christian Kauhaus wrote:
> > Am 26.08.2011 18:55, schrieb Alex Legler:
> > > Compared to other distributions, our advisories have been rather
> > > detailed with lots of manually researched information. I'm not sure
> > > if
> > > we can keep up this very high standard with the limited manpower,
> > > but
> > > we'll try our best.
> > 
> > I see the point. I think it would be an achievement over the current
> > situation (which is: no current GLSAs at all) to send out less detailed
> > GLSAs. Even something short as: "$PACKAGE has vulnerabilities, they are
> > fixed in $VERSION, for details see $CVE" would be immensely helpful.
> > 
> > Is the any viable way to get it at least to this point? Probably the
> > largest part of such a task could be automated. This would lift the
> > burden from the security maintainers.
> 
> I agree on this.
> I don't (yet) know enough to actually help in this. I tend to follow
> advisories and try to keep my machines as much up-to-date as possible.
> 
> More brief GSLAs like what Christian mentioned are, for the majority,
> sufficient. If someone really needs more information, there is always
> google.
> 

Like I said, please use Bugzilla and some basic filtering to get notifications 
until we can provide full advisories again. I realize it's not a solution and 
you will get the information somewhat unfiltered, but it is a reliable and 
most importantly currently available source of information.

Alex

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security / Ruby

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Joost Roeleveld]

On Friday, August 26, 2011 08:07:57 PM Alex Legler wrote:
> On Friday 26 August 2011 20:00:15 Joost Roeleveld wrote:
> > On Friday, August 26, 2011 07:06:35 PM Christian Kauhaus wrote:
> > > Am 26.08.2011 18:55, schrieb Alex Legler:
> > > > Compared to other distributions, our advisories have been rather
> > > > detailed with lots of manually researched information. I'm not
> > > > sure
> > > > if
> > > > we can keep up this very high standard with the limited
> > > > manpower,
> > > > but
> > > > we'll try our best.
> > > 
> > > I see the point. I think it would be an achievement over the current
> > > situation (which is: no current GLSAs at all) to send out less
> > > detailed
> > > GLSAs. Even something short as: "$PACKAGE has vulnerabilities, they
> > > are
> > > fixed in $VERSION, for details see $CVE" would be immensely helpful.
> > > 
> > > Is the any viable way to get it at least to this point? Probably the
> > > largest part of such a task could be automated. This would lift the
> > > burden from the security maintainers.
> > 
> > I agree on this.
> > I don't (yet) know enough to actually help in this. I tend to follow
> > advisories and try to keep my machines as much up-to-date as possible.
> > 
> > More brief GSLAs like what Christian mentioned are, for the majority,
> > sufficient. If someone really needs more information, there is always
> > google.
> 
> Like I said, please use Bugzilla and some basic filtering to get
> notifications until we can provide full advisories again. I realize it's
> not a solution and you will get the information somewhat unfiltered, but it
> is a reliable and most importantly currently available source of
> information.
> 
> Alex

Alex,

If my reply seemed, in any way, to suggest I do not appreciate the amount of 
work that has been going into the GLSAs and the difficulty in finding the 
people to keep doing it, then I am sorry.
It wasn't meant to sound that way.

I'll go read the Padawan page and see if there is anything I can do.

For others, the padawan-page can be found here:
http://www.gentoo.org/security/en/padawans.xml

--
Joost

Re: [gentoo-security] No GLSA since January?!?

[Kevin Bryan]

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

Although I like having the summary information about what the
vulnerability is, if I'm only reading them for packages I have
installed, then a reference of some kind would suffice.

I'd be fine even if it was just a new variable in the .ebuild file that
somehow indicated which versions it was a fix for, reusing the syntax
for dependency checking.  A reference to the CVE or gentoo bug reference
would be good, too:

SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64"
SECURITY_REF="CVE:2010-2169 http://..."
SECURITY_BUG="343089"
SECURITY_IMPACT="remote"

Then would be most of the work the committer needs to do is right there
in a file they are modifying anyway.

The portage @security set could also look for and evaluate these tags,
instead of parsing the GLSA's.

Note on the impact variable: make a few easy to understand tags:
local
remote
remote-user-assist
denial-of-service
...

- --Kevin


On Fri, Aug 26, 2011 at 07:06:35PM +0200, Christian Kauhaus wrote:

> Am 26.08.2011 18:55, schrieb Alex Legler:
> > Compared to other distributions, our advisories have been rather detailed with
> > lots of manually researched information. I'm not sure if we can keep up this
> > very high standard with the limited manpower, but we'll try our best.
> 
> I see the point. I think it would be an achievement over the current situation 
> (which is: no current GLSAs at all) to send out less detailed GLSAs. Even 
> something short as: "$PACKAGE has vulnerabilities, they are fixed in $VERSION, 
> for details see $CVE" would be immensely helpful.
> 
> Is the any viable way to get it at least to this point? Probably the largest 
> part of such a task could be automated. This would lift the burden from the 
> security maintainers.
> 
> Regards
> 
> Christian
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk5X4SYACgkQ6ENyPMTUmzpTLwCeIrikkC82ZC/YMALUD3AUOG71
GQ0An02FoagrOJSU4kFQ8RUP+q/1+zQn
=/kf5
-----END PGP SIGNATURE-----

Re: [gentoo-security] No GLSA since January?!?

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Friday 26 August 2011 14:08:38 Kevin Bryan wrote:
> Although I like having the summary information about what the
> vulnerability is, if I'm only reading them for packages I have
> installed, then a reference of some kind would suffice.
> 
> I'd be fine even if it was just a new variable in the .ebuild file that
> somehow indicated which versions it was a fix for, reusing the syntax
> for dependency checking.  A reference to the CVE or gentoo bug reference
> would be good, too:
> 
> SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64"
> SECURITY_REF="CVE:2010-2169 http://..."
> SECURITY_BUG="343089"
> SECURITY_IMPACT="remote"
> 
> Then would be most of the work the committer needs to do is right there
> in a file they are modifying anyway.
> 
> The portage @security set could also look for and evaluate these tags,
> instead of parsing the GLSA's.

A complete change of the system is very unlikely.
Nevertheless: What is the end-to-end process in your solution? (i.e. 
vulnerability report to 'advisory' release)

A while ago a similar solution was proposed. Basically you want to shift our 
job back to the package maintainers. That might work, but rais a few new 
issues.

We'd automatically lose some consistency, because not everyone would follow 
the needed or wanted data scheme. Such a thing is much better to control in a 
smaller and better connected group of people.

Also, cleanup and large amounts of issues in packages are issues. Browsers 
usually get hundreds of CVEs assigned in a year, that would be all in the 
Ebuild, and for how long?

Personally, I'm not convinced this is a model that would be an improvement 
over the current situation.

Alex

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security / Ruby

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Kevin Bryan]

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

I was not considering the entire process, just the part that really
impacts me: identifying vulnerable and patched packages.  Full
advisories are nice, but really what I want to know is when I need to
update a particular package.

You are right that marking the packages that contain fixes doesn't
really scale because of increased baggage to carry forward.

The problem I have with GLSA's is that they don't come out until after
the problem has been fixed.  

Perhaps it would be better to just have a system to label a particular
ebuild/version as vulnerable.  Maybe something closer to package.mask,
but for security would be appropriate.  With a package.security_mask,
you could have anyone on the security project update that file with
packages as soon as they know about it and while they are waiting on the
devs to fix it.  References/links/impact could be noted in the comments
above, as package.mask does now.

As for interacting with 'emerge', I don't think we want the same
semantics as package.mask, since we don't want to force a downgrade (if
possible).  It should probably just warn when you ask it to install a
vulnerable version.  Upgrades to safe versions will be quiet that way.
The @security would contain packages with and without fixes so you get
warnings for things that remain vulnerable, and updates for things that
are fixed.

Thoughts?

- --Kevin

On Fri, Aug 26, 2011 at 08:40:29PM +0200, Alex Legler wrote:
> 
> A complete change of the system is very unlikely.
> Nevertheless: What is the end-to-end process in your solution? (i.e. 
> vulnerability report to 'advisory' release)
> 
> A while ago a similar solution was proposed. Basically you want to shift our 
> job back to the package maintainers. That might work, but rais a few new 
> issues.
> 
> We'd automatically lose some consistency, because not everyone would follow 
> the needed or wanted data scheme. Such a thing is much better to control in a 
> smaller and better connected group of people.
> 
> Also, cleanup and large amounts of issues in packages are issues. Browsers 
> usually get hundreds of CVEs assigned in a year, that would be all in the 
> Ebuild, and for how long?
> 
> Personally, I'm not convinced this is a model that would be an improvement 
> over the current situation.
> 
> Alex
> 
> -- 
> Alex Legler <a3li@gentoo.org>
> Gentoo Security / Ruby


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd
VakAnA4yzElckmCZaikTsPZdWZU5VazF
=MSwi
-----END PGP SIGNATURE-----

Re: [gentoo-security] No GLSA since January?!?

[Daniel A. Avelino]

I like this approach but I have no idea about how this could be performed.

ACCEPT_RISKS="remote dos"  emerge ...

Sounds very cool to me.

Daniel

On 8/26/11, Kevin Bryan <bryank@cs.uri.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I was not considering the entire process, just the part that really
> impacts me: identifying vulnerable and patched packages.  Full
> advisories are nice, but really what I want to know is when I need to
> update a particular package.
>
> You are right that marking the packages that contain fixes doesn't
> really scale because of increased baggage to carry forward.
>
> The problem I have with GLSA's is that they don't come out until after
> the problem has been fixed.
>
> Perhaps it would be better to just have a system to label a particular
> ebuild/version as vulnerable.  Maybe something closer to package.mask,
> but for security would be appropriate.  With a package.security_mask,
> you could have anyone on the security project update that file with
> packages as soon as they know about it and while they are waiting on the
> devs to fix it.  References/links/impact could be noted in the comments
> above, as package.mask does now.
>
> As for interacting with 'emerge', I don't think we want the same
> semantics as package.mask, since we don't want to force a downgrade (if
> possible).  It should probably just warn when you ask it to install a
> vulnerable version.  Upgrades to safe versions will be quiet that way.
> The @security would contain packages with and without fixes so you get
> warnings for things that remain vulnerable, and updates for things that
> are fixed.
>
> Thoughts?
>
> - --Kevin
>
> On Fri, Aug 26, 2011 at 08:40:29PM +0200, Alex Legler wrote:
>>
>> A complete change of the system is very unlikely.
>> Nevertheless: What is the end-to-end process in your solution? (i.e.
>> vulnerability report to 'advisory' release)
>>
>> A while ago a similar solution was proposed. Basically you want to shift
>> our
>> job back to the package maintainers. That might work, but rais a few new
>> issues.
>>
>> We'd automatically lose some consistency, because not everyone would
>> follow
>> the needed or wanted data scheme. Such a thing is much better to control
>> in a
>> smaller and better connected group of people.
>>
>> Also, cleanup and large amounts of issues in packages are issues. Browsers
>>
>> usually get hundreds of CVEs assigned in a year, that would be all in the
>> Ebuild, and for how long?
>>
>> Personally, I'm not convinced this is a model that would be an improvement
>>
>> over the current situation.
>>
>> Alex
>>
>> --
>> Alex Legler <a3li@gentoo.org>
>> Gentoo Security / Ruby
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd
> VakAnA4yzElckmCZaikTsPZdWZU5VazF
> =MSwi
> -----END PGP SIGNATURE-----
>
>

Re: [gentoo-security] No GLSA since January?!?

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

On Friday 26 August 2011 16:02:56 Kevin Bryan wrote:
> I was not considering the entire process, just the part that really
> impacts me: identifying vulnerable and patched packages.  Full
> advisories are nice, but really what I want to know is when I need to
> update a particular package.
> 
> You are right that marking the packages that contain fixes doesn't
> really scale because of increased baggage to carry forward.
> 
> The problem I have with GLSA's is that they don't come out until after
> the problem has been fixed.
> 
> Perhaps it would be better to just have a system to label a particular
> ebuild/version as vulnerable.  Maybe something closer to package.mask,
> but for security would be appropriate.  With a package.security_mask,
> you could have anyone on the security project update that file with
> packages as soon as they know about it and while they are waiting on the
> devs to fix it.  References/links/impact could be noted in the comments
> above, as package.mask does now.
> 
> As for interacting with 'emerge', I don't think we want the same
> semantics as package.mask, since we don't want to force a downgrade (if
> possible).  It should probably just warn when you ask it to install a
> vulnerable version.  Upgrades to safe versions will be quiet that way.
> The @security would contain packages with and without fixes so you get
> warnings for things that remain vulnerable, and updates for things that
> are fixed.
> 
> Thoughts?

I see this as an addition to sending advisories after fixing an issue, not as 
a solution to the issue at hand.

-- 
Alex Legler <a3li@gentoo.org>
Gentoo Security / Ruby

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Daniel A. Avelino]

But Alex, this could be a great improvement in system at all. This can
help administrators to measure better its systems, and may be "force"
developers to solve issues faster.

What do you think?


Daniel

On 8/26/11, Alex Legler <a3li@gentoo.org> wrote:
> On Friday 26 August 2011 16:02:56 Kevin Bryan wrote:
>> I was not considering the entire process, just the part that really
>> impacts me: identifying vulnerable and patched packages.  Full
>> advisories are nice, but really what I want to know is when I need to
>> update a particular package.
>>
>> You are right that marking the packages that contain fixes doesn't
>> really scale because of increased baggage to carry forward.
>>
>> The problem I have with GLSA's is that they don't come out until after
>> the problem has been fixed.
>>
>> Perhaps it would be better to just have a system to label a particular
>> ebuild/version as vulnerable.  Maybe something closer to package.mask,
>> but for security would be appropriate.  With a package.security_mask,
>> you could have anyone on the security project update that file with
>> packages as soon as they know about it and while they are waiting on the
>> devs to fix it.  References/links/impact could be noted in the comments
>> above, as package.mask does now.
>>
>> As for interacting with 'emerge', I don't think we want the same
>> semantics as package.mask, since we don't want to force a downgrade (if
>> possible).  It should probably just warn when you ask it to install a
>> vulnerable version.  Upgrades to safe versions will be quiet that way.
>> The @security would contain packages with and without fixes so you get
>> warnings for things that remain vulnerable, and updates for things that
>> are fixed.
>>
>> Thoughts?
>
> I see this as an addition to sending advisories after fixing an issue, not
> as
> a solution to the issue at hand.
>
> --
> Alex Legler <a3li@gentoo.org>
> Gentoo Security / Ruby

Re: [gentoo-security] No GLSA since January?!?

[Daniel A. Avelino]

[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]

Hi Kevin.

That is an interesting idea. So one could check about vulnerabilies
solutions
_before_ package installation. And better. This could give us a measure
about
how secure [think a little bit ahead] packages in portage tree are.

Actually, there are some mechanisms to know what is the mean time
corrections are
provided when one look to portage's tree as a whole?

I like this idea and would like to suggest two other variables

SECURITY_CORRECTION_DATE
SECURITY_DISCOVERY_DATE

containing the date the correction was published on portage tree and
the date the problem was post [may be in bugzilla]

Let me go back and continue to read Security Project documentation.


Regards,

Daniel A. Avelino


On Fri, Aug 26, 2011 at 3:08 PM, Kevin Bryan <bryank@cs.uri.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Although I like having the summary information about what the
> vulnerability is, if I'm only reading them for packages I have
> installed, then a reference of some kind would suffice.
>
> I'd be fine even if it was just a new variable in the .ebuild file that
> somehow indicated which versions it was a fix for, reusing the syntax
> for dependency checking.  A reference to the CVE or gentoo bug reference
> would be good, too:
>
> SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64"
> SECURITY_REF="CVE:2010-2169 http://..."
> SECURITY_BUG="343089"
> SECURITY_IMPACT="remote"
>
> Then would be most of the work the committer needs to do is right there
> in a file they are modifying anyway.
>
> The portage @security set could also look for and evaluate these tags,
> instead of parsing the GLSA's.
>
> Note on the impact variable: make a few easy to understand tags:
> local
> remote
> remote-user-assist
> denial-of-service
> ...
>
> - --Kevin
>
>
> On Fri, Aug 26, 2011 at 07:06:35PM +0200, Christian Kauhaus wrote:
>
> > Am 26.08.2011 18:55, schrieb Alex Legler:
> > > Compared to other distributions, our advisories have been rather
> detailed with
> > > lots of manually researched information. I'm not sure if we can keep up
> this
> > > very high standard with the limited manpower, but we'll try our best.
> >
> > I see the point. I think it would be an achievement over the current
> situation
> > (which is: no current GLSAs at all) to send out less detailed GLSAs. Even
> > something short as: "$PACKAGE has vulnerabilities, they are fixed in
> $VERSION,
> > for details see $CVE" would be immensely helpful.
> >
> > Is the any viable way to get it at least to this point? Probably the
> largest
> > part of such a task could be automated. This would lift the burden from
> the
> > security maintainers.
> >
> > Regards
> >
> > Christian
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iEYEARECAAYFAk5X4SYACgkQ6ENyPMTUmzpTLwCeIrikkC82ZC/YMALUD3AUOG71
> GQ0An02FoagrOJSU4kFQ8RUP+q/1+zQn
> =/kf5
> -----END PGP SIGNATURE-----
>
>

[-- Attachment #2: Type: text/html, Size: 3616 bytes --]

Re: [gentoo-security] No GLSA since January?!?

[Christian Kauhaus]

Am 26.08.2011 20:08, schrieb Kevin Bryan:
> SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64"
> SECURITY_REF="CVE:2010-2169 http://..."
> SECURITY_BUG="343089"
> SECURITY_IMPACT="remote"

Your idea sounds interesting and could lead to very cool technology like the 
'ACCEPT_RISKS="..."' variable mentioned elsewhere in this thread.

But it does not solve a major part of the use case. In my opinion, we need to 
get notifications about security risks over an independent channel without 
having to update the portage tree.

For me (and the rest of my company) the greatest advantage of Gentoo over 
other distributions it it's "continuous integration" approach. Updates get 
committed to the portage tree continuously over time and administrators are 
completely free on how often and when they update their systems. This is 
great. But given I have an installed base and I have no reason to update the 
portage tree now, I need a reliable information about "this package is 
borked". Then I should go for update as fast as possible of course. :-)

So in consequence I would appreciate to have both mechanisms: a timely 
up-front notification via GLSAs (probably more brief than the past ones) and 
some sort of security masking.

Regards

Christian

-- 
Dipl.-Inf. Christian Kauhaus <>< · kc@gocept.com · systems administration
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
Zope and Plone consulting and development

Re: [gentoo-security] No GLSA since January?!?

[Rich Freeman]

On Sat, Aug 27, 2011 at 4:49 AM, Christian Kauhaus <kc@gocept.com> wrote:
> So in consequence I would appreciate to have both mechanisms: a timely
> up-front notification via GLSAs (probably more brief than the past ones) and
> some sort of security masking.

The current GLSA mechanism already provides both of these.  There are
the email notifications, and there is an xml file that provides the
masking information (which the glsa-checker tool and some package
managers use).

From what I've seen (from a distance), the problem seems to be that
both of these are created using a software tool which is apparently
very cumbersome to use.  However, both are just text files.

Part of me wonders if a workflow like this would help solve the problem:

1.  Some contributor posts a GLSA email and xml file to a security
bug.  This could be anybody.  The content would be trimmed down a bit
- perhaps just a CVE reference, and then the information on vulnerable
and non-vulnerable versions.

2.  Somebody on staff with commit access to the xml tree and the
mailing list would review and send out the advisory, and mark this as
done in the bug.

I also wonder if there would be in value in sending out the notice
after the fixed version is in the tree but before it is stable.  Right
now advisories wait until the last security-supported arch stabilizes
the package.  I would think that earlier notice would be useful - even
if sysadmins want to wait for a package to become stable they'll know
something is coming, and the delay on the major arches tends to be
hours to days.  Plus, if somebody can't wait they can test/install on
their own, and perhaps even post feedback on the bug.

Obviously notices would have to wait until after any blackout period ends.

Note that I'm basically advocating ditching the tool.  A tool is good
when it improves productivity.  However, right now it appears that the
tool is keeping people from contributing who want to contribute.
Certainly things couldn't get worse without the tool.  If a user just
edits an xml template and email template and posts it on the bug, then
very little work should be required to review the files before posting
them.  Contributors wouldn't need any special access either - freeing
up devs to provide more of a QA role.

Ditching the tool would also simplify fixes to GLSAs.  I haven't run
it in a while, but took glsa-checker out of my cron ages ago when it
would just report packages with vulnerabilities that had none.  I did
log bugs, but apparently adding one line to the xml files requires as
much pain as sending out the original notice.

Bottom line, however, is I don't think that we can't consider
ourselves as a serious distro if we don't provide timely security
advisories.

All that said, I would say that from what I've seen in bugzilla, if
you're on x86 or amd64 and running an updated stable tree, you
shouldn't have longstanding security vulnerabilities.  A new security
bug pops up almost weekly, and packages are updated fairly quickly on
those arches.  The problem is just that we never tell anybody that
we're doing it.

Rich

Re: [gentoo-security] No GLSA since January?!?

[Tobias Heinlein]

Rich Freeman wrote, on 08/27/2011 02:13 PM:
> Note that I'm basically advocating ditching the tool.  A tool is good
> when it improves productivity.  However, right now it appears that the
> tool is keeping people from contributing who want to contribute.
> Certainly things couldn't get worse without the tool.  If a user just
> edits an xml template and email template and posts it on the bug, then
> very little work should be required to review the files before posting
> them.  Contributors wouldn't need any special access either - freeing
> up devs to provide more of a QA role.
> 
> Ditching the tool would also simplify fixes to GLSAs.  I haven't run
> it in a while, but took glsa-checker out of my cron ages ago when it
> would just report packages with vulnerabilities that had none.  I did
> log bugs, but apparently adding one line to the xml files requires as
> much pain as sending out the original notice.

I have read that idea multiple times now, each of them by people not on
the security team or something similar. It just doesn't work that way.
It's like suggesting to ditch Bugzilla and instead enter bugs manually
with SQL commands into a database. Well, not quite, but you get the idea.

Also, as previously stated, we know that the tool sucks, which is why
Alex has been working for months on new tools. We really wouldn't spend
that much time on that if it wasn't worth it.

Re: [gentoo-security] No GLSA since January?!?

[Rich Freeman]

On Sat, Aug 27, 2011 at 8:34 AM, Tobias Heinlein <keytoaster@gentoo.org> wrote:
> I have read that idea multiple times now, each of them by people not on
> the security team or something similar. It just doesn't work that way.
> It's like suggesting to ditch Bugzilla and instead enter bugs manually
> with SQL commands into a database. Well, not quite, but you get the idea.

So, if we weren't able to log or update any bugs for six months, we
would probably at least give devs a spreadsheet on google docs or
something.  I wouldn't suggest that we put the distro on hold until
somebody could re-engineer bugzilla.

If we had an automatic ebuild creator and nobody created ebuilds for
six months I'd suggest that we create them by hand.

We're talking about emails and xml files - neither of which are
terribly complex.  Exact format on the former is not critical, and the
syntax of the latter can be checked with standard tools.  If on rare
occasion we get one wrong we fix it - just like we do with ebuilds
(the libpng glsa still shows stable amd64 as vulnerable, so simply
having a tool doesn't prevent mistakes).

>
> Also, as previously stated, we know that the tool sucks, which is why
> Alex has been working for months on new tools. We really wouldn't spend
> that much time on that if it wasn't worth it.

I have no doubt that automation is better than no automation.
However, that isn't really what we're discussing here.  What we're
talking about is GLSAs vs no GLSAs.  Working automated GLSAs
apparently don't exist right now.  It is wonderful that a bunch of
people are looking to change that, however it doesn't really change
the fact that we're not sending out GLSAs, and that makes it hard for
people to take Gentoo seriously as a distro.  If the new tool were
just a few weeks away then a few posts to -dev/-security updating
status would probably alleviate concerns.  However, I think that
people have been talking about fixing the GLSA tool for ages now.

I think the fundamental problem is failing to distinguish between
operations and improvements.  You can't put the former on hold to work
on the latter.  It seems like we're trying to debate how to build the
Hagia Sophia while we're sleeping on dirt and rocks.  In my thinking
the most critical requirement is that we send out a notice when we
have a vulnerability, and describe what the vulnerability is (in a
sentence with links), and what versions are and are not vulnerable.
When resource constraints hit a volunteer project, the solution is
usually to create a more distributed solution.

Rich

Re: [gentoo-security] No GLSA since January?!?

[Tobias Heinlein]

Rich Freeman wrote, on 08/27/2011 03:06 PM:
> However, that isn't really what we're discussing here.  What we're
> talking about is GLSAs vs no GLSAs.  Working automated GLSAs
> apparently don't exist right now.  It is wonderful that a bunch of
> people are looking to change that, however it doesn't really change
> the fact that we're not sending out GLSAs, and that makes it hard for
> people to take Gentoo seriously as a distro.

Yes, we are aware of that. We know it's very unfortunate, but just
*stating* it doesn't get us more manpower.

> If the new tool were
> just a few weeks away then a few posts to -dev/-security updating
> status would probably alleviate concerns.  However, I think that
> people have been talking about fixing the GLSA tool for ages now.

We currently believe the tool *is* just a few weeks away; we plan to
meet in person at the end of September. But I don't want to promise
anything as real life may get in the way anytime.

> I think the fundamental problem is failing to distinguish between
> operations and improvements.  You can't put the former on hold to work
> on the latter.

Sure, but that is not the case. It's still possible to use the old
GLSAmaker and send out advisories; the problem is manpower. No-one
currently wants to do the work with the old tool (And no, editing XML
files manually won't motivate people either).

> When resource constraints hit a volunteer project, the solution is
> usually to create a more distributed solution.

That's similar to the bug wrangling situation a while ago. The queue was
huge and everyone knew we needed more people to wrangle the bugs. But
how many people actually did that for more than a few? Not even a handful.

Having maintainers "care" about security just won't work out. That's why
the security team exists in the first place.