Slashdot Mirror
Windows Gets Independent Security Certification
linumax writes "Microsoft Corp. on Wednesday clinched Common Criteria security certification from the U.S. government's National Information Assurance Partnership for six versions of its flagship Windows OS. The products receiving CC certification include Windows XP Professional with Service Pack 2 and Windows XP Embedded with Service Pack 2. Four different versions of Windows Server 2003 also received certification. Common Criteria certification, which was ratified as an international standard in 1999, helps customers in key market segments evaluate IT products when making software purchase decisions and contribute to higher levels of consumer confidence in IT product security, Lipner said. SuSE Linux ES 9 has already achieved the certification and almost a year away from being released, Red Hat Enterprise Linux 5 is on the path toward EAL4 certification."
Now all the US police departments (that have to use EAL-4 systems) can buy upgrades from Win2000 to XP. Perfect timing, with all that DHS money coming down the pipe right now...
As a Windows user considering the switch to the Intel Mac's coming soon, I'm curious if Tiger (OS 10.4.4 or whatever) has gotten this certification? I know the argument is that you're more secure no matter what since no one writes spyware etc for the Mac, but is it certified? I'm honestly curious, so I know what I'm in for.
If I remember right, there is a certification fee. Of course, that makes sense, since certifying an OS costs the certifier. But you're not saying that; you're implying that MS payed a bribe to get certified.
Care to back that up with references? Or is this just typical Slashdot trolling?
How about an encrypted filesystem? How about if there were no ways for this attacker to gain root priveliges from a local login. I really don't understand what you're saying.
E = m c^3 Don't drink and derive E = m c^3
Once you have access to the machine, you can always break into it. Yeah, an encrypted file system will slow people down a lot.
But if the machine can boot itself and access that disk, then the machine itself contains all the information needed to decrypt the data on the disk. And thus someone can break into it by definition. It may be difficult, but it's certainly possible.
This is why Kerberos key granters are locked away.
http://lkml.org/lkml/2005/8/20/95
Has anyone done windows source code audit?
Slashdot = Sarcasm
Actually if you want to get serious about it they should use a "Trusted" OS like Trusted Solaris or similar OS that uses mandatory access controls. OpenBSD does not have support for that in the base configuration the last time I checked, although it is probably sufficient for general purpose computing.
This is the short-form explanation. If you somehow decide to care about this more seriously, aside from seeking professional help I would recommend that you consult the Book of Armaments...er...the *real* CC site: http://csrc.nist.gov/cc/
Each of the areas that Common Criteria cares about has an extensive set of "things in this area about which we care" that is the source of the ADO_IGS.1 (&c) items above. For a software item such as an OS, think of those as "claims".
For any area, the EAL just shows the level to which a "claim" has been examined and therefore can be proven. EAL 1 is basically "I read your marketing puff piece, and it sounds really good!". At a different extreme, EAL 5 is pretty close to "I did everything I could to review your code and attack your system, and I still couldn't get in". Unsurprisingly, most software falls somewhere in between. Surprisingly (or not), some software (particularly OSs) might go at EAL 3 or 4 but will still have holes. Why, one might ask? (!)
Unfortunately, it's because CC actually expects (but does not assume) that software authors did their jobs thoroughly--including not injecting unintentional bugs. Any bug that does not match the stated intent of a chunk of code, and which doesn't get caught on a code review (which might or might not happen during CC eval, but if it does should only repeat processes in place at the software vendor) would look to most of us like a HOLY CRAP VULNERABILITY -- but the CC process doesn't directly account for it in evaluating and certifying software. Is that a flaw? Yes. At the same time, if one wants to go out and procure an OS that supports an essential set of features related to user authentication, CC is more likely to provide an OS that implements that set. It doesn't mean that a CC-evaluated OS is the most secure, but it has a specific set of functions that can be shown to work.
I know that probably sounds like a steaming pile to some folks...but for one set of evaluation criteria, the above means that CC evaluation is good and nothing else quite takes the place. In an ideal world, CC evaluation would be only one data point in a decision to procure a product, along with other measures of effectiveness that can more truly show fitness of particular software for a particular purpose.
BIOS passwords are useless, there are Master passwords for most makes and models :)
:)
go here and find yours today:
http://www.biosflash.com/e/bios-passwords.htm
LocalSystem is granted everything by default, but restrictions can be put on it, and LocalSystem can't ignore restrictions put on it like root can in Unix. There really is no comparison to *nix root account in Windows.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Since no-one else seems to be commenting on the fundamental features of security evaluations, I suppose I had better do so.
When you think of Govenment-approved IT Security evaluations, you tend to think of TCSEC - the Orange Book. Though fundamentally flawed (don't get me started!) that document set the scene for such work. It defined the vocabulary to be used for this activity, and famously made a distinction between the security features an operating system had, and the level of assurance you might have that they work.
The Orange Book joined these two features together while Common Criteria sets them apart. Worse, Common Criteria lets the submitter define the security features he will claim. The 'assurance level' means the stringency of testing (and associated paperwork) and nothing more.
When I worked in this field I used to refer to this as the 'Green Box' problem - the point being that you could claim a very low level of security functionality, and have that pointless claim evaluated to a very high assurance level. So, with tongue firmly in cheek, you could make a security claim that 'my product comes in a green box', have that claim evaluated to a high assurance level, and then go boasting that you have a 'level 6'.
This is what contributors mean when they say you should 'look at the profile'. They mean you should look at the Security Claims made in the evaluation, not at the rigour with which this claim was tested.
One possible way out of this problem is to pre-define sensible claim sets - I have done this for the UK Government in my time, but these claim sets have never achieved standard status. So the public never ask for them, and so corporations keep fooling us with pointless 'advertising' assertions like this.
If you really want MAC though, TrustedBSD was merged back with FreeBSD in the 5.x branch, and is there in the latest releases. I seem to recall that Solaris 10 and Trusted Solaris now use the same codebase too, so that's another option as you said.
I am TheRaven on Soylent News
Windows protocols can not be breached in any way, therefore making Windows 100% secure systems. But the Windows O/S is not 100% safe, due to bugs in critical libraries and wrong default settings. A properly patched and configured Windows system is as safe as any Unix box, but the complex security model of Windows makes it far easier to be breached.
In unix, if you're root, you can do anything. "Security" checks basically start with an "if (UID != 0)".
Not with ACLs and profiles.
In Solaris 8 and above you can actually shutdown the root account quite tightly. You can prevent it from (say) reading the shadow file.
Root in Solaris is simply another account, which by default has system wide access.
I'm pretty sure similar things can be done in FreeBSD with the TrustedBSD code and also with SELinux.