* Re: [gentoo-security] glksa-check Proof of Concept
2014-01-18 4:25 [gentoo-security] glksa-check Proof of Concept Samuel Damashek
@ 2014-01-19 2:24 ` Chris Reffett
0 siblings, 0 replies; 2+ messages in thread
From: Chris Reffett @ 2014-01-19 2:24 UTC (permalink / raw
To: gentoo-security
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/17/2014 11:25 PM, Samuel Damashek wrote:
> At the request of creffett, I created a Proof of Concept for
> glksa-check, which allows for glksa XML files to define Kernel
> security vulnerabilities. Please realize that this is a Proof of
> Concept, and that the interface is not the most user-friendly. The
> code can definitely be improved as well. To test the program,
> untar the files and copy the glksa dir to /usr/portage/metadata/.
> At the moment, the script requires you to have /proc/config.gz
> enabled in your kernel to read your running config options.
>
> I have two XML files currently defined (still using the glsa.dtd
> schema); one that is an actual vulnerability and one that is simply
> a control that triggers on X86. To test the program, run it with
> the -l option.
>
> You can download the files at
> http://sdamashek.me/files/glksa.tar.gz (not sure if the mailing
> lists let you attach tarballs). There is definitely a lot to be
> improved about the application; this is just an idea for how to
> handle notifying users about Kernel vulnerabilities that affect
> their system. They would be released just like glsas. What are the
> list's opinions on this?
>
> -- Samuel Damashek
>
@security team: yes, I asked sdamashek to look into kernel bug
handling since we really don't do anything with it right now, and
suggested that he make a tool to check whether a kernel is vulnerable
(since it's more configuration-specific than a standard GLSA). As a
first step, I like it. It will need some cleaning up, of course, and
we will need to set up the framework to publish these and the
necessary integration into gentoolkit, but thank you for starting work
on this. As far as the release process goes, I think this could be
fairly easily automated--dump the CVE into the description, have
someone fill in the affected versions, kernel options, and type,
commit and send, no real need for peer review. I'm undecided as to
whether this is worth a new dtd or if we can just hack around the
existing glsa dtd, I think it might be worth a new one just for
simplicity. Of course, I'd like to hear the opinions of the more
senior members of security on what is needed to actually get this
deployable.
Chris Reffett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlLbN15fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TP6gCggp61cehAy0iursG8ZMIaOiGX
mswAni4Vr6JHpZCw92zCNQ+X5M6k4xJL
=8tqg
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 2+ messages in thread