Linux Security Workgroup
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security
verification of Linux kernel subsystems in order to assist in securing the Linux Kernel and maintain trust and confidence in the security of the Linux ecosystem.
This may include, but is not limited to, topics such as tooling to assist in securing the Linux Kernel, verification and testing of critical subsystems for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.
For communication, we have permission to use the following mail list: [email protected] The list can be subscribed to at: http://www.openwall.com/lists/#subscribe
If you would like to participate or know anyone else who would like to, please join the mailing list or feel free to pass the word on.
The bullets below are further details based on our discussion at the Linux Security Summit:
General Notes:
--------------
* The idea of the workgroup came from the Linux Foundation and Ted Tso after the kernel.org attack.
* Malicious code wasn't inserted into the kernel tree. git hashing would have detected a mismatch in kernel code quickly. Also the PGP web of trust and kernel signing was an important validation measure that's since been taken.
* Guidelines for subsystems could be created to provide guidance for best practices to consider when reviewing code (e.g. detecting common vulnerabilities, don't leave ssh private keys around, etc).
* Development and maintenance of automated tools would assist in securing the kernel on an ongoing basis.
* Maintainers should have more automated tooling available to enforce security checks on patches as they come in.
* Daily execution (perhaps on linux-next tree or as part of build system) of static analysis and emailing reports out to a list and CC'ing authors using git blame. Red Hat's Coverity license allows results to be shared with the upstream project.
* Provide verification of critical kernel subsystems (Kernel build infrastructure, Networking, Network file systems, KVM, Cryptographic library).
* Fuzz testing could be used to find potential problems in the kernel's interface to userspace (syscall, ioctl, KVM paravirt calls).
* More stringent rules could be adopted such as patch signing.
* The security community should share and coordinate their efforts on the mail list so that overlap of work items does not occur.
Resource requirements:
----------------------
* We should narrow down the working group's scope and/or priorities before we narrow down the resources.
* Perhaps allocating people for a limited amount of time that rotates would be the most attainable resource possibility.
Signature · 2 lines
Regards, Corey Bryant
Quoted 8 lines · Corey Bryant
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security verification of Linux kernel subsystems in order to assist in securing the Linux Kernel and maintain trust and confidence in the security of the Linux ecosystem.
Quoted 4 lines
This may include, but is not limited to, topics such as tooling to assist in securing the Linux Kernel, verification and testing of critical subsystems for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.
Thanks for getting this rolling!
What are the next steps? Does it make sense to try to gather a list of active projects to try and see where things currently stand? (i.e who is actively running smatch, trinity, etc?) Or to call attention to a specific subsystem that needs direct auditing (e.g. KVM)?
-Kees
Signature · 2 lines
Kees Cook Chrome OS Security
Quoted 15 lines · Kees Cook
Quoted 8 lines · Corey Bryant
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security verification of Linux kernel subsystems in order to assist in securing the Linux Kernel and maintain trust and confidence in the security of the Linux ecosystem.
Quoted 4 lines
This may include, but is not limited to, topics such as tooling to assist in securing the Linux Kernel, verification and testing of critical subsystems for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.
Quoted 9 lines
Thanks for getting this rolling!
What are the next steps? Does it make sense to try to gather a list of active projects to try and see where things currently stand? (i.e who is actively running smatch, trinity, etc?) Or to call attention to a specific subsystem that needs direct auditing (e.g. KVM)?
-Kees
No problem, thanks for the input!
I think having a list of active projects is a good place to start.
Perhaps we can also add desired projects to this list, and if anyone has cycles to cover a project they can put their name to the project.
I'm personally trying to get time allocated to work on KVM fuzzing and/or static analysis in 2013.
A wiki probably makes sense for the list. Google sites has wikis. I can start one there unless there are other ideas.
Signature · 2 lines
Regards, Corey Bryant
Quoted 32 lines · Corey Bryant
Quoted 29 lines · Kees Cook
Quoted 11 lines · Corey Bryant
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security verification of Linux kernel subsystems in order to assist in securing the
Linux Kernel and maintain trust and confidence in the security of the Linux
ecosystem.Quoted 6 lines
This may include, but is not limited to, topics such as tooling to assist in
securing the Linux Kernel, verification and testing of critical subsystems
for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.Thanks for getting this rolling!
What are the next steps? Does it make sense to try to gather a list of active projects to try and see where things currently stand? (i.e who is actively running smatch, trinity, etc?) Or to call attention to a specific subsystem that needs direct auditing (e.g. KVM)?
Quoted 6 lines
Quoted 2 lines
-Kees
No problem, thanks for the input!
I think having a list of active projects is a good place to start.
I know Dan Carpenter is running smatch, as well as Fengguang Wu. Getting details on which trees are being scanned would be good.
I know Fengguang Wu is running trinity too.
There is a collection of coccinelle scripts in the tree, but I'm not sure if/when those are getting run by anyone. Julia, do you know if those are being regularly run?
Quoted 2 lines
Perhaps we can also add desired projects to this list, and if anyone has cycles to cover a project they can put their name to the project.
I was keeping a list of potential hardening work here:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream_Hardening
some of it is out of date.
Quoted 2 lines
I'm personally trying to get time allocated to work on KVM fuzzing and/or static analysis in 2013.
Sounds good.
Quoted 2 lines
A wiki probably makes sense for the list. Google sites has wikis. I can start one there unless there are other ideas.
Kernel.org hosts wikis as well, and James Morris already has
http://kernsec.org/. Perhaps we can use that? James, would this be something you'd be okay with?
Thanks,
-Kees
Signature · 2 lines
Kees Cook Chrome OS Security
Quoted 40 lines · Kees Cook
Quoted 32 lines · Corey Bryant
Quoted 29 lines · Kees Cook
Quoted 11 lines · Corey Bryant
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security verification of Linux kernel subsystems in order to assist in securing the
Linux Kernel and maintain trust and confidence in the security of the Linux
ecosystem.Quoted 6 lines
This may include, but is not limited to, topics such as tooling to assist in
securing the Linux Kernel, verification and testing of critical subsystems
for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.Thanks for getting this rolling!
What are the next steps? Does it make sense to try to gather a list of active projects to try and see where things currently stand? (i.e who is actively running smatch, trinity, etc?) Or to call attention to a specific subsystem that needs direct auditing (e.g. KVM)?
Quoted 6 lines
Quoted 2 lines
-Kees
No problem, thanks for the input!
I think having a list of active projects is a good place to start.
Quoted 8 lines
I know Dan Carpenter is running smatch, as well as Fengguang Wu. Getting details on which trees are being scanned would be good.
I know Fengguang Wu is running trinity too.
There is a collection of coccinelle scripts in the tree, but I'm not sure if/when those are getting run by anyone. Julia, do you know if those are being regularly run?
Fengguang Wu runs at least some of them as well.
Artem Bityutskiy also runs them on the patces he receives (aiaiai).
julia
Quoted 27 lines
Quoted 2 lines
Perhaps we can also add desired projects to this list, and if anyone has cycles to cover a project they can put their name to the project.
I was keeping a list of potential hardening work here:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream_Hardening
some of it is out of date.Quoted 2 lines
I'm personally trying to get time allocated to work on KVM fuzzing and/or static analysis in 2013.
Sounds good.
Quoted 2 lines
A wiki probably makes sense for the list. Google sites has wikis. I can start one there unless there are other ideas.
Kernel.org hosts wikis as well, and James Morris already has
http://kernsec.org/. Perhaps we can use that? James, would this be something you'd be okay with?Thanks,
-Kees
Signature · 2 lines
Kees Cook Chrome OS Security
Quoted 36 lines · Kees Cook
Quoted 35 lines · Corey Bryant
Quoted 31 lines · Kees Cook
Quoted 11 lines · Corey Bryant
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security verification of Linux kernel subsystems in order to assist in securing the
Linux Kernel and maintain trust and confidence in the security of the Linux
ecosystem.Quoted 6 lines
This may include, but is not limited to, topics such as tooling to assist in
securing the Linux Kernel, verification and testing of critical subsystems
for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.Thanks for getting this rolling!
What are the next steps? Does it make sense to try to gather a list of active projects to try and see where things currently stand? (i.e who is actively running smatch, trinity, etc?) Or to call attention to a specific subsystem that needs direct auditing (e.g. KVM)?
-Kees
Quoted 7 lines
Quoted 3 lines
No problem, thanks for the input!
I think having a list of active projects is a good place to start.
I know Dan Carpenter is running smatch, as well as Fengguang Wu. Getting details on which trees are being scanned would be good.
I run it against linux-next x86_64 allmodconfig.
regards,
dan carpenter
Quoted 40 lines · Kees Cook
Quoted 32 lines · Corey Bryant
Quoted 29 lines · Kees Cook
Quoted 11 lines · Corey Bryant
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security verification of Linux kernel subsystems in order to assist in securing the
Linux Kernel and maintain trust and confidence in the security of the Linux
ecosystem.Quoted 6 lines
This may include, but is not limited to, topics such as tooling to assist in
securing the Linux Kernel, verification and testing of critical subsystems
for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.Thanks for getting this rolling!
What are the next steps? Does it make sense to try to gather a list of active projects to try and see where things currently stand? (i.e who is actively running smatch, trinity, etc?) Or to call attention to a specific subsystem that needs direct auditing (e.g. KVM)?
Quoted 6 lines
Quoted 2 lines
-Kees
No problem, thanks for the input!
I think having a list of active projects is a good place to start.
Quoted 9 lines
I know Dan Carpenter is running smatch, as well as Fengguang Wu. Getting details on which trees are being scanned would be good.
I know Fengguang Wu is running trinity too.
There is a collection of coccinelle scripts in the tree, but I'm not sure if/when those are getting run by anyone. Julia, do you know if those are being regularly run?
Great, thanks for the info.
Quoted 7 lines
Quoted 2 lines
Perhaps we can also add desired projects to this list, and if anyone has cycles to cover a project they can put their name to the project.
I was keeping a list of potential hardening work here:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream_Hardening
some of it is out of date.
Ok so I guess it doesn't make sense to re-invent these details on another wiki. Although in the long run it may be nice to have everything in one place (active projects and desired projects).
Quoted 11 lines
Quoted 2 lines
I'm personally trying to get time allocated to work on KVM fuzzing and/or static analysis in 2013.
Sounds good.
Quoted 2 lines
A wiki probably makes sense for the list. Google sites has wikis. I can start one there unless there are other ideas.
Kernel.org hosts wikis as well, and James Morris already has
http://kernsec.org/. Perhaps we can use that? James, would this be something you'd be okay with?
That sounds good to me if it's okay with James.
Signature · 2 lines
Regards, Corey Bryant
Quoted 5 lines
Thanks,
-Kees
Quoted 4 lines · Corey Bryant
Quoted 2 lines
http://kernsec.org/. Perhaps we can use that? James, would this be something you'd be okay with?
That sounds good to me if it's okay with James.
Sounds good -- email me if you want an account there.
Signature · 2 lines
James Morris <[email protected]>
Quoted 59 lines · Kees Cook
Quoted 32 lines · Corey Bryant
Quoted 29 lines · Kees Cook
Quoted 11 lines · Corey Bryant
At the Linux Security Summit we began discussing the Linux Security Workgroup and some of the efforts that we can focus on.
The charter of the workgroup is to provide on-going security verification of Linux kernel subsystems in order to assist in securing the
Linux Kernel and maintain trust and confidence in the security of the Linux
ecosystem.Quoted 6 lines
This may include, but is not limited to, topics such as tooling to assist in
securing the Linux Kernel, verification and testing of critical subsystems
for vulnerabilities, security improvements for build tools, and providing guidance for maintaining subsystem security.Thanks for getting this rolling!
What are the next steps? Does it make sense to try to gather a list of active projects to try and see where things currently stand? (i.e who is actively running smatch, trinity, etc?) Or to call attention to a specific subsystem that needs direct auditing (e.g. KVM)?
Quoted 6 lines
Quoted 2 lines
-Kees
No problem, thanks for the input!
I think having a list of active projects is a good place to start.
I know Dan Carpenter is running smatch, as well as Fengguang Wu. Getting details on which trees are being scanned would be good.
I know Fengguang Wu is running trinity too.
There is a collection of coccinelle scripts in the tree, but I'm not sure if/when those are getting run by anyone. Julia, do you know if those are being regularly run?
Quoted 2 lines
Perhaps we can also add desired projects to this list, and if anyone has cycles to cover a project they can put their name to the project.
I was keeping a list of potential hardening work here:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream_Hardening
some of it is out of date.Quoted 2 lines
I'm personally trying to get time allocated to work on KVM fuzzing and/or static analysis in 2013.
Quoted 8 lines
Sounds good.
Quoted 2 lines
A wiki probably makes sense for the list. Google sites has wikis. I can start one there unless there are other ideas.
Kernel.org hosts wikis as well, and James Morris already has
http://kernsec.org/. Perhaps we can use that? James, would this be something you'd be okay with?
Here's a start on the wiki. There's not really a whole lot on it other than what we've discussed on the list, but it's a start. Comments and updates are very much welcome.
http://kernsec.org/wiki/index.php/Linux_Security_Workgroup
A couple of questions:
* What should the work group's scope be? The charter mentions " ...
on-going security verification of Linux kernel subsystems ... ". I was thinking it would focus more on items like: fuzzing, static analysis, education for reviewing code, tooling/build security enhancements. But I have a feeling it will start to include Kernel development projects too.
* Where should we document inactive, but desired, projects? I know
Kees has https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening but I'm wondering if it makes sense to keep track of work items on the same wiki.
Signature · 2 lines
Regards, Corey Bryant
Quoted 5 lines · Corey Bryant
Here's a start on the wiki. There's not really a whole lot on it other than what we've discussed on the list, but it's a start. Comments and updates are very much welcome.
Cool! This looks good.
We may want to add a mailing list pointer to this top-level page, so people can find this list more directly.
Quoted 6 lines
A couple of questions:
* What should the work group's scope be? The charter mentions " ...
on-going security verification of Linux kernel subsystems ... ". I was thinking it would focus more on items like: fuzzing, static analysis, education for reviewing code, tooling/build security enhancements. But I have a feeling it will start to include Kernel development projects too.
I think it should, yes. Finding bugs is, of course, important, but I'd like to have a single point of contact for development tasks too.
Quoted 3 lines
* Where should we document inactive, but desired, projects? I know Kees
has https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening but I'm wondering if it makes sense to keep track of work items on the same wiki.
I'll take a TODO to build up a Development section on the wiki and move things from the ubuntu wik
-Kees
Signature · 2 lines
Kees Cook Chrome OS Security
Quoted 11 lines · Kees Cook
Quoted 5 lines · Corey Bryant
Here's a start on the wiki. There's not really a whole lot on it other than what we've discussed on the list, but it's a start. Comments and updates are very much welcome.
Cool! This looks good.
We may want to add a mailing list pointer to this top-level page, so people can find this list more directly.
Good idea, I've added this.
Quoted 11 lines
Quoted 7 lines
A couple of questions:
* What should the work group's scope be? The charter mentions " ...
on-going security verification of Linux kernel subsystems ... ". I was thinking it would focus more on items like: fuzzing, static analysis, education for reviewing code, tooling/build security enhancements. But I have a feeling it will start to include Kernel development projects too.I think it should, yes. Finding bugs is, of course, important, but I'd like to have a single point of contact for development tasks too.
That's fine with me. I just want to have a clear understanding more than anything.
Quoted 6 lines
Quoted 3 lines
* Where should we document inactive, but desired, projects? I know Kees
has https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening but I'm wondering if it makes sense to keep track of work items on the same wiki.I'll take a TODO to build up a Development section on the wiki and move things from the ubuntu wik
Awesome, thanks!
Signature · 2 lines
Regards, Corey Bryant
Quoted 5 lines · Corey Bryant
Here's a start on the wiki. There's not really a whole lot on it other than what we've discussed on the list, but it's a start. Comments and updates are very much welcome.
Thanks for pulling this together.
I haven't forgotten about my TODO from the summit to look into running Coverity on the upstream kernel on a regular basis, I've just been stuck on other things since returning. Unfortunately, the next couple of weeks will be a bit tricky too, but I hope to be able to report something back in early November.
Signature · 2 lines
paul moore security and virtualization @ redhat
Quoted 7 lines · Paul Moore
Quoted 5 lines · Corey Bryant
Here's a start on the wiki. There's not really a whole lot on it other than what we've discussed on the list, but it's a start. Comments and updates are very much welcome.
Quoted 7 lines
Thanks for pulling this together.
I haven't forgotten about my TODO from the summit to look into running Coverity on the upstream kernel on a regular basis, I've just been stuck on other things since returning. Unfortunately, the next couple of weeks will be a bit tricky too, but I hope to be able to report something back in early November.
Cool, thanks. I've added your name next to the Coverity project item. (And I renamed the page to just "Active Projects".)
-Kees
Signature · 2 lines
Kees Cook Chrome OS Security
Quoted 7 lines · Paul Moore
Quoted 5 lines · Corey Bryant
Here's a start on the wiki. There's not really a whole lot on it other than what we've discussed on the list, but it's a start. Comments and updates are very much welcome.
Quoted 8 lines
Thanks for pulling this together.
I haven't forgotten about my TODO from the summit to look into running Coverity on the upstream kernel on a regular basis, I've just been stuck on other things since returning. Unfortunately, the next couple of weeks will be a bit tricky too, but I hope to be able to report something back in early November.
Thanks Paul!
Signature · 2 lines
Regards, Corey Bryant