Gentoo Linux security discussion

Christian Kauhaus | 26 Aug 2011 18:12

No GLSA since January?!?

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 <at> 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

headers

Christoph Jasinski | 26 Aug 2011 18:43

Re: No GLSA since January?!?

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 <at> 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
>

headers

Alex Legler | 26 Aug 2011 18:55

Re: No GLSA since January?!?

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)

(Continue reading)

headers

Christian Kauhaus | 26 Aug 2011 19:06

Re: No GLSA since January?!?

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 <at> 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

headers

Kevin Bryan | 26 Aug 2011 20:08

Re: No GLSA since January?!?


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  <at> 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

(Continue reading)

headers

Alex Legler | 26 Aug 2011 20:40

Re: No GLSA since January?!?

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  <at> 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

(Continue reading)

headers

Kevin Bryan | 26 Aug 2011 22:02

Re: No GLSA since January?!?


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  <at> 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?

(Continue reading)

headers

Daniel A. Avelino | 26 Aug 2011 22:40

Re: No GLSA since January?!?

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 <at> 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.

(Continue reading)

headers

Alex Legler | 27 Aug 2011 00:27

Re: No GLSA since January?!?

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  <at> 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?

(Continue reading)

headers

Daniel A. Avelino | 27 Aug 2011 01:38

Re: No GLSA since January?!?

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 <at> 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

(Continue reading)

headers

Daniel A. Avelino | 26 Aug 2011 20:41

Re: No GLSA since January?!?

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 <at> 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 <at> 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-----

headers

Christian Kauhaus | 27 Aug 2011 10:49

Re: No GLSA since January?!?

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 <at> 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

headers

Rich Freeman | 27 Aug 2011 14:13

Re: No GLSA since January?!?

On Sat, Aug 27, 2011 at 4:49 AM, Christian Kauhaus <kc <at> 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

headers

Tobias Heinlein | 27 Aug 2011 14:34

Re: No GLSA since January?!?

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.

headers

Rich Freeman | 27 Aug 2011 15:06

Re: No GLSA since January?!?

On Sat, Aug 27, 2011 at 8:34 AM, Tobias Heinlein <keytoaster <at> 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

headers

Tobias Heinlein | 27 Aug 2011 15:34

Re: No GLSA since January?!?

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.