|
Post by rustleg on Feb 15, 2012 15:21:37 GMT -5
I have been pondering a few questions about security updates. Maybe the answers could be found from the information on the web site, but I'm afraid I couldn't see them.
All software these days seems to have to have security updates because of flaws found in the code - obviously things like Windows and Adobe Flash come immediately to mind but even the most secure systems such as BSD need patching at times since no code can be guaranteed bug free.
So I was wondering how this is maintained within KNOS and its component applications as vulnerabilities are discovered.
One particular thought is about the frequency of updates to browsers. I've used Firefox and it currently seems a new version is released about every week. Also Chrome (maybe not Chromium) has silent updates on a regular basis. Does this mean we should wait for updates after booting the KNOS CD before using the system?
Whilst on this subject can I also mention that I understand the next version of Windows will require a signed boot process (there's some concern that new Windows machines may be manufactured in such a way that they are not able to be booted with Linux, etc). So what is Microsoft concerned about that could invade at an early stage? Is this the potential of some malicious code in the Master Boot record? I guess this doesn't affect a DVD bootup since I suspect that no code on the hard disc is invoked. So perhaps it's down to whether a malevolent person could plant something in the BIOS. (Huh, I think my paranoia has overflowed with this thought!)
Having said all this, I'm not too concerned since my primary use is to access banking sites by booting a DVD afresh each time, but I'd still like to know how updates are handled, since I imagine I'll need to burn new DVDs from time to time. I know there are other vulnerable parts in the chain such as rogue certificates, bad DNS records or even hacked banking sites, but if I do my best to limit the opportunities I can accept the residual risk. However small this is, the potential for exploits are the price we pay for running a modern OS.
|
|
|
Post by Kevin McAleavey on Feb 15, 2012 20:37:07 GMT -5
I have been pondering a few questions about security updates. Maybe the answers could be found from the information on the web site, but I'm afraid I couldn't see them. All software these days seems to have to have security updates because of flaws found in the code - obviously things like Windows and Adobe Flash come immediately to mind but even the most secure systems such as BSD need patching at times since no code can be guaranteed bug free. So I was wondering how this is maintained within KNOS and its component applications as vulnerabilities are discovered. One particular thought is about the frequency of updates to browsers. I've used Firefox and it currently seems a new version is released about every week. Also Chrome (maybe not Chromium) has silent updates on a regular basis. Does this mean we should wait for updates after booting the KNOS CD before using the system? Whilst on this subject can I also mention that I understand the next version of Windows will require a signed boot process (there's some concern that new Windows machines may be manufactured in such a way that they are not able to be booted with Linux, etc). So what is Microsoft concerned about that could invade at an early stage? Is this the potential of some malicious code in the Master Boot record? I guess this doesn't affect a DVD bootup since I suspect that no code on the hard disc is invoked. So perhaps it's down to whether a malevolent person could plant something in the BIOS. (Huh, I think my paranoia has overflowed with this thought!) Having said all this, I'm not too concerned since my primary use is to access banking sites by booting a DVD afresh each time, but I'd still like to know how updates are handled, since I imagine I'll need to burn new DVDs from time to time. I know there are other vulnerable parts in the chain such as rogue certificates, bad DNS records or even hacked banking sites, but if I do my best to limit the opportunities I can accept the residual risk. However small this is, the potential for exploits are the price we pay for running a modern OS. You'll be pleased, even relieved to know that we've been pondering the same questions before creating KNOS, and security was foremost in the design. The reason why KNOS is sold on a "subscription" basis is because we foresaw the potential need to replace the existing release when a serious security issue arose. In fact, a few days after the first release of KNOS 8, we had to replace the existing distribution as the result of a flaw in BSD's "bind" utility that could result in DNS poisoning. Fortunately only about ten people had copies that had to be replaced at that point in time and they were notified that they had to replace their existing copy and download a new ISO. Such notifications would appear on the KNOS home page that comes up in your browser on the right hand side. As for Adobe Flash, that's one we watch very carefully along with the browsers for any need to replace. Sun's Java became so troublesome that we replaced that with OpenJDK and a plugin called "IcedTea" which is very safe and heavily limited. Adobe's PDF viewer is another petrie dish that required replacement owing to its continuing issues with PDF files. That was replaced with Evince in KNOS which doesn't permit links, scripting or require direct connection to our kernel as is the case with OpenJDK. Those replacements solve the potential for exploitation. So this left the necessary Adobe Flash as the last remaining danger in KNOS, and for that we came to a special solution in that Flash is wrapped inside a sandbox called "NS Pluginwrapper" (which also wraps all other plugins into its own virtual machine) and then that gets placed into yet another sandbox called "npviewer" which finally runs inside the final sandbox for the browser called "firefox-bin" ... three levels of sandboxing, none of which runs directly in the kernel except for that last "outer sandbox." As a result, anything that breaks inside any of those sandboxes will solve the problem by breaking its own container, causing the browser to completely crash. When something untoward occurs in Flash itself, we make Flash crash and that happens SO often that we have that red button on the top window there called "Flashfix" which resets and cleans up the flash sandbox locations and memory assignments so that a new instance of Flash can start again. We watch each and every security announcement for each and every product included within KNOS as well as BSD itself looking for, and TESTING any reported security incidents, and if necessary, will issue a new KNOS if any exploits are able to be successfully used against KNOS. That's always been our policy and our design has always taken into account that similar incidents have been going on for quite some time now against other operating systems. That's also why we consciously designed KNOS to circumvent these weaknesses in the first place. As to the browser updates themselves, I've been extremely disappointed with Firefox, and to a lesser degree with Chromium. The new engines they are using just seem to get less and less robust with each new version and have literally been sprouting more and more problems. I'm seriously considering reverting back to the Firefox 3 branch (which is still maintained) because although it may run slower than the new ones, it's at least more secure than the new ones. Eventually Mozilla might get their act together, but right now they're very disappointing in the number of bugs and memory leaks in their current versions. Chromium is also a pig, but at least it works somewhat better. But there's been nothing so far in either branch that has turned out to be a problem with KNOS' sandboxing that has required a "red alert" and outright replacement. Yet. As to Microsoft, what you're hearing about is "UEFI boot" and one of the major reasons behind KNOS 9 is the ability to support the new UEFI standard, along with the ability to do a GPT boot under what is called the "GPART file system." Apple has already been doing this in OSX for a couple of years now. It requires a radically redesigned bootup, and some KNOS users have unfortunately tripped over that with the first beta release. We've got that fixed already for the next release and those who have machines that will *require* UEFI signatures will be offered a special version of KNOS for those machines with a proper GPTID boot sector in KNOS. The current version of KNOS however WILL boot on those machines, although some early versions that have been manufactured will require going into BIOS and turning off UEFI. After objections by the Linux community (who weren't really ready for this) Microsoft is now encouraging manufacturers to resolve that so the choice will be automatic based on what you're booting into for future machines. An important thing to bear in mind though about KNOS. We don't USE BIOS! All BIOS does for KNOS when it is started is to point to where the bootable drives are by hardware address. Once KNOS finds its own boot sector, all polling and configuring of hardware is done by KNOS internally and KNOS no longer needs BIOS beyond spitting out locations of hardware addresses. From there, KNOS polls the hardware itself with our own code and configures the hardware based on our own internal kernel information. Thus, any "virus" contained in BIOS or video card or other hardware that can be "flashed by firmware" does not get read by KNOS at all. We even include our OWN firmware uploads from within KNOS to wifi cards, video cards, printers and other devices that require external firmware so that even if any of these were to be infected with a Windows virus, we end up dynamically overwriting such in KNOS. And I suppose no need to mention that any Windows virus wouldn't be able to run in KNOS' kernel anyway since our code is not at all like Windows, OSX or even Linux. But all of this is the reason why KNOS takes so long to boot, because every time KNOS is started, it has to find and configure and load hardware on its own and doesn't listen to anything that's already coded in any machine it runs on. KNOS trusts no one. About the only thing that I see as an actual concern here though would be rogue certificates, or that your internet provider has had their DNS cache poisoned. However, none of those situations would be resolvable on your machine no matter what you were running, even KNOS. But these two items seriously are the only concerns that remain that we cannot solve with KNOS. That kind of limits the amount of risk susbtantially though. And here, as far as banking goes, there's another solution that few think of that would actually work ... instead of using DNS to go to your bank, learn the proper IP4 octets and input the correct numerical address to go to the bank! I'm sure that memorizing xx.xxx.xx.xxx/ would be worth the effort if the paranoia is strong.
|
|
|
Post by rustleg on Feb 16, 2012 5:10:42 GMT -5
Great response Kevin - I hope other people find it as useful as I do in understanding how good KNOS is. ...<snip> And here, as far as banking goes, there's another solution that few think of that would actually work ... instead of using DNS to go to your bank, learn the proper IP4 octets and input the correct numerical address to go to the bank! I'm sure that memorizing xx.xxx.xx.xxx/ would be worth the effort if the paranoia is strong. I tried that once with my bank and asked them for the IPs to use - they refused. I presume this is because they use several to balance the load. Also I don't think they want to deal with people who know enough to want to do this - they would prefer to deal with the large majority who don't know any better. That is until their fraud payouts are bigger than the money they save by getting the customers to do their own banking. Maybe I could monitor the actual IPs used and try to use them direct. Also no reason why they shouldn't be set up as bookmarks.
|
|
|
Post by Kevin McAleavey on Feb 16, 2012 17:57:10 GMT -5
Great response Kevin - I hope other people find it as useful as I do in understanding how good KNOS is. I tried that once with my bank and asked them for the IPs to use - they refused. I presume this is because they use several to balance the load. Also I don't think they want to deal with people who know enough to want to do this - they would prefer to deal with the large majority who don't know any better. That is until their fraud payouts are bigger than the money they save by getting the customers to do their own banking. Maybe I could monitor the actual IPs used and try to use them direct. Also no reason why they shouldn't be set up as bookmarks. Yep ... if they won't give you a hard IP to hit up, then they're leaving you to potentially fall victim to somebody else's DNS cache poisoning. Not much can be done there aside from finding another bank that's sufficiently concerned about the issue willing to at least give you the gateway IP so that your first hit is definitely inside their site. Sorry to say, not much one can do in that circumstance although DNS poisoning usually occurs by poisoning the DNS configuration at the user's machine. That's why Windows viruses such as "FakeDNS" and "DNSchanger" are so popular amongst the " bad guys" ... those won't work on KNOS either.
|
|