Any OS not connected to a network is 100% secure, barring physical security of course.
Barring physical security? So in other words you mean it is 100% secure from network attacks. It isn't secure from users, administrator errors, malware, or TEMPEST.

In other words, it is 100% secure from everything but threats?

Solaris, who has the money for that OS. I'm poor, can't afford it.
http://wwws.sun.com/software/solaris/binaries/get.html

Whew, $20... damn that is expensive.

Memory is right the OS only as secure as the admin or user. I have seen new *nix users install with not knowing that they had to install a firewall , harden the kernel, checks sys logs. or even implent security features. Still some OS'es have better built-in features to make it more secure or less. But the admin must know how to lock down services and uninstall service that's not needed.
This is why ISO15408 takes documentation into consideration. Systems lacking a standardized manner of implementing security are inherently less mature and less secure as they require heroics on the part of the admin. Many systems ship with not only good documentation but either in its most secure state (eg. OpenBSD) or with scripts/apps to put the system in a secure state (NT).

I got a private message regarding this thread and OpenBSD. Although OpenBSD ships in a more locked down state it offers no additional security functionality over other flavors of UN*X. OpenBSD does not protect against rights propagation that I discussed in my "How to hack (nearly) any OS" tutorial. OpenBSD does not protect itself from trusted malicious users, trusted malicious code, or even trusted weak code (bind springs to mind).

OpenBSD is in fact the apex of flawed security assumptions, the idea that the system is only as secure as the admin is answered by shipping the system in as minimal state as possible thus not requiring the admin to do anything to lock down a default install. The second is that secure code makes secure systems, hence all of OpenBSD's code audits. This is refuted by the simple question. is it feasible for the OpenBSD team to make the OpenBSD code 100% perfect? No of course not, they would need a _hell_ of a lot more money than they have, not to mention that ensuring that ever supported 3rd party app is also perfect. If this isn't possible in their current situation, why try? Doesn't it make more sense to design a system keeping in mind that it will fail, but ensure that it fails into a secure state? More advanced systems do this (NT's CAF is a fine example) This of course doesn't even take into consideration the weaknesses of the OpenBSD DAC architecture (multiple actions with a single command).

catch