Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kaspersky OS

eugene.kaspersky.com

Post reply on HN
Print view View original

241–250 of 290 posts

Re: Kaspersky OS

#241

Post by nickpsecurity »

bonzini wrote: post #233
mmalone wrote: post #163

Earlier quoted context omitted.

Linux doesn't scale down very well though. I really don't need the full Linux API for a lightbulb. Most embedded OSs are microkernels for this reason. If any mega-trend has a chance of unseating Linux and generally disrupting the OS space it's IoT.

A lightbulb will have an RTOS, not a microkernel. While microkernels provide utmost isolation between processes and well-defined primitives for communications, a lightbulb might not even have separate supervisor and user modes.

A lightbulb won't even have a RTOS. It will be a state machine or series of them in C language on cheapest MCU imaginable. Probably 8- or 16-bit. That keeps the cost at nickles or dimes.

Re: Kaspersky OS

#242

Post by nickpsecurity »

krylon wrote: post #33
metafex wrote: post #14

> All the popular operating systems aren’t designed with security in mind Kaspy OS runs on a switch, and they're talking about popular operating systems, so in the same vein, OpenBSD wouldn't be a popular secure OS for e.g. routers? But hey, I'd be really happy if they based it on seL4 and formally verified their security concepts. That would be a real game-changer. OTOH I'm really sceptical until they provide any re…

Also, in a microkernel-based system, verifying the kernel itself is but a start. To make a verifiably secure system for network infrastructure and IoT-devices, you need, at the very least, a provably correct IP stack. Want a nice web interface? Now you need to verify the HTTP server, too. Want to talk to other devices? You probably want a DNS resolver. And so forth... Simply signing code and having the OS refuse to e…

You do. The good news is that it's not a lot of components. A good example would be what's going on in DO-178B space that requires strong verification albeit not necessarily formal. They subset things like networking standards then build partitioning and quite-static design into them. Resulting ones still have decent amount of features:

http://www.lynx.com/lcs-lynx-certifiable-protocol-stack/

The minimum I've seen are a few drivers, bootloader, partitioning filesystem/storage, partitioning networking, and language runtime (esp Ada or today Rust). That's not a lot to build given what's already available in FOSS or embedded. More than just a separation kernel but not much more.

Re: Kaspersky OS

#243

Post by nickpsecurity »

floatboth wrote: post #202

A lot of OpenBSD mentions here, but what about MINIX 3? It's so underrated and ignored :( They made a nice microkernel-based UNIX-like system with a NetBSD userspace. Also, Redox is switching to a microkernel architecture...

re MINIX 3. It's not made for high-security. It's about high-reliability. Safety is usually a precursor to security but security can take a lot more. The core has to be designed for it like Genode is doing.

re Redox. It's a nice project I've praised before. It's an alpha work-in-progress, changing rapidly, and unclear how much of its design is truly for security. A trimmed OpenBSD is probably a safer bet than it so far given the staggering amount of review that went into it. Rust's features and a microkernel only prevent so many kinds of problems.

Re: Kaspersky OS

#244

Post by nickpsecurity »

MichaelBurge wrote: post #232
nickpsecurity wrote: post #226

Earlier quoted context omitted.

There's little to no liability in most situations. Security experts have been pushing for liability for a long time as a solution to this. Basically, we want a minimum level of responsibility like what exists in safety-critical industries. Schneier has a brief essay that explains it well: https://www.schneier.com/blog/archives/2004/11/computer_secu...

I suppose the other economic option is insurance. That works best in general with a lawsuit, but certain companies that would suffer great damages with a breach should be motivated to buy insurance. 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 supp…

"I suppose the other economic option is insurance"

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.

Re: Kaspersky OS

#245

Post by nickpsecurity »

Animats wrote: post #10

Somebody finally did this. Good for them. Unbreakable boxes for DNS, BGP, and routers will be a good start. Those boxes don't need to do anything else, and contain no user data. Looking forward to hearing more about their OS.

"Finally?"

Did you miss HYDRA, Secure64, or the MILS/DO-178B groups building certified, partitioning middleware?

https://news.ycombinator.com/item?id=12988808

http://www.lynx.com/lcs-lynx-certifiable-protocol-stack/

It's been going on. The OEM's just aren't buying or cloning any of it outside a few. Many of those that do are going out of business because customers vote against security with their wallet. Even when the cost isn't much more. Outside of pure defense contractors, one of only ones making it is Genua selling OpenBSD-based solutions in Layer 2 and 3. Assuming they're still OpenBSD-based.

"Looking forward to hearing more about their OS."

I agree with this and your view on the need to develop more bare-bones, clean-slate solutions for these kinds of services. If we're lucky, Kaspersky's will both be more secure than Linux-based products and have convenient, affordable licensing than forerunners to get major adoption. However, as you probably know from high-assurance, a company with no history of making a system secure against strong attackers will probably fail to do so with its products. That's my default anyway. So, I also look forward to the details to compare and contrast against competing solutions in medium- and high-assurance spaces.

