User: Password:
Subscribe / Log in / New account

Yama: not so fast

Yama: not so fast

Posted Aug 5, 2010 21:45 UTC (Thu) by spender (subscriber, #23067)
In reply to: Yama: not so fast by Cyberax
Parent article: Yama: not so fast

Grsecurity coexists fine with containers. Yes, containers are a better choice than chroot (though not the best choice). The benefit of containers however is only realized if they're actually used. Grsecurity's chroot restrictions are still useful as it passively adds protection to applications that for portability or other reasons are using chroots as a security mechanism. Most grsecurity features are written to work in a similar passive way. The idealist would say "convert everything from using chroot to using containers" but this hasn't happened. In fact, based on a recent study of pie/ssp/fortify_source usage among distros, it's clear that the mechanisms we've had for years aren't being fully utilized in any distro. It's poor security strategy to protect based on how you wish things were in the optimal case on your end, rather than based on what the situation is in reality.


(Log in to post comments)

Yama: not so fast

Posted Aug 5, 2010 22:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm of opinion that too much security == no security.

My systems run a fair amount of legacy code, but I was able to migrate all of it to LXC. It's even feasible to isolate it even further using Xen/KVM now, because hardware is so damn cheap. So adding protections to 'chroot' just isn't worth it, IMO. Actually, it should be possible to reimplement chroot on top of containers.

Some features of grsecurity would better be generalized. For example, IP address tracking should be generalized to other types of metadata (what if I use IP-less protocols?).

Personally, I'd like to see some of features of grsecurity in the mainline kernel. Though I don't really care about a lot of other features...

Yama: not so fast

Posted Aug 6, 2010 11:56 UTC (Fri) by nix (subscriber, #2304) [Link]

Is it time for me to note that glibc bug 7065, providing a patch adding -fstack-protector support to all of glibc (bar small parts of the dynamic loader), was rejected out of hand with no reason given (which made it impossible for me to respond to whatever Ulrich's concerns were: I suspect the real concern was "I didn't think of it", as there have been several occasions now when he has rejected code from others only to reimplement the feature himself and insert it into glibc without crediting the original author), and how bug 7066, which used that support to find a place in *glibc's own test suite* where strtold() was induced into an apparent stack overrun, has now gone one and a half years without any attention?

So even when we provide patches to allow existing mechanisms to be used in pervasive things like glibc *and prove that they are useful*, they are still rejected. *sigh*

(That was the last time I was tempted to contribute to glibc at all. Life is too short to work with maintainers with attitudes like that. The stack-protection patch still works, if anyone wants a version against eglibc head.)

Yama: not so fast

Posted Aug 9, 2010 21:09 UTC (Mon) by ilmari (guest, #14175) [Link]

Have you tried submitting your patches to the eglibc folks instead of directly to glibc?

Yama: not so fast

Posted Aug 10, 2010 5:58 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

eglibc has a stated goal to be binary and source compatible with glibc. So not too much room for many changes.

Yama: not so fast

Posted Aug 11, 2010 23:46 UTC (Wed) by nix (subscriber, #2304) [Link]

Yeah, but -fstack-protector doesn't break either of these. I think it would work. I just need to switch jobs to one that isn't totally in bed with Microsoft (they're *proud* of it) and is willing to sign the disclaimer first :/ (they said they'd sign, and said they'd sign... and didn't sign).

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds