Hi Balint, Bálint Réczey wrote: > The upstream project I'm most involved in is Wireshark where we try to > employ most of the state of the art techniques for improving code > quality but I think the Wireshark project is in much better position > than most other projects. Thanks to dedicated team and community we > can build on 3 different static analyzers, CI buildbots on 6 different > platforms and tests fuzzing with Valgrind all day long. > For the projects lacking this infrastructure Debian can provide build > tests for many platforms and could also be the project where > additional hardening flags could catch security problems. Expecting > all upstreams to be able to keep up with latest security best > practices is not realistic to me. A trivial example is the case of > dead upstreams.
That's certainly the way on how to approach proper security testing within an upstream project, but it does already take some effort only for one project, imagine how much effort it takes doing this for e.g. all debian packages. As I said it's not simply running audit tools on code and binaries, the actual work is figuring out what is to be done if there are warnings and how this translates to (upstream) code. I'm the last person to speak against security improvements within a linux distribution. But it just does not seem to be a feasible or a realistic task. > It is true that stack canaries can't catch everything, but it detects > a fair share of attacks. Note that -fstack-protector is used by > default for all packages in Ubuntu, Fedora, ArchLinux, OpenBSD and > others: > http://en.wikipedia.org/wiki/Buffer_overflow_protection I'm aware of this. Some of them also implement PaX (or W^X in OpenBSDs case). That said, it will probably improve security a bit, in particular against skiddies just running scripts of the web. But any serious attacker may circumvent stack canaries anyway. Thats not deep magic anymore. There are now automated tools to make ROP/return-to-lib-c attacks particularly easy to pull off (finding ROP gadgets automatically, even writing weaponized exploit code and so forth). See: http://cseweb.ucsd.edu/~hovav/dist/rop.pdf https://en.wikipedia.org/wiki/Return-to-libc_attack http://phrack.org/issues/59/9.html > The new architecture would target hardening the toolchain as the first > goal and I consider this is doable with reasonable effort. Other parts > like SELinux and Grsecurity-enabled kernel > can be done (and are already being developed) for all architectures > independently from the porting effort. Now shipping grsec is a really good idea. I'd like to see that as well. SELinux is just a PITA with no added security functionality except security by obscurity. I know there are people seriously making a living of implementing SELinux policies for customers - I still do not get why. Everytime somebody mentions SELinux I point them to this nice pic that pretty much hits the nail on the head: https://grsecurity.net/~spender/pics/mac_security_sesamestreet.jpg :) Nowadays almost every guide to set up some kind of software for e.g. RHEL/CentOS/.. mentions to `setenforce 0` first. And that's what systems engineers do in production. A couple of years back I've played extensively with TrustedSolaris and TrustedBSD (same idea as SELinux) and SELinux. It's a nightmare. For a multiuser system running a couple of servies you will spend not weeks but months to define a policy that keeps the system in a usable state. This is just unacceptable to most - it's not however - to the people that design, implement and use such paranoid policy systems: NSA and the intelligence community in general. I like to think people get rich of writing policies for those people with no added benefit for security, it amuses me. Beautiful codebase though. Aaron
signature.asc
Description: OpenPGP digital signature
