KNOS

I noticed earlier that one of the mods here was working on KNOS, a "reasonably secure" FreeBSD derived OS for workstations. It looks to go more for standard MAC and exploit mitigation stuff than does Qubes, and the hardware requirements are more sane. Also appears to include some kind of copy-on-write sandbox.

The info page: http://knosproject.com/info.html "Malware and exploit-proof" sounds very optimistic to me, but it does look pretty good compared to your generic Linux distro.

Any thoughts on this? Experiences?

BTW, this OS is proprietary, but not terribly expensive (even with the subscription model) assuming it works as indicated. OTOH the license indicates no warranty. Not sure how to take that.

P.S. A question for the developers. From the info page:

This doesn't quite sound right to me. As long as the BIOS is what's starting the bootloader code, couldn't it tamper with that and by extension with the kernel?

Furthermore, couldn't the modified BIOS do something like:
- Creating an address for a fake piece of hardware
- Having it point to a region of memory containing hostile code
- Attacking the kernel when that region is accessed?

I could see an OS being resistant to many "generic" firmware rootkits, but I don't see how it could be made entirely immune to a custom-designed firmware rootkit, on normal x86 hardware. Am I wrong about this?

 

BSD isn't the most secure OS available, Linux is more easily secured IMO, by far - but I'm sure a custom BSD could be quite secure as well. BIOS infections, yeah, cool I guess, but are we too worried about BIOS? You'd need root for that anyways. If they access the kernel, meh, idk, should be able to attack BIOS unless you're buying custom hardware that enforces this as well.

Nah, it didn't though. Get me a full written proof of this, and give me years and a team to analyze it, and I'll believe that.

Here's the thing. The project sounds cool, and I like the idea of a user-oriented secure desktop OS, I love it, and they've probably done a great job. They just need to be honest about security - I don't trust security software that says it'll protect against APT without offering significant proof, it often means their reaction to security vulns is terrible (look at OpenBSD for one example, or tons of other security companies who hate when someone exploits their code) and they're being unrealistic.

The idea of a highly customized and secured environment is very cool. Again, a nice idea. Just wish they'd be a bit more honest about it all.

Again, this isn't custom hardware. How can you ensure this? I don't believe that it's possible. If it used some kind of secureboot/trustedcomputing devices, perhaps it would be hardened against this.

I don't want to tear into it right now. I see a lot here that's nice but none of this seems so horribly difficult to bypass. No shared libraries for one thing.

Oracle's version is actually patched much faster, and is based on OpenJDK as a framework, which is why they share vulns/ design bypasses.

I see a lot of stuff here. IDK. I'll refrain from commenting further.

 

Hi there! I'm the actual coder and architect for KNOS, be happy to answer anything you'd like.

In our explanation, we tried to be as non-technical as possible. I'm going to try to remain as non-technical as I can here, but I guess I need to explain a little bit about what BIOS contains, how it works, how KNOS' BSD core code works in using the information contained in BIOS, and what is and isn't possible. Here's hoping I don't get too confusing here, it IS complicated.

When a machine is booted, BIOS wakes up all the hardware on the motherboard, and then sequences through any bootable devices connected to it. Usually a default is selected, or the user chooses "boot from DVD" or "boot from USB" instead. BIOS then points the next sequence to that chosen device whereupon control is passed to the boot sector on that device. Our boot sector is unique and different from any other.

We don't support Grub or other third-party bootloaders either, the KNOS boot record must be dedicated, and we use our own file system. If there's anything untoward, and it fails to locate itself at its own value of zero (due to a shift caused by something else already there) it will stop booting at that point and just sit there. That would get anyone's attention because the first boot stage would fail hard right there.

From there, we have two more steps before we even start booting, again checking the locations and verifying that we are booting KNOS and not anything else. From there, a frozen boot image is loaded and because KNOS is a memory-only system, before it continues, it then initializes the totality of RAM memory from top to bottom with zeroes and then begins filling it with its own kernel which is another compressed image.