Re: Kaspersky OS

#246

Post by krylon »

Vendan wrote: post #162
this-dang-guy wrote: post #131

Earlier quoted context omitted.

The biggest issue with Windows isn't its inherent security, it's the way it's used. Most users run everything with super admin rights. Most developers require that for installs. OSX is right behind it, with a culture of laxness that undoes most of the benefits the designers tried to give them.

I've run into "security software" for domain computers that required every computer to have the same local admin password... and for it to be enabled on every computer.

Hehe, I once saw a corporate network where the root password on all Un*x systems was ${vendor}xyz, i.e. sunxyz for a Solaris box, ibmxyz for AIX, and so forth. I hope at least they disabled root login via ssh.

Re: Kaspersky OS

#247

Post by this-dang-guy »

nickpsecurity wrote: post #239
this-dang-guy wrote: post #175

Earlier quoted context omitted.

Yeah, I went down that rabbit hole a bit. The point is - it's about the only way to do a real actual code audit on what your processor is doing.

You can pay a company to fab a Leon3 or Leon4 for you. Leon3 is GPL with eASIC already supporting it in their Nextreme's. There's also Rocket RISC-V core that was fabbed on a 45nm SOI process. Do it on the same node with anything extra an external, swappable component on the PCB for supplier diversity. Additionally, Cambridge has FreeBSD running on a capability-secure version of 64-bit MIPS on FPGA's. It's called CHE…

Unlikely to be much unless there's a prevailing need.

I think it's easier to do deep packet inspection if you're that concerned, honestly.

Re: Kaspersky OS

#248

Post by this-dang-guy »

nickpsecurity wrote: post #237
this-dang-guy wrote: post #144

Earlier quoted context omitted.

Ahem http://rationalviews.com/t/presentation-on-fully-open-source... You could go into that rabbit hole. I'd recommend against it... I lost days reading all the docs and playing with this

Ahem what? That proves nothing. Here's a write-up I did on verifying hardware against subversion. https://news.ycombinator.com/item?id=10468624 It's a hard problem. That's why DARPA is throwing tons of money and brains at it right now. Also why a number of defense contractors maintain their own fabs and packaging plants despite the technology aging.

And your point is? It's not a hard problem. You either trust your fabricator and tools, or you don't.

End of freaking story. If you don't, and/or you can't throw a fab plant at it, your options are limited. You can read all the docs on the open CPU stuff (as far as that goes), you can literally do everything from scratch, but unless you're a Nation State or a massive company, you're pretty much wasting your time.

/edit: I don't mean this as a criticism of your writeup (where you basically state the same thing), or even some of your other comments (where you state much the same thing). It's literally an issue where there are VERY few people in the entire world capable of doing cutting edge processor design, coding, and implementation. They cost phenomenal amounts of money, and even with the money, people, and the best of intentions - a motivated nation state actor can muck things up.

The only real defense we have, as regular people, is to basically see if anything we own is misbehaving. Even that is a specialized skill set and time investment beyond what most folks are interested in committing.

Re: Kaspersky OS

#249

Post by this-dang-guy »

krylon wrote: post #246
Vendan wrote: post #162

Earlier quoted context omitted.

I've run into "security software" for domain computers that required every computer to have the same local admin password... and for it to be enabled on every computer.

Hehe, I once saw a corporate network where the root password on all Un*x systems was ${vendor}xyz, i.e. sunxyz for a Solaris box, ibmxyz for AIX, and so forth. I hope at least they disabled root login via ssh.

I've not seen that, but I have seen one where the root password was the vendor who supported it - like capgem123 ibm123 etc.

Not quite as bad, but still pretty weak.

Re: Kaspersky OS

#250

Post by this-dang-guy »

nickpsecurity wrote: post #227
grzm wrote: post #213

Earlier quoted context omitted.

Yeah, I was wondering about that, too. Granted, the BSD base is arguably one step removed from Apple (as that was NeXTSTEP, which Apple acquired), and both Darwin and OpenStep are open source. Apple continues to release the source of some of their software.[0] According to the "Myths" page at FreeBSD, "FreeBSD 9.1 and later include a C++ stack and compiler that were originally developed for OS X, with major parts of…

"so it hasn't completely been freeloading." That's Clang/LLVM compiler that gets them off GCC's GPL codebase. It also allows them to keep more extensions proprietary if they choose. It's been beneficial to the OSS community but I'd say it's barely altruistic. An exception rather than the rule. " The "how Apple treated BSD" phrasing sounds like there is more active bad treatment rather than not contributing enough" He…

You are correct, I should have been more clear in my phrasing.
Post reply on HN