OpenBSD is pretty popular in the security community, and is as FLOSS as it gets.
The underlying problem, IMO, is people. They just don't care about security, they want to deliver working device.
Also it's not clear how many vulnerabilities, used in real life attacks (like DDOS from IoT devices) are in latest Linux kernel? May be problem not with Linux, but with custom software or lack of updates.
OpenBSD project includes stuff like OpenSSH, time sync tools, an SSL implementation, and these are very widely used. Are those devices OpenBSD based though?
Similarly with BSD code, you can just use it and you only need to credit it with the code, so lots of OpenBSD kernel code will be in other systems with no user visible attribution. If MacOS kernel contains OpenBSD code, even big chunks, is it OpenBSD based?
With Linux, GPL means its kind of visible when someone is using it, and GPL encourages you not to integrate your software with it too tightly, so you get an obviously Linux based device with proprietary code on the top. With BSD, you can integrate much more tightly, only ever need to give out a binary blob, and no one would know you were using it.
That said, OpenBSD is kind of server oriented, and FreeBSD would be a more popular starting point for a device, but you might well crib OpenBSD for best practices.
https://www.genua.de/en/solutions.html
One can always strip out what's not necessary. One can also put it in user-mode on top of a secure microkernel with some services running directly on microkernel and some running in OpenBSD. That Kaspersky thought the choices were Linux-based or purely clean-slate shows limited knowledge of what's out there or a personal preference.
Kaspersky has a big-enough ego that I suspect his main goal is just having one of his company's and country's own to brag about. Especially if it ends up better in track record than something like Linux that's very visible albeit not made for security. That will actually be straight-forward if it's a Layer 2 or 3 operating system given how little they need to get right with one.
> The underlying problem, IMO, is people. They just don't care about security, they want to deliver working device.
> This unassuming black box is [...] designed for networks with extreme requirements for data security.
You can claim that nobody will buy Kaspersky's device, or that they did poor market research. But you can't claim that they don't care about security.
Their business is selling antivirus & other software, not security. They have no history whatsoever of building a piece of software immune to code injection by determined attackers. There are companies and academics that build stuff like that. Some were evaluated by pentesters of third parties. Kaspersky has neither that background nor evaluations by expert breakers. We should by default think they don't know what they're doing and the product is insecure until proven otherwise. Like always.
People often mistake "company in security industry selling security products" with "knows how to secure software or systems." They're two very different things.
If they're not liable in any way, then I agree it's nothing more than marketing to call it secure.
https://www.schneier.com/blog/archives/2004/11/computer_secu...
One example would be companies handling credit card information. If you leak a bunch of credit cards, Visa has to invalidate and reissue the cards, and the issuing banks have to spend a lot of money handling customer support. So they're motivated to punish companies when there are security breaches, and to write these punishments into the contracts.
Thanks for the article.
If they hack you, you can loose all your secrets, loose availability of your service in a way that customers leave, loose an election, or be implicated in crimes when your system is a proxy. I've never believed insurance would really compensate for such losses like it would a stolen TV or fire damage to a building.
"If you leak a bunch of credit cards, Visa has"
That's actually a good example. Both the regulatory and lawsuit-related penalties over mishandling PII have led to a boom of vendors offering solutions to make it easier. Still plenty of BS in the market but solutions are there due to incentives.
Then of course, I realized that by "Popular" he meant Mac OSX, Windows, and Linux.
Linux of course, we all know is a security mess because Torvalds refuses to deal with security issues.
Linux provides support for lots of security options, but the project's guiding philosophy is "don't break userland". This is 99% of the time what you see Linus cursing out other kernel contributors for. All of the possible options that Linus could _enforce_ would do just that. Heck, a lot of the security problems and blame have nothing to do with the kernel at all and lie squarely with systemd and how it's implemented. If these are dealbreaker features that you must have, Linux is not the tool for you. Your efforts are better spent working to improve OpenBSD.
"So LSM stays in. No ifs, buts, maybes or anything else. When I see the security people making sane arguments and agreeing on something, that will change. Quite frankly, I expect hell to freeze over before that happens, and pigs will be nesting in trees. But hey, I can hope."
He's typically very critical of security-related changes unless they are a massive improvement. I think characterizing him as "functionality over security" is entirely fair. He's not even wrong necessarily.
Companies that use Linux and need security will either get caught with their pants down or they won't. It's up to their level of preparedness and luck. I wouldn't underwrite that if I were an insurer though.
Those of us that care are already using something else.
I would actually argue that security doesn't depend on any one product, but instead a mindset, methodology, and toolbox. Defense in depth, etc.
So, yeah, blame Linus and others in that ecosystem who do everything but make a solid foundation. Contrast that to OpenBSD for monolithic or GenodeOS for microkernel approaches where they bake security in at various levels. MINIX 3 for reliability levels they achieved 10x faster than monolithic UNIX's did. You get what you focus on. :)
You should be shouting at companies who use it for applications where security is a must. That's where the madness lies.
I use OpenBSD and so should you :)
Due for a hardware refresh soon, and I will obviously be trying it again :)
It's even possible to do modern web stuff on OpenBSD. Erlang and Elixir run on it, as does Postgres. Phoenix framework pretty much works out of the box.
Is this Hacker News or slashdot?
Those get fixed. There are places where the kernel could be further hardened, but would break software.
Most of the security issues that we talk about have to do with process permissions and runlevel. The runlevel of systemd and it's various components is actually my #1 security concern. Has nothing to do with the kernel.
This has been done, but poorly and only for an extremely select few things. KASLR is just one example of a poorly implemented feature that pales in comparison to alternatives (completely subsumed by features in the grsec implementation, for example, since it only randomizes things like .text addresses. Maybe some of that got fixed.) Features like kptr_restrict can easily be subverted by a number of trivial infoleaks unless you back it up with a lot of other protections, etc.
Other things like __ro_after_init for read-only post-init memory have only recently been incorporated into arch/x86 (in the past few months AFAICS, so likely kernel 4.8+ only) since being available for nearly a year on x86 at least. I'm not sure if they fixed the fact __ro_after_init apparently didn't work on loadable modules. grsecurity's implementation is better anyway (allowing remarking variables as writeable for short windows), but I'll concede that extra power relies on KERNEXEC, which breaks some userspace things.
I don't think they botched the LATENT_ENTROPY plugin, at least...
If you actually look at the details, Linux has a pretty bad track record as far as "meaningfully implementing defenses" goes, considering how long this stuff has been around. It's better than literally nothing, I guess.
> There are places where the kernel could be further hardened, but would break software.
Uhhhh, sorry, but you need to do your research. There are plenty of places that could be improved without breaking userland at all, while still mitigating many classes of exploits. PAX_REFCOUNT is one example (a variant of which will probably soon go upstream in some weird way, of course). RANDSTRUCT, PAX_MEMORY_STACKLEAK, KSTACKOVERFLOW, JIT_HARDEN, RAND_THREADSTACK... If you're determined to fix the FPs, the SIZE_OVERFLOW plugin qualifies, too (it occasionally hits false positives, murdering an otherwise legitimate task, but this is a different scenario to a feature outright breaking userspace, and it's caught many bugs and can stop many actual exploits on its own).
There are probably at least a dozen major features in grsecurity that don't have to compromise userspace, and still aren't implemented in Linux, with no equivalent, and no timeline on the horizon. I'm not sure what to take away from this assessment of yours that the only remaining improvements will break things, other than you aren't really aware at all of what the current defense landscape looks like...
Furthermore, I really don't see how that link is relevant, given most of the more recent security features that went upstream, as well as many of the ones that will come in the future -- all originate in part from grsecurity anyway. Apparently, your position is that the kernel developers have already done all they can, and any further improvements else will break userspace, so systemd is definitely totes the #1 biggest problem now, everybody (non sequitur, but whatever). But when I bring up the defenses they could implement, but haven't yet, from the same source of the previous ones -- apparently I'm just doing some irrelevant posturing, or something? I find that funny. Maybe in 5 years when they've poorly ripped off more features and are still behind, you'll be moving the goalpost and saying "Any further improvements would break userspace", and it still won't be true in the slightest. :)
PAX_REFCOUNT is a non-breaking addition that would have stopped CVE-2016-0728 completely, for example, had it actually existed upstream -- it will soon enough, at least, as someone is working on it by porting the grsecurity patches.
The reality is very simple, even if you don't like it: upstream Linux is just bad at meaningful exploit mitigation, in many ways, and they have trailed behind what's possible for literally years. I'd also argue that some kernel developers seem to just have a complete, fundamental misunderstanding of what the point of the mitigations are, which is damning. One guy on the dev list argued with Kees Cook that people shouldn't bother with this shit, because we don't need to help "those bastards with proprietary modules be more secure" (Kees works on Android, so proprietary modules are just a fact of life, grsec improving their security simply being tangential), or help the people with out of tree kernels like the grsecurity team. It had apparently never dawned on him that mitigation tech could stop exploits that appear in the future. Like PAX_REFCOUNT stopping an exploit that would only appear in the future as time went on. This is mind-blowing as a position, for a developer of what is ostensibly one of the most complex projects in the world.
Anyone who has followed the grsecurity project for a while is pretty well aware of why they don't bother with upstream, and aware that upstream mostly reinvents their work, poorly. In any case, the given link is still irrelevant.
I'm going to go out on a limb and say you don't actually know much about modern memory corruption defense, or the landscape of modern kernel security and how it has moved forward over time, if this non-reply is your only answer to the examples I listed...