5 ms·

You don't evolve proper security though a million tiny commits. You design it. This is why containers on Linux will probably never have the security that Solari

You don't evolve proper security though a million tiny commits. You design it. This is why containers on Linux will probably never have the security that Solaris or the BSDs have, and this attitude is why. It will never get better until that is rethought, if you're right..

CrLf 10y ago
That's what people used to say about OS kernels, but Linux proved them wrong by evolving the most successful kernel on the planet by almost all measures.
- KingMob 10y ago
  True, but one measure Linux is not the best at is security. By many accounts, OpenBSD leads the pack there.
SwellJoe 10y ago
I don't think I buy this argument; at least, I don't think grsecurity backs up this argument. grsecurity is a big collection of a bunch of different techniques. It isn't a total rethink of the Linux kernel, it is a bunch of patches spread over a large surface area. Some of the changes are far-reaching, yes, but even so, each of the techniques represented in grsecurity could be broken into independent patches. So, why haven't they been? (I honestly don't know why. It's not something I follow closely.)
- zanny 10y ago
  > So, why haven't they been? Grsec upstream argues that only accepting part of the whole is worse than having their patches outside mainline in bulk, because it would give developers and users a false sense of security to only provide some of the hardening grsec does. See this[1] LWN article from 2009, which is a kernel developers post with a comment retort by some grsec developers. [1]: https://lwn.net/Articles/313621/ https://lwn.net/Articles/313621/ The frustration is that we are now seven years later and the situation has only gotten worse - plenty of kernel exploits have emerged, no distro is shipping grsec comprehensively, grsec itself had to stop providing stable releases, and it has become more religious than logical as to why many critical features, like the internal bug prevention functionality, never will be mainlined and will be re-implemented with much less thoroughly tested surrogates.
  - SwellJoe 10y ago
    The irony is that the grsecurity folks complain of limited time and unwillingness to do that work. But, had they done so back then, they wouldn't still be maintaining a huge patchset against the massive moving target that is the kernel. Once a patch is in, it becomes the onus of every kernel developer to not break it. As long as it remains in a silo, nobody has an obligation to not making breaking changes. I don't have a lot of sympathy for that position. I respect the work, but not the hostile-to-collaboration approach.
  - makomk 10y ago
    This is the problem with grsecurity and the security community in general, I think. grsecurity includes things that are relatively safe and beneficial. It also - for example - redefines integer arithmetic kernel-wide in a way that causes massive false positives and kernel panics. Insisting that if you don't want the parts likely to take critical servers down at the worst possible time for no reason, you may as well not bother is ridiculous, broken, and leads to reasonable people just not bothering.
    - digi_owl 10y ago
      > This is the problem with grsecurity and the security community in general Yep. They keep coming across as treating security as something binary. Either it is secure or it is not. And the moment even the most convoluted of CVEs gets published, anything affected is in their view insecure. And thus needs to be taken out of production until a fix has been applied. Frankly it seems quite a number of the most outspoken in the community is not in it for the hohum daily security process, but as some kind of grand joust with "the man". Thus their low water mark for security is "can it stop the NSA".
DDub 10y ago
Why do you believe that they are opposing activities? I can make a journey by helicopter or by walking but the destination is still the same, however as I walk there someone might point me at a better one.
xorcist 10y ago
> This is why containers on Linux will probably never have the security that Solaris or the BSDs have The dozens of changes which you refer to as containers are very much bolted-on to both FreeBSD and Solaris. It would have been nice of that wasn't true, but it's just not realistic to to back to the drawing board netiher for FreeBSD nor Linux to get this single feature. Just think about cgroups, which required some rather deep reworking of several subsystems in Linux, took years to get in place. And that's just one of many pieces that containers can potentially make use of.
- ZenoArrow 10y ago
  I don't know about the security situation with FreeBSD, but the OpenBSD team seem to put security as a central consideration of what they do. http://www.jp.openbsd.org/security.html http://www.jp.openbsd.org/security.html

CrLf 10y ago

That's what people used to say about OS kernels, but Linux proved them wrong by evolving the most successful kernel on the planet by almost all measures.

KingMob 10y ago
True, but one measure Linux is not the best at is security. By many accounts, OpenBSD leads the pack there.

SwellJoe 10y ago

I don't think I buy this argument; at least, I don't think grsecurity backs up this argument. grsecurity is a big collection of a bunch of different techniques. It isn't a total rethink of the Linux kernel, it is a bunch of patches spread over a large surface area. Some of the changes are far-reaching, yes, but even so, each of the techniques represented in grsecurity could be broken into independent patches. So, why haven't they been? (I honestly don't know why. It's not something I follow closely.)

zanny 10y ago
> So, why haven't they been? Grsec upstream argues that only accepting part of the whole is worse than having their patches outside mainline in bulk, because it would give developers and users a false sense of security to only provide some of the hardening grsec does. See this[1] LWN article from 2009, which is a kernel developers post with a comment retort by some grsec developers. [1]: https://lwn.net/Articles/313621/ https://lwn.net/Articles/313621/ The frustration is that we are now seven years later and the situation has only gotten worse - plenty of kernel exploits have emerged, no distro is shipping grsec comprehensively, grsec itself had to stop providing stable releases, and it has become more religious than logical as to why many critical features, like the internal bug prevention functionality, never will be mainlined and will be re-implemented with much less thoroughly tested surrogates.
- SwellJoe 10y ago
  The irony is that the grsecurity folks complain of limited time and unwillingness to do that work. But, had they done so back then, they wouldn't still be maintaining a huge patchset against the massive moving target that is the kernel. Once a patch is in, it becomes the onus of every kernel developer to not break it. As long as it remains in a silo, nobody has an obligation to not making breaking changes. I don't have a lot of sympathy for that position. I respect the work, but not the hostile-to-collaboration approach.
- makomk 10y ago
  This is the problem with grsecurity and the security community in general, I think. grsecurity includes things that are relatively safe and beneficial. It also - for example - redefines integer arithmetic kernel-wide in a way that causes massive false positives and kernel panics. Insisting that if you don't want the parts likely to take critical servers down at the worst possible time for no reason, you may as well not bother is ridiculous, broken, and leads to reasonable people just not bothering.
  - digi_owl 10y ago
    > This is the problem with grsecurity and the security community in general Yep. They keep coming across as treating security as something binary. Either it is secure or it is not. And the moment even the most convoluted of CVEs gets published, anything affected is in their view insecure. And thus needs to be taken out of production until a fix has been applied. Frankly it seems quite a number of the most outspoken in the community is not in it for the hohum daily security process, but as some kind of grand joust with "the man". Thus their low water mark for security is "can it stop the NSA".

DDub 10y ago

Why do you believe that they are opposing activities? I can make a journey by helicopter or by walking but the destination is still the same, however as I walk there someone might point me at a better one.

xorcist 10y ago

> This is why containers on Linux will probably never have the security that Solaris or the BSDs have The dozens of changes which you refer to as containers are very much bolted-on to both FreeBSD and Solaris. It would have been nice of that wasn't true, but it's just not realistic to to back to the drawing board netiher for FreeBSD nor Linux to get this single feature. Just think about cgroups, which required some rather deep reworking of several subsystems in Linux, took years to get in place. And that's just one of many pieces that containers can potentially make use of.

ZenoArrow 10y ago
I don't know about the security situation with FreeBSD, but the OpenBSD team seem to put security as a central consideration of what they do. http://www.jp.openbsd.org/security.html http://www.jp.openbsd.org/security.html