|
grsec/PaX
Paul Wise <pabs3@...>
Hi,
The best you could do for core Linux infrastructure would be to pay for grsec/PaX to be merged into mainline Linux. -- bye, pabs http://bonedaddy.net/pabs3/ |
|
|
|
Re: grsec/PaX
Emily Ratliff
Thanks for the suggestion. The grsecurity folks do great work. Emily On Fri, Jul 10, 2015 at 12:32 AM, Paul Wise <pabs3@...> wrote: Hi, |
|
|
|
Trinity fuzzer
Paul Wise <pabs3@...>
Hi,
The Trinity fuzzer is essential to ensuring the security and reliability of the Linux kernel. The author of it has just quit working on it. It would be great if LF could repair the damage done by the discontinuation of this project. http://codemonkey.org.uk/2015/07/12/future-trinity/ -- bye, pabs http://bonedaddy.net/pabs3/ |
|
|
|
Re: Trinity fuzzer
Kevin P. Fleming (BLOOMBERG/ 731 LEX)
Thanks for bringing this to our attention. It's been forwarded to the CII Steering Committee for discussion. From: pabs3@... At: Jul 13 2015 13:43:19 Hi, |
|
|
|
You may be interested in this list of basic libraries I needed for my program
Steven Stewart-Gallus
Hello,
I found the paper about possibly vulnerable and critical software very informative. The paper mostly focused on core, web and development software. However, I think the full list of dependencies at https://gitlab.com/linted/linted/blob/master/docs/platforms.h that my own minimal personal game I'm working on may be interesting. The two key insights I would take away from my list of dependencies is that in order to put on the screen a simple 3D model one needs a huge rat nest of dependencies (some of which don't seem well supported) and that small shims such as libcap for little known functional that is exposed by the kernel and not by GLibc may not be well maintained. I think there was talk about creating a libsyscall or something for centralizing these shims a while ago but I don't think that got off the ground. You may also find the raw build dependencies at https://gitlab.com/linted/linted/blob/master/scripts/builddeps interesting. Also, many of the dependencies read or write file formats (such as s2tc, zlib, LLVM, libexpat and elfutils) as noted as potentially vulnerable stuff in the paper. XCB also does protocol handling. LLVM is also interesting because it is both used in compilers and jitters. Thank you, Steven Stewart-Gallus |
|
|
|
Minor update (version 1.1.0) in "develop" branch ready to go?
Sam and I have a minor update of the cii-census queued up in the "develop" branch. Below is a draft ChangeLog.
I'd like to release the develop branch this Wednesday as the new "master" branch. I don't think the changes are controversial, but I'd like to hear if others agree :-). It has a number of smaller improvements, a bugfix, and adds a number of projects.
--- David A. Wheeler
= DRAFT CHANGELOG =
2015-11-15 Version 1.1.0
* Issue #29: Included breakdown of risk index score into the result * Added original cached data from Openhub and Debian, put in original_cache folder * Included latest cached data and results put in latest_cache folder * Added projects suggested by pull requests (fail2ban, glib-networking, openvpn, clamav, dnsmasq, encfs, ffmpeg,owncloud, qemu, rsync, samba, virt-manager, git, subversion, mercurial, bzr, parted, vlc) * Fixed string and integer comparison bugs for CVE and 12-month contributor counts * Issue #22: get language and role for each project from apt_cache_dumpavail.txt, not through web scraping * Issue #28: only the 'worst' score is obtained from exposure values, making the code input processing more robust * General Code clean up * Added script to load results.csv into a SQLite database (thanks to Florian Weimer)
|
|
|
|
Re: Minor update (version 1.1.0) in "develop" branch ready to go?
Kevin P. Fleming (BLOOMBERG/ 731 LEX)
I've been lurking and watching the pull requests, and this set of updates certainly gets my vote, for what that's worth. From: dwheeler@... At: Jul 27 2015 16:18:56 To: cii-census@... Subject: Re:[cii-census] Minor update (version 1.1.0) in "develop" branch ready to go?
|
|
|
|
networking analysis of Linux applications
Miika Komu <mkomu@...>
FYI,
I read about the Linux foundations's core infrastructure census project. Related to this, we analyzed networking related issues in Linux applications a few years back in university: https://www.kernel.org/doc/ols/2012/ols2012-komu.pdf The next step would have been to automatize scanning of the software in the repositories of distributions. We're not working actively anymore on this, but the analysis source code is still available if somebody is interested. P.S. I am not actively following this list, so please contact us directly. |
|
|
|
Let's update the master branch due to accepting issue #21 (popularity)
We accepted issue#21 in the "develop" branch, which changes the scoring. See here for why and more detail:
https://github.com/linuxfoundation/cii-census/issues/21 We'd like to push this branch to master around Monday; any objections? Once that's updated, we should update the Linux Foundation page about it, but I think we should change the master branch first :-). --- David A. Wheeler |
|
|
|
Support Grsecurity/PaX
Jason A. Donenfeld
Dear Core Infrastructure Initiative:
I do consulting for several different security companies. The uniform advice across the industry is: if you want to deploy Linux securely, be sure to be using a Grsecurity/PaX kernel. This advice is given time after time in reports authored by several security companies for whom I consult. And companies who take their security seriously wind up using Grsecurity/PaX. This isn't just security-scare-speak rattling the saber; this is pretty much essential and true. As somebody who works day in day out developing exploits and finding vulnerability, I can tell you that Grsecurity/PaX makes my work considerably more difficult. The defenses Grsecurity/PaX offers are real, and are useful. They're doing important work, and as a whole they're moving everybody forward. Simply put, anybody serious about security uses a Grsecurity/PaX kernel. Yet, as far as I can see, the developers (CC'd) receive basically no funding, and since the source they release is GPL, the thousands of companies who deploy Grsecurity/PaX are not compelled to give any financial support. As such, the financial situation of the developers is in nearly constant peril, and this core Linux project lives under a consistent existential threat. Were it not for Grsecurity/PaX, I would probably not be using the Linux kernel in my mission critical infrastructure, in favor of some flavor of BSD that's copied Grsecurity/PaX's techniques. Or simply in favor of a smaller, less performant, more minimal BSD kernel, that would be a big hassle, but would have a smaller attack surface. However, since there is Grsecurity/PaX, I feel a bit more comfortable deploying Linux. And I think many in the security industry feel the same. So, Core Infrastructure Initiative - please - consider supporting them. I'm not affiliated with them in anyway, but in stumbling across CII, and reviewing what CII is up to, it struck me that there's currently a glaring omission in supported projects. Grsecurity/PaX ought to be at the top of the list. Thank you, Jason Donenfeld |
|
|
|
Re: Support Grsecurity/PaX
Dan Kohn <dan@...>
Thanks for the comment. Has anything significant changed since 2009?
toggle quoted message
Show quoted text
https://lwn.net/Articles/313621/ If members of the PAX team would like to apply for a grant to break up their work and work with upstream to get it included in mainline Linux, CII would be happy to consider it. https://www.coreinfrastructure.org/contact -- Dan Kohn <mailto:dan@...> tel:+1-415-233-1000 On Wed, Aug 19, 2015 at 9:12 AM, Jason A. Donenfeld <Jason@...> wrote:
Dear Core Infrastructure Initiative: |
|
|
|
Re: Support Grsecurity/PaX
Jason A. Donenfeld
I believe there have been significant changes since 2009. I'll let the Grsecurity/PaX developers chime in on this, I guess.
It's important to note, though, that it shouldn't be considered relevant whether or not their work is mainlined. This is an important core project that's extremely widely used by everybody who cares about security. Ensuring the work goes on is of *critical* importance. Not only that, but work done in Grsecurity/PaX _does_ make its way back to mainline bit by bit in the form of individual patches that are a rework of features pioneered by Grsecurity/PaX. In other words, mainlined or not, keeping Grsecurity/PaX around with healthy funding is of the utmost importance for the Linux ecosystem at large. We need them. (And I believe they very likely need you, CII.) |
|
|
|
Re: Support Grsecurity/PaX
Dan Kohn
On Wed, Aug 19, 2015 at 10:03 AM, Jason A. Donenfeld <Jason@...> wrote:
It's important to note, though, that it shouldn't be considered relevantCII follows the philosophy of Linux development that long-term, out-of-mainline patches are problematic because of the maintenance issues and lack of peer-review. Of course, the Grsecurity/PaX team is welcome to continue as they have been, and the GPL allows them to charge for consulting services. But the most likely scenario for a CII grant would be to facilitate inclusion into mainline. -- Dan Kohn <mailto:dankohn@...> Senior Advisor, Core Infrastructure Initiative tel:+1-415-233-1000 |
|
|
|
Re: Support Grsecurity/PaX
Jason A. Donenfeld
On Wed, Aug 19, 2015 at 4:15 PM, Dan Kohn <dankohn@...> wrote:
CII follows the philosophy of Linux development that long-term, Please do try to consider Grsecurity/PaX as not "just another out of tree patchset" but rather a mission critical project that serves a real world benefit in addition to pushing the bounds with the research that goes into it. No matter the debate on the various kernel development practices and philosophies, nobody in the security world disagrees with the fact that keeping Grsecurity/PaX around as a healthy project is very critical. Regardless of the mainline discussion, Grsecurity/PaX, as it exists today, *is* *core* *infrastructure*. |
|
|
|
Re: Support Grsecurity/PaX
Dan Kohn
On Wed, Aug 19, 2015 at 4:15 PM, Dan Kohn <dankohn@...> wrote: On Wed, Aug 19, 2015 at 10:21 AM, Jason A. Donenfeld <Jason@...> wrote:CII follows the philosophy of Linux development that long-term, Please do try to consider Grsecurity/PaX as not "just another out of treeJason, if CII funded Grsecurity/PaX for a year or two, it would keep the project going, but then what? It is unlikely that CII could fund the project indefinitely, so it would remain an unhealthy project. By contrast, if we funded mainlining the most important parts of Grsecurity, then the thousands of companies and individuals that develop Linux would take responsibility for maintaining it (and improving it) indefinitely. The parts that didn't get accepted could still be maintained out-of-mainline by whatever companies or individuals chose to do so. -- Dan Kohn <mailto:dankohn@...> Senior Advisor, Core Infrastructure Initiative tel:+1-415-233-1000 |
|
|
|
Re: Support Grsecurity/PaX
Jason A. Donenfeld
On Wed, Aug 19, 2015 at 4:43 PM, Dan Kohn <dankohn@...> wrote:
Jason, if CII funded Grsecurity/PaX for a year or two, it would keepThat's a nearly reasonable objection, but I think it's a bit narrow of a vision on how many open projects work. More generally, it's "how can a small but essential open source project be supported?" One answer is by merging with an already funded project, like the Linux kernel itself, that already has plenty of commercial investment, with paid developers. Another, more accessible, answer is -- by receiving funding when it can, using that funding to improve the project, and have those improvements result in more interest, and therefore more funding and grants down the line. It appears that many projects work this way. For example, OpenBSD seems to be supported by generous donations and grants (one of which has come from the CII, IIRC). The longer these projects go, the more likely funding from various places is to pour in. It seems that having CII fund Grsecurity/PaX for a year or two would indeed result in increased momentum, more interest, and therefore a steady stream of funding and support from elsewhere going forward. This, anyway, is the route that most smaller open source projects take, that do not directly have developers who are paid by commercial entities. And on top of this, there's the obvious point: a year or two of funded Grsecurity/PaX work would result in research and practical security solutions that would be a massive benefit to all. I suspect there are additional counter arguments as well that I am missing (others can chime in?), because were it the case that it's not worthwhile to fund something for a year or two as you described, many projects that do now receive funding would become woefully ineligible. |
|
|
|
Re: Support Grsecurity/PaX
Dan Kohn
On Wed, Aug 19, 2015 at 10:59 AM, Jason A. Donenfeld <Jason@...> wrote:
That's a nearly reasonable objection, but I think it's a bit narrow ofJason, I do see your points, and the Grsecurity team is welcome to apply for funding whether they want to upstream their work as patches or keep it out-of-mainline. I am pointing out that sustainability is a major factor that the CII steering group evaluates, and that mainlining the work appears to be a much more sustainable path. Separately, I would encourage you (and them) to take a look at a sister project to the CII census, which is our best practices program. https://github.com/linuxfoundation/cii-best-practices-badge One criteria we might add in the future is around mainlining code. -- Dan Kohn <mailto:dankohn@...> Senior Advisor, Core Infrastructure Initiative tel:+1-415-233-1000 |
|
|
|
Re: Support Grsecurity/PaX
Jason A. Donenfeld
On Wed, Aug 19, 2015 at 5:11 PM, Dan Kohn <dankohn@...> wrote:
Jason, I do see your points, and the Grsecurity team is welcome toHopefully the Grsecurity/PaX developers are actually reading this thread and do consider applying! One last point, and then I'll fade away a little bit. There is a set of projects that are core infrastructure and are worth funding. There is a set of projects that should be mainlined. I think it's entirely reasonable that while these sets might overlap at times, they won't overlap all the time, and that's okay. Of course there are worthwhile kernel projects that are not a part of mainline. And in this case, one of those projects happens to be core infrastructure, and certainly worthy of a CII grant. I play jazz guitar; here's an analogy. Sometimes artists make pop music, and this sells many albums, and everyone is happy. Othertimes artists make jazz music, but nobody cares about jazz, so artists often can't sustain themselves. There are a few artists who do very well though -- say, Pat Metheny or Herbie Hancock. If your musical direction fits with theirs, you might get lucky and they'll bring you on tour (into the mainline!), and then you'll be set for life. But if not, you'll have to struggle. Fortunately there are a huge amount of foundations, institutions, conservatories, patrons, and so forth who help fund talented upcoming jazz artists. Often times these artists live grant-to-grant (shows don't pay well; cds are pirated). With the help of these patrons, some jazz artists have a chance, and eventually become the next big deal. Sometimes they don't become big, but having their artistic voice in the scene remains an inspiration for many other artists, and so these patrons have supported a good cause here too. Now this analogy breaks down, as there are many other odd ways for jazz musicians to make a living. But hopefully the goofy comparison will demonstrate that there are indeed very legitimate grounds for funding non-mainlined kernel code. Okay, thanks for listening; I'll let others take over the discussion from here. |
|
|
|
Re: Support Grsecurity/PaX
Dan Kohn
On Wed, Aug 19, 2015 at 11:32 AM, Jason A. Donenfeld <Jason@...> wrote:
Of course there are worthwhileOne last question for you: could you name other such projects (not necessarily security-related). Nearly every other out-of-mainline project I'm aware of has eventually either merged or died out. -- Dan Kohn <mailto:dankohn@...> Senior Advisor, Core Infrastructure Initiative tel:+1-415-233-1000 |
|
|
|
Re: Support Grsecurity/PaX
PaX Team
On 19 Aug 2015 at 13:37, Dan Kohn wrote:
Hi Dan, On Wed, Aug 19, 2015 at 11:32 AM, Jason A. Donenfeld <Jason@...> wrote:Let's hope you only had bad luck and that's why you aren't aware ofOf course there are worthwhileOne last question for you: could you name other such projects (not any of these ;) http://lttng.org/download/ http://www.sysdig.org/wiki/how-to-install-sysdig-from-the-source-code/ http://open-mx.gforge.inria.fr/download/ http://knem.gforge.inria.fr/download/ http://download.savannah.gnu.org/releases/davfs2/ http://www.openafs.org/release/index.html http://www.asterisk.org/downloads/dahdi https://www.virtualbox.org/wiki/Downloads https://www.jetico.com/linux/installation.html http://zfsonlinux.org/ http://aufs.sourceforge.net/ http://cryptodev-linux.org/download.html http://loop-aes.sourceforge.net/loop-AES/ https://www.rsbac.org/download http://cdemu.org/about/vhba/ https://github.com/vmware/open-vm-tools http://scst.sourceforge.net/downloads.html http://sourceforge.net/projects/xtables-addons/files/Xtables-addons/ As for the requirement of mainlining grsec, it's not possible since we know right off the start that some of the features and other changes are not acceptable at all (say, all the x86 segmentation based code). Second, for the potentially viable pieces this would be a multi-year full time job. Is the CII willing to fund projects at that level? If not we all would end up with lots of unfinished and partially broken features. Third, you're actually wrong as to what is needed for mainline acceptance, it's most definitely not enough to dump the code on them and let the community figure it all out and take care of it. If anything, the exact opposite is true, for any non-trivial amount of code there has to be a pledge for long-term maintenance from the submitters (so regardless where grsec stays, in-tree or out-of-tree, the maintenance burden would still be ours for some years at least, with corresponding need of funding). Fourth, you mentioned the potential futility of not funding grsec indefinitely. It begs the question why it is then worth doing the same for the fuzzing project or Frama-C. I hope noone at CII believes that a year or two of fuzzing and static analysis will exterminate all bugs so what happens after their funding runs out? Or are you suggesting that they can be funded indefinitely but for some reason grsec could not be? In any case, it is your money and decision at the end and we thank you for your attention at least. However it is also clear that we have a different understanding of what constitutes securing the core infrastructure. cheers, PaX Team |
|
|
| 1 - 20 of 42 |