From BIOS itself, all we pick up is slot addresses and interrupt numbers. As KNOS boots, it then queries each device address it received from BIOS (at this point, we don't need BIOS any longer) and then uses its internally contained hardware drivers to query each device (drives, video, sound, etc) and proceed to "attach" to them with its own internal code. Any "ersatz devices" even if they are present, won't have one of our drivers which know about it and therefore, any fake device would not be attached to as an "unknown" ... any such would be reported in our boot log. Since memory is cleansed, anything sitting there previously would have been overwritten.

Since the kernel, drivers, and even the userland applications are all frozen inside a read-only, compressed and encrypted "lockbox" then it's not possible for those to be tampered with at any time. For those who know of me from back in the BOClean days, I know all the tricks, and the design accounts for them. Reality though is that any such firmware rootkits would be looking to exploit Windows or Linux, and would only work when run under those OS'. They'd have to write one specific to FreeBSD and stuff it in there, and even if they had done so, KNOS wouldn't read it anyway because we only gather hardware address information and then at a later time, attach our driver to it and use our own code to talk to all the hardware.

So not wrong, it's been very rarely done for other platforms, but it would be extremely difficult to manage doing so with KNOS owing to the way we considered all of this in our original design five years ago. Do feel free though to ask more, only too happy to try to explain how this works.

 

To Hungry Man: Hey, guy!

I usually don't hang out here much given that "All things Unix" pretty much means Linux, and sadly over the years, some Linux folks have gotten to be like OSX folks used to be before "Flashback" got their attention and made lots of money for the usual AV suspects.

I sincerely don't mean what I'm about to say in a negative way, my first love was Slackware 2.0.8 and I still have my Walnut Creek CD from back in the 80's and have followed Linux through Caldera, Red Hat (pre-IBM) and all the permutations since. I don't believe in forming religions around operating systems myself, but found that BSD was a whole lot saner for my purposes owing to the rigid structure and reliability of how it's done. Linux is great for hobbyists and diddlers, but in the end stability and foolproof security is critical for non-geeks, and for us starting with BSD was a much saner way to ensure that our customers don't need to play with configuration files and try to figure out if they need to YUM or APT-GET or something else. Right or wrong, Linux has just not clicked with ordinary users, especially given how it changes so often for no good reason to their minds. People like stability.

KNOS was created very deliberately for those who never should have been given a computer in the first place. The ones who are always managing to infect themselves with the very best AV's, firewalls and instructions on advice on how to stay secure. Those clearly aren't the kind of folks who hang out here or on other security sites, therefore I've tended to not be too chatty about it. For those who knew us back in our NSClean, IEClean and BOClean days, you know how we went out of our way to design our stuff to be simple yet effective, unintimidating and friendly. Same here. KNOS is designed to be simple, friendly, and most importantly, reliable. Something you can just use and it just works. That's what we do although our primary business is mass production of custom installs for those people in the corner office who just keep infecting the entire company. A "consumer product" wasn't our original intention.

So let's get down to a few specifics, as before, be happy to clarify further if you'd like. We based KNOS on BSD for a number of important reasons, not just the better security. First off, BSD isn't polluted by GPL which means that it's extremely easy to incorporate proprietary code for our customers that would never get signed off on for Linux. That's critical for business customers and military customers who are stuck with Windows because of limitations from their vendors under GPL who just won't allow it. We consider getting off Windows as the highest priority as do our customers.

With respect to the security differences between the FreeBSD base on which KNOS is built vs. Linux, these two links pretty much demonstrate the difference from a security standpoint:

FreeBSD:
http://www.exploit-db.com/search/?a...g_id=0&filter_port=&filter_osvdb=&filter_cve=

Linux:
http://www.exploit-db.com/platform/?p=linux&pg=65

Further, because Linus insists that Linux is only the kernel itself, and the rest of userland is not his concern, there is no real accountability for the complete environment. Further, each distro seems to maintain their own hodgepodge of incompatible code. In BSD world, there may be a paucity of options compared to the far wider array of Linux apps, but everything in BSD world is vetted, verified and the integrity of even third party apps is tightly controlled and monitored. What makes BSD very difficult though for ordinary people is that while there are a number of application packages which can be downloaded and installed, they tend to be old and out of date, many just plain obsolete and incompatible.

Working with BSD can be a nightmare for geeks, and certainly beyond the grasp of ordinary users. For best results, every single application is best compiled by hand from the source code and just swapping out a new version of Firefox can mean WEEKS of compiling all sorts of dependencies. We handle all this here at the KNOS Project and provide a finished product ready to go with all proper security handling and auditing and the end user has to do nothing at all other than boot up and use it.

As to the three years, it's been five now. And in the past five years since the first release of KNOS, there has not been ONE single security incident in delivered product. And we have some mighty particular customers, some with really big guns.

We came VERY close to an actual security issue about a week prior to our release of KNOS 9.0 last summer involving an Intel CPU hardware flaw involving http://threatpost.com/intel-processor-sysret-vulnerability-affecting-some-64-bit-systems-061812/ (SYSRET and ROP) which BSD fixed immediately. It's still vulnerable on Windows. We were days from shipping KNOS 9 when it was discovered, and that fix delayed release by a couple of weeks.

As to Oracle's mess, KNOS has stuck with the JDK6 tree since that's all our customers required. OpenJDK's code was clean, and we ship the IcedTea Java web control which runs in virtual memory in a memory-only file system inside a VM. Nothing has escaped from it yet, and those browser VM's have no write access to anything anyway. In our testing with the Air Force's "LPS Linux" their Java took it in the ear every time.

I understand that all of this is hard to believe, I'll be happy to explain further if it helps. With the way we designed KNOS, we don't need to do a "secure boot" or many of the other classic methods. We thought outside of the box the first time given that I spent so many ears INSIDE the box before throwing up my hands over how well "best practices in security" was working out in the first place, did a lot of thinking, and then did this.

Oh ... almost forgot ... Joanna's thing. I always admired Joanna's way of breaking into things and spanking the guilty. Heh. Qubes is an RHEL Linux system with Xen hypervisor and is actually pretty neat. Only downside though from some of our testers who gave it a spin is that it's confusing to ordinary users and difficult to use.

http://www.flaviostechnotalk.com/2011/05/01/is-there-a-blue-pill-for-qubes-os/

In the BSD world, we have Capsicum which is superior to the Xen style sandboxing. Our primary business is quantities of customized builds, and this is now an option for customers willing to pay for custom builds along with many of the things mentioned on that page of ours which was written nearly two years ago.

Anyhoo, I'm sure I've managed to raise even more questions, please don't be offended by my own attitude towards Linux, there's plenty of Linux out there in the world for folks, we wanted to do something very different. This is the result of all that.

(Edit: added "To Hungry Man" since the "reply to" didn't appear with a "quick reply")

 

Okay, I managed to find a demo CD on CNET. Tried it on two computers. This is an old version from 2011.

- Boot process looks like the usual FreeBSD stuff, though kernel output is suppressed.

- On the Acer ex-laptop with 1.5 GB of RAM, it failed to boot - the system spontaneously rebooted before X started. Not sure why; that machine has had BIOS problems before, but the BIOS was reflashed and it should be fine, and anyway the BIOS stuff should have manifested way early in the boot process if present.

- So I tried it on the netbook...

- It booted okay, but couldn't get the ethernet card working - reports no carrier. This is an old bug with FreeBSD 8.x and the alc module. Wireless was detected fine though.

- uname reports the system is FreeBSD 8.2 (duh). pkg utils and portsnap are present. The wifi manager is one that's available in the FreeBSD repos, branded with the KNOS logo instead of the FreeBSD one.

- Xorg logs look pretty normal. Interesting the Gnome 2 desktop started with DRI support, and Metacity in compositing WM mode. This seems a little odd; Qubes last I checked doesn't do 3D acceleration because of security issues, and much 3D stuff doesn't work with GrSecurity's memory protection features. I'll give credit where credit is due though, at least the Composite extension works without crashing (which is not always the case on BSD).

- /etc/master.passwd has no passwords in it. There's some stuff on the KNOS boards about the OS verifying that input comes from a physically present user, and passwords being unnecessary on the live version... Not sure how that's possible. Maybe verifying that application input is associated with input from the keyboard and mouse devices? At any rate I can su to root with no password.

- top shows the usual stuff running as root. (Xorg, etc.) The pf firewall appears not to be enabled.

- Various MAC systems are available as modules in /boot/kernel/, but kldstat shows none of them loaded.

- Filesystem permissions appear normal. All the KNOS user's processes run in that user account. Firefox has full access to the home directory; an SSH private key that I generated is visible in Firefox if you direct it to the requisite directory.

- It is indicated on the info page that the desktop is set up in a FreeBSD jail. I'll admit I wouldn't be able to verify that if it was the case, however I saw no indication of it during the boot process.

- The user manual is... umm... clearly oriented towards end users. It also attempts to gloss over the fact that the screen locker is useless without password authentication.

This looks like a bog-standard FreeBSD live CD. Some stuff rebranded, some stuff (Xorg?) possibly updated, some settings changed; but it does not look like it's been modified a whole lot.

 

Yep ... it is indeed pretty much standard standard BSD (with numerous mods in the kernel and other code) given that our customers have the option of buying our build toolkits (that's what we actually sell) which enables them to build their own since their motto as well as our own is "trust nobody."

That's actually a requirement of most of our "real" customers. We provide the necessary patches and instructions, and this allows them to obtain and synchronize the code and build it on their own machines for their own ability to maintain that "chain of possession and control" over it all. The really big magic is in how everything is loaded and how the resulting distro is locked up solid, even when installed onto a standard hard disk, which is how most institutional customers do their own KNOS distributions, literally replacing Windows. The ability to customize how it all ends up on those drives is our real thing.

And of course, 8.2 was a long while ago - that ALC thing got fixed in 9.0. As to your Acer, yes, that was a known ACPI issue in those, we had some adventures with it again during the 9.0 test cycle. We're planning on a public beta for 9.1 in about a month, we're still working on it. Keep an eye out, you're invited to play with it when the time comes.

As to MAC and those other layers, given the way we set it up, there wasn't a need to take it that far although we've done that and XEN for some customs. As far as PF goes, that requires configuration and in a generic release where we have no idea of what IP's and ports are needed in an individual user environment, so we didn't bother with that. The assumption, given our major customers, is that all of that would be filtered before it got to the CAT 6 and adding that would be redundant. I'm sure you understand.

The real purpose of that demo was to allow folks to check hardware compatibility and make sure that it booted up at all before purchasing. At the time, we expected consumer interest, but it never materialized and so there wasn't one for 9.0. And yes, su from CONSOLE ONLY is permitted, and verified to be coming from local devices. After all, if someone's actually at your screen, then it wasn't your computer anymore anyway.

And yes, understand your point about the screen locking, but on a read-only file system, how would you write out a password when it can't be written to anyway? All of that can be provided in a custom (and is), but there was no point in doing it for the personal. That kind of stuff is usually done in KNOS with an NFS personal share and unionfs overlay in multiuser environments.

 

How? Capsicum is built into the (huge) kernel, Xen is a hypervisor. Part of the point of Qubes was to move the sandboxing onto as little code as possible, because code is attack surface.

You say "verified to be coming from local devices." But remote access via e.g. SSH is one thing, a compromised application is another. If Firefox gets its call stack clobbered and calls a function that has been loaded into its memory space earlier, how can you possibly tell that the function is "not local"? How can you be sure that it won't go on to simply spawn a shell and su to root?

 

Can't verify the encryption ATM. Aside from that, how is this any different from other live media?

Also, encrypted files have to be decrypted in memory. What's to keep an attacker from grabbing the key from somewhere in RAM?

Wouldn't this have required some heavy duty modification of a huge number of FreeBSD drivers?

The boot sector looks an awful lot like the FreeBSD one from where I'm standing.

Dunno about custom filesystems. The live CD uses compressed UFS filesystems and the CD is standard ISO9660. I assume you're talking about the installed version.

 

My bad ... was trying to remember Joanna's thing since the last time I looked at it was back in her beta. Got them confused when typing. Once I saw it was Linux and not something "new" I kinda lost interest. As I said earlier, it's interesting but a bit too confusing for regular users. Please do understand that the ones I've always worried about isn't the technogeeks, it's the folks who can't tell a CPU from a toaster. Those are the ones that get in trouble and once something gets complicated or unfamiliar, they tend to do the wrong thing no matter how well written code might be.

Since you're apparently familiar with BSD, I'll answer this a bit deeper for your benefit. Without getting too deep here though, we use ConsoleKit and DBus and limit the communications only to the mouse and keyboard as far as bringing up xterm within our desktop environment. By design, BSD only accepts console, and all tty's are set for "secure and xterm" by default. You would have to deliberately configure it for any exceptions, which we didn't. There is no way to circumvent being forced into "KNOS User" mode during bootup which brings the additional security into play. Same goes for the ctrl-alt-F? means of obtaining a terminal outside of X. You can check the ttys file in etc to verify.

BSD doesn't use BASH as a shell by default, and neither do we. That's a Linux thing and BSD's version of BASH is more restrictive. I'll point you simply to item #2 in the following about the system shell, the article goes into other differences from "Linuxisms" ...

http://www.freebsd.org/doc/en/articles/linux-users/article.html

Thanks for bringing up the "stack fault" issues which plague other OS' such as Windows, that's always a favorite topic for me.

BSD has been designed for several years now with serious stack protections, one of the reasons why there's so few successful exploits outside of third parties doing dumb things porting over from Linux and not compiling the ports using the gcc compiler protection in the older KNOS version:

"gcc -g -Wall -O2 -fstack-protector-all -o main main.c"

... which provides stack protection in any applications that are deliberately compiled by ports including that flag, and on BSD builds, also includes additional stack protections from the BSD kernel itself. That's another reason why most of KNOS uses custom compiles of applications rather than the default packages because many of the default packages do not use that flag, depending on the kernel itself to protect against stack faults which of course can occur in poorly written applications.

Also, since version 9.0, BSD has been migrating away from teh GNU C compiler because frankly, it's not all that good. As of 9.0, we've been transitioning to the CLANG compiler and with our 9.1 release, that transition will be almost complete. CLANG has far better protections than GCC permits for applications, and that's part of the reason why our 9.1 is taking so long, fixing all the Linuxisms that came along frombuilding things in the BSD GCC compiler for all these years.

The following stack protections have been in BSD since version 8.0 and have been enhanced with each release since:

http://census-labs.com/news/2010/04/26/kernel-exploitation-mitigations/

In KNOS, our BSD kernel *is* highly customized, and includes all hardware drivers (and I mean *everything* available) compiled directly into our unique kernel compilation. And we include the "-fno-strict-aliasing -fstack-protector -fomit-frame-pointer" directive there as well. So everything in KNOS, including any internet-facing applications, has extensive tamper protection, so no worries.

Hope that helps.

 

I understand your concerns, we had the same back when we started.

The encryption is proprietary and an extension of uzip facilities that came with BSD. It's not quite encryption in the traditional standard, that's more "sales-speak" than anything else. Given that it's one of our own "trade secrets" though, I can only offer that if anything modifies the "lockbox" then the system will break seriously and fail to operate as a means of alerting that something's horribly wrong. On a liveCD of course, that's pretty much impossible to do given that it's read-only media, but the design also applies when it's burned to writable media which is why we went to the trouble of modifying the method for our own purposes.

The kernel is fully self-contained and compressed, and yes, it's obviously possible to catch bits and pieces of it in memory perhaps, but at the same time, our stack protection also makes it very difficult to determine whether or not what you've unpacked is the real memory location or a phantom. Given that keys do not need to be distributed, our packing is symmetric encryption. System knows the key already. And tampering with ANYTHING in the "lockbox" will break the mtime and inode chain, resulting in a broken system. We designed it to work that way.

Indeed it did. And the code was compiled directly into our packed kernel. We HAD to do it that way so that KNOS could detect a far wider range of odd hardware than BSD built into their generics. No kld_loads are required, everything's in the kernel itself.

Sure is ... "bog standard" ... BSD won't boot without its own mommy. Same for the rest of the boot sequence, depending on the media it's on. DVD, USB, HD, the rest. But BSD is very fussy. It will not boot if anything isn't just right, and the placement and offsets of everything is hard-coded. Bring along a stowaway and it won't boot. Another reason why we chose BSD as our base.

Yes. UFS is merely a file system environment. The way we built KNOS resides in them inodes. Major benefit of UFS though is that when you plug a KNOS USB stick into Windows, it thinks the drive hasn't been formatted. Helps to keep strays out of our hair. Heh.

The ONE thing that continues to vex us is certain Broadcom wifi cards - the vendor will not cooperate, and the Linux WL driver for it is SO full of incompatible Linuxisms that don't exist in BSD that we're forced to use the Windows drivers, which don't work well in BSD either. And because they're Windows drivers, they open up a Pandora's box of nightmares to us. At this point, we still not sure whether we can get them working safely for our 9.1 version, that's currently the hangup for release. We're STILL trying to find a way to support those given how many of those "crappers" there are out there.

Well ... nighty for now. Bear in mind once again, KNOS 8 was nearly three years ago, we've done additional things since. Secondly, the most important thing for everyone to bear in mind: We're NOT another "Linux live CD." In fact, we're not Linux at all! And unlike Linux, KNOS is designed for NON-geeks to just whip in there and use. No configuration, no diddling, no cursing. It just works.

 

Yeah, I saw this; there are no logins beside the automatic ones (and su). OTOH I don't see how you can possibly distinguish what is local code, and what is foreign shellcode injected into some application's address space.

(I get that stack protection makes this unlikely though.)

Edit: I'm not actually very familiar with BSD, more with Linux, so I might be missing stuff. I will take another look at the demo later today.

 

Those stack smashing techniques already exist on Linux, vanilla BSD, and Windows.

I'm clear on all of the BSD security. What I don't get is the KNOX security. Can you explain in more detail how all of this works?

You talk about 0'ing out data. How do you enforce that?

You talk about these "lockbox"'s. What exactly are these and how are they enforced?

 

Firefox and libxul do not appear to be compiled with SSP on the demo.

Code:

readelf /usr/local/lib/firefox3/firefox-bin | egrep -i "(stack|guard)"

just returns some stuff about __cxa_guard_whatever functions (which are related to thread safety AFAIK, not SSP). Same goes for libxul.so. Also for Nautilus, Gedit, and other things.

Edit: SSP has been available in GCC since 2006. The version in the KNOS demo is 4.2.1 and should definitely support it.

Edit 2: Umm, how much has changed since the 2011 demo? There don't seem to be any demos of current versions.

 

Hope you don't mind, but I'll combine your previous two messages here since they're related. So let's see what we can do to explain things a little better, since we're still not quite handshaking on what you're looking at there, and unfortunately I could fill a couple hundred screens with the details. So once again, I'll try to keep it as simple as I can here.

KNOS is a memory-only based system. As such, when it starts up, everything launches into a VM, similar to the way "jails" work. Everything is virtual, including the filesystem itself which is copied into memory. The filesystem itself is referred to as a copy of the contents of the "disk" (whether DVD, USB or HD) and loaded into that virtual "drive" that KNOS runs as.

All communications from X once it's launched are protected by consolekit and dbus straight off from the launch. This is part of the reason why that force launch into the automatic login in the first place. There is no interaction with the booted OS until you get to the desktop. Keyboard and mouse talk ONLY to the system through xterm. Any "shell call" also would go through DBUS and consolekit, and coming from an application rather than through xterm, would be denied. In the configuration, only the local tty9 is permitted to talk to the "system" and again, only through xterm.

While LINUX has supported GNU's "SSP" since then, BSD isn't at all similar to Linux and none of that worked until 2010 where it was introduced in FBSD 8.0 given that the kernel itself has to support that. At the time of construction of KNOS 8.2, SSP was not available for applications as explained here:

http://forums.freebsd.org/showthread.php?t=20381

That all said however, the 8.2 demo wasn't intended to contain any of that because it was released as a "debug" version. Again, the intention of the demo wasn't handing out "free meat," it was created in order to allow potential customers to try out what we had in that version and see if it was compatible with their hardware. In other words, if it booted up, then they could purchase KNOS and be assured that it would run on their machine and they wouldn't need to find out the hard way that they needed to get a refund because it failed to work. At the same time, debug functions would have their data interfered with had we enabled any of that in that version.

We also disable that in our public betas for the same reasons. If there's a problem, we ask for extended diagnostics data which is not present in our formal releases. In formal releases, we do not compile our kernel with any debug hooks (unlike Windows, Linux and other OS') given that the vast majority of exploits depend on being able to hook debug functions. In release versions of KNOS, all debugging is not compiled into our kernel, firmly closing that door for exploitation. Same for applications that we compile ourselves. In our demos and our betas, we do provide unimpeded access to debug functions in order to track down anomalies and problems. Hopefully this explains why.

I don't have a copy of the demo handy at the moment, but I'm pretty sure that we did nxstack back in 8.2, I know it was in there for 9 and the way that works in BSD is that IF a buffer overflow occurs, it immediately calls a panic() and brings the entire system crashing down BEFORE the overflow can pop the stack. So whether or not SSP is in the applications, the kernel will stop such dead cold. The only reason why we even did SSP from 9.0 on some apps and for all internet-facing apps in the upcoming 9.1 was because we kinda got tired of explaining that just because it happens in Linux doesn't mean it will happen in KNOS. I was trying to find the reference material that I had the other night, but google isn't locating it right now. If you want, I'll dig further on the details. FWIW though, as we're moving away from GCC to the CLANG compiler, the stack protection will be provided by "SafeCode" and "AddressSanitizer" in the next releases, that's pretty easy to look up.

Forgive me if I glossed over anything, been a long night.

 

Actually, if you check the link back above, you'll discover that BSD's design already has been extremely successful at stopping those from becoming active exploits - at least on FreeBSD. PCBSD, NetBSD, OSX and the others are forks that go way back to 4.3BSD. That was the primary reason why we built KNOS with FreeBSD and our own little tricks.

As for zeroing memory, KNOS runs in memory. When it's started, we do a memset() call on memory before loading KNOS into it. This assures that for each allocated block KNOS is being loaded into, anything which existed in the boundaries has been cleared before write. That means that should something overflow, it will overflow into nulls. As to what we call the "lockbox," it contains the entire contents of /var, /etc, /usr/local/etc and the entire /usr directories in compressed packages with separate verification data elsewhere in order to verify that the contents have not been changed. These are read-only and cannot be modified. Any attempts to modify them would result in corrupted memory allocations, causing KNOS to fail to run. That would be the indication that it's time to reload any writable media, I don't think there'd be any possibility of that happening on a DVD. Everything is read-only though and run in memory, not directly from the media containing the lockbox.

Hope that helps.

Link references on exploits that I was referring to:

FreeBSD:
http://www.exploit-db.com/search/?ac...b=&filter_cve=

Linux:
http://www.exploit-db.com/platform/?p=linux&pg=65

 

I don't get this dbus/consolekit thing. Do you mean it would prevent an interactive shell from spawning, or prevent arbitrary code from being run period?

Figuring out which code is injected is apparently not impossible (for instance with FOOD: http://www.acsac.org/2006/papers/86.pdf) but I find it difficult to believe that you implemented it from userspace, using preexisting software.

Re tty9, I take it this is just enforced by passwords being disabled? You can log in as root from any console in the demo if you enable the root password.

BTW, I tried to compile a simple buffer overflow test on the demo, but was unable to because there are no header files on it.

I don't expect a demo version to be "free meat" with full functionality. OTOH... I hate to say this, because it's hard not to come off as rude... But you are making some really extraordinary claims. And they have gotten even more extraordinary as I have asked questions. And now you are saying you have not provided a trial version with the extraordinary capabilities you described.

Look, I don't want to be a jerk here, but I think I can see why KNOS failed to generate much consumer interest.

 

BTW, looking at the info page, you say a couple other things...

Not sure about the "only has access to the screen" bit, the X server looks pretty normal to me; but requiring both applications to be open is how the normal X "clipboard" works. Also, various sorts of drag-and-drop work okay on the demo (e.g. dragging a text file into Gedit to open it).

Not sure how to verify this, but I would expect much more memory to be used if every program were loading its own copy of a needed library. Also, not an expert on this, but I'm pretty sure there are other methods by which code can be injected into a process than by using a loadable library.

Again, this is with the obsolete demo so I can't verify that it's true of the real deal. But I think you can see why prospective buyers might be a little weary.

 

I'm sure you're aware that Xwindows has had a lengthy history of security issues, and although they've closed off most of the holes that existed historically, there are still some sharp edges in it. Since we run a modified version of Gnome2, which is quite mature thanks to BSD and the BSD maintainers at "marcuscom" who've made many specific modifications to the port which originated in Linux and has since been abandoned, it is capable of quite tight control in the BSD version. Dbus and consolekit filter any communication between elements by a configured set of rules and specific action permissions based on the source of any message and its destination. In our configurations of what is permitted, and what isn't, we've spent years limiting what kind of communication is permitted, and rather successfully.

Some of our KNOS customers are very well versed in blackhat, and before purchasing, they ran us through their own gauntlets and were impressed enough to purchase. Is some remote possibility possible? Only a fool would say absolutely not. But so far, knock on wood, hasn't happened that anyone is aware of. Remember that in addition to the extensive work on Gnome2 by its BSD developers, the kernel itself is also designed to thwart malcode. If you open an xterm in KNOS to open an interactive shell, then you're free to do as you wish because you're doing so from your own system manually. As "KNOS User" we'll let you do pretty much anything you want. If the source of an X message is from another application and not one of ours, permissions will be denied.

We looked at "food" many years ago, back in the BOClean days. Yes, it's a definite problem ... for WINDOWS. Our protections exist both in how the FreeBSD kernel was designed (along with options you can build into a custom kernel) as well as how the Gnome2 structures were changed for FreeBSD from all that Linux code that won't work in BSD.

As to tty9, you don't even need a password to login as root. No need, since that's all tied to the local console. Try logging in from outside. Even from another KNOS machine. You'll see the KNOS box, try logging in.

I understand. You're trying to apply Linux to the BSD world, and that's like comparing an apple to a boat. They're VERY different. Something else that needs to be restated is that our target audience is NOT Linux users. Anyone capable of getting LInux up, configured and properly running doesn't need what we're doing at all, although I'd suggest installing FreeBSD and giving it a spin and see if it isn't a happier experience. That's why Gentoo has a BSD version which is a lot safer than Linus' thing. As I said at the outset, I didn't want to step on any toes, but KNOS is intended to resolve WINDOWS problems by offering an alternative that is ready to run with no computer knowledge needed by the end user. It's also designed for Intel OSX users whose older machines are no longer safe because Apple is no longer supporting them and they can't install newer versions of OSX because of the hardware they're running. We even have a dock available for those OSX users left behind.

Bottom line though, if you can get a Linux install up and running and and you're happy with it, then you really don't need us. We exist for those who can't or won't.

 

Our "sales material" is written for WINDOWS users, and in Windows, that clipboard has been a perpetual nightmare. Do a copy, close the original source program where that copy operation came from, paste it into something else and you're done. Not quite. Raiding the clipboard buffer in Windows has been a rich source of information for malware in Windows for many years. It's a major security concern in Windows. Now close the source program in KNOS once you've copied or dragged, and there's nothing left to paste. Instead of a clipboard, KNOS does the operation between two open programs through DBUS. There is no "clipboard buffer" of any kind in KNOS. That's what we were trying to explain to readers.

Now you see why we have the system requirement of "at LEAST 1GB of memory, more is better." That's precisely the reason. KNOS can't even boot up if you have less than that. While we have no choice but to permit some shared memory on the video card as a result of limitations in Xorg which require that in a controlled amount, each application is NOT allowed shared memory. The downside of that is that if you have too many things open at once with limited memory, BSD's very different memory management is going to clobber something and signal 11 if it can't shift memory around and clear more. But yes, we considered that to be a very important thing in preventing one application to be able to inject anything into another application by finding the address of some shared library and abusing it. Again, that's a major problem in Windows as well that our design considered. So if multiple programs are calling for example, "libc" then each one will have its own separate instance of "libc" in order to close that door. It's piggy, but it's safe.

As to prospective buyers, sure we'd like to have them. But for those who have their doubts, be happy to walk them through it if they're interested. Please DO understand though that since what we're doing is proprietary, I can't just paste up all the source code for what we did. Under the BSD license, we don't have to and thus can keep our "security by obscurity" intact except for those who have signed an NDA. And we've done PLENTY of that since customers who want to roll their own get all the goodies under that NDA. That's also the reason why we HAVE to write around anything that's GPL separately because if we were to touch any of the GPL stuff, we'd have to give away all our cookies.

Sorry if I've managed to raise any offense, that was never my intention. FWIW, those who remember when we did BOClean know that our own thinking was WAY "outside the box" and worked despite many expecting us to do things the same way as everybody else, and that raised lots of skepticism and criticism. I'm used to that. But that's WHY it worked. But given that there's a lot of proprietary in KNOS, there are limits to how much detail I can go into without getting slapped by my wigs here.

 

Let me step aside for a moment and make this a reply to nobody in particular which basically explains the whole purpose of KNOS. It's what's kept us going all these years ...

Linux has been around for a long time. It's quite mature. Lately, distros like Mint and Ubuntu are trying to focus on the average "Joe" and unfortunately because there are a lot of illiterate users out there, they've been going out of their way to "dumb it down." This is accomplished by knocking down some walls of security so as to not frustrate "idiots." Given my lengthy history with Billyware, I consider that quite dangerous. Nothing against Linux, in the hands of the very capable it's every bit as good as BSD. *IF* it's configured properly. Fortunately, out of the box, it's pretty good despite all this. However, over the years, many have tried Linux and really didn't like it. They considered it confusing, awkward and some distros quite unfriendly. Linux is built for geeks, not grandma.

BSD on the other hand is a SERVER operating system. The BSD heads go out of their way to discourage the use of BSD for desktops, and when newcomers come to the lobby, they're only too happy to foist desktop users off onto PC-BSD and other distros which hand non-skilled users the same bucket of unhappiness that they found in Linux. While BSD is easier to build, configure and install for geeks and often much more flexible, it's definitely written for metalheads who are told to RTFM and go away. The community is much smaller and if you don't come off as a newb, they'll take the trouble to point you to real answers instead of forums.

KNOS is designed specifically to be run by grandma, the kids who come over and want to infect that computer at all costs, the suits in the corner office who opened that email and infected the entire company - not once, not twice, but every time. Those are OUR customers, and the folks who are tired of cleaning up their messes ... the folks who just want them to whip in that DVD, a bootable USB stick, or even the hard drive and let them go to town without worrying about what they're about to do. KNOS isn't designed as a REPLACEMENT operating system (although many have done just that) - it's designed as a separate operating system, leaving everything on the machine safe and intact while providing the dangerous end user types a familiar and highly useful "alternate computer" that does what they need.

So while I understand many thinking that we're somehow competing with Linux, we're not. What we're offering is convenience, sanity and also safety. Just wanted to get that out here since so far, it's approaching some sort of pi--ing match and there's really no need for it to go there.

Thanks.

 

Hi,
If KNOS is not a revolution, it is nice to see another alternative OS in the market.
None OS will solve the security problem, KNOS and Kevin, neither Kaspersky labs
http://www.csoonline.com/article/71...it-proof-os-leaves-security-experts-skeptical
And this toppic has been discussed many time here
https://www.wilderssecurity.com/showthread.php?t=304119
https://www.wilderssecurity.com/showthread.php?t=339883

KNOS has a good value for money, if we consider for instance another paid OS alternative like eComStation that begins at 149 dollars
http://www.ecomstation.biz/cgi-bin/db2www/biz_art2.d2w/report?catname=eComStation

Regarding technical design, KNOS is not the most original and unusual OS concept that i ever seen...sorry for Kevin...and i guess that all previous posters might be interested in Phantom OS, the Russian OS that never dies...
http://en.wikipedia.org/wiki/Phantom_OS
http://www.osnews.com/story/20899/Russian_Phantom_OS_Never_Dies/
http://www.dz.ru/en/solutions/phantom/
Not practical as a daily OS of course!

I guess that KNOS needs to be more popular, especially in schools and libraries market.

Rgds

 

Thanks!

And let's not forget another one that was supposed to be based on FreeBSD. It had us scared for a very long time given that it was very well funded. However it turns out that the Chinese never managed to do what we were successful at. It was called "Kylin" and they finally gave up on it last year and came up with yet another Linux distro instead:

http://en.wikipedia.org/wiki/Kylin_(operating_system)

What we did with KNOS might sound easy, because it's commonly done with Linux. However, doing this with BSD was a major and expensive challenge.

 

HI

Tried Kilyn in the past and did not see its need in comparison to FreeBSD
http://www.freebsdnews.net/2011/01/07/kylin-os-details-download-links/
Now Kilyn is based on Linux and is not intented only to military and critical IT
https://wiki.ubuntu.com/UbuntuKylin
Agree that building an OS which takes good parts of various other OS is a big challenge, and i remember that some promising ones has never seen the sun
http://www.skyos.org/
One of the key of an OS, Phantom excepted, is the file system, then is there any plan for a KNOS port to ZFS or HAMMER for instance?
Regarding security focused OS, virtualization (kernel) is in vogue (Qbes, Polyxene, LynxOS), but this is here an additional layer of Security, not security by design.
Our member Mrk has published an overview of KNOS on his site
http://www.dedoimedo.com/computers/knos-project.html

A good dev. is not automatically a good marketer, and a lot of work is necessary to provide some lights on KNOS.
Security boards are interesting, but there is also security conferences like the new French Defcon NoSuchCon
http://www.nosuchcon.org/#cfp
Anyway best wishes for KNOS project

Rgds