It's not what happened to you that matters. It matters who you know, how often you talk to them, and who they talk to. Someone else will decide what that leads them to believe about you.
In other news, open source community takes another swing at Privacy Enhanced Mail, but this time with no trust anchor...
I'm still not convinced that anonymity and accountability can coexist. At the very least, they need their servers to be accountable for the anonymity assurances given to their users.
It's the device drivers IN the motherboard I'm talking about - they constitute a huge block of code, supplied by who knows whom from who knows where that make up the BIOS and EFI bootstrap framework. They're what inform your OS kernel what devices are present, their characteristics, and in many instances provide standardized interfaces to them that the OS drivers themselves can simply invoke.
They operate BELOW the OS layer.
Check out the OpenFirmware.info community for more details, and know the motherboards you buy and use have them, too.
It's not really possible to "opt out" of public surveillance. Can you imagine the difficulty of claiming the right to "disappear" off of other people's Google Glass (maybe by broadcasting a disruptor signal of some sort saying "ignore me, nothing to see here, move along"?
And how do you assure privacy to those who deprive others of it, themselves?
If privacy is outlawed, only outlaws will have privacy...
New thought really is required. Not sure all the angles can be squared.
Worrying about compromise of the Linux or Windows kernel is foolish - they're so large, they could have anything hidden inside and you'd never find it (searching for such is literally uncomputable). Begin your concerns with the device drivers from who knows where that are put into place by your motherboard BIOS or EFI boot systems. Conventional operating systems are entirely dependent on them, and they're completely beyond your ability to inspect or trust. And the Open Source variations have the same issue as the operating systems - large, monolithic blocks of code impenetrable to analysis.
You fear what you know about. Fear, instead, what you don't.
Ha Ha. Hahaha. I guess you missed the bit about how it is computationally infeasible (as in, halting problem) to definitively determine whether there are artifices in source or object code that deliberately mask and hide their behavior. See Naval Post Graduate School thesis and papers on how few lines of code need to be introduced to turn IPSEC implementations into clear text relays - turned on and off via encrypted key triggers.
A few years back, it was discovered that virtually every one's - and I mean EVERYone's - SSL and LDAP and PKI and IPSEC and SMIME and OpenSSH implementations were FILLED with defects - because they all were using the same open source ASN.1 library that was RIFE with buffer overflows.
The wonderful thing about open source code is that everyone uses it, thinking SOMEONE else MUST have vetted it, so all too many times, no one actually does.
No, actually, you can't. Its computationally infeasible to find deliberately hidden malware in a body of code, whether source or object. So no amount of analysis and/or testing can ever reliably tell you whether in fact your existing system is corrupt. You can only accomplish that by starting with a formal set of requirements that you can then successively refine into code that is (a) minimal, and (b) demonstrably maps directly to your formal specifications and their requirements. Any excess beyond what is minimally required to accomplish your task is a potential reservoir of latent malware. Note that such malware may be present in the source (ref. Ken Thompson's attack), or if it is, it may make use of various global state variables on the system as a trigger, or key, to unlock its functionality.
Give the long established practice in high assurance computer systems design to use segments to represent base-level security objects (so as to maximize alignment of hardware-enforced security policies with promised protections of the objects), will your new OS design rely on segments to represent security objects, or if not, what hardware abstraction will you use, instead?
Given the the long established history with reference monitors and Class A1 design, will your from-scratch OS follow TCSEC (Orangebook) guidance so as to provide verifiable assurance that no trap doors or Trojan horses exist in the code? If not, what is your approach, instead?
One, at least, has been developed, and certified multiple times, using x86 commodity PC hardware, with a proprietary security controller (to provide isolated identity secret key and crypto support, like would be provided via TPM chip, today)
What would it do if it ran in a virtual machine with thunks provided so that the virtual machine had direct access to the proprietary security controller? In other words, how easy is it to perform a MITM attack on the OS and security controller?
With a Class A1 security kernel, or a Class A1 VMM, each virtual machine access to hardware would necessarily be mediated by the TCB - thus the reference monitor - whether that's done via partitioning hardware to the VMs, or virtualizing some hardware (like network interfaces, console, etc) via trusted services provided by the TCB. The design would necessarily preclude your MITM attacks.
I wouldn't blame monolithic kernels per-se. In my secure computing utopia, hardware privilege separation wouldn't even be necessary. Formal verification at the instruction level provides everything (and more) that hardware protection could, while ECC verification prevents the exploitation of bit flips in pointers that was used against the JVM. Formal verification could be attempted on an existing monolithic kernel, and might even succeed, but the work would be in defining a secure operating model and then tracking down all the bugs that violate the model when the proof generator fails, and writing proofs by hand for the hairy parts.
No, formal verification of the monolithic kernels is not possible. At the system level, we want the formal verification to take the form "demonstrate that there is no insecure state into which the system may enter". Specifically, the verification needs to demonstrate that there are no hidden interfaces, not even cryptographically protected ones that use long keys of system-wide state to decrypt or enable them, as those are the sorts of attack that a determined adversary might be expected to use.
A rational approach is to use hardware mechanisms, like segmentation, and MMU-enforced privilege level separation mechanisms (e.g., rings) to reduce the footprint subject to subversion attacks. Yes, the hardware mechanisms need also to be verified and protected against modification (whether by changing resistance or capacitance values, voltage levels, or loading hostile microcode). But that's all part of the environmental and trusted distribution aspects of the system security policy, overall.
I'm a believer in layered, modular composition in this regard - it gives you at least a prayer of analyzing and understanding the nature of a system. Formally verify the hardware and the software allowed unmediated access to it. Allocate (TCB Subsets and partitions) responsibility for other aspects of your security policy to high layers and other processors. Rely on the formally verified TCB to enforce separation and controlled sharing of information according to the policies it implements.
Let applications be applications. Put your foot down when they try to be trusted, particularly with regard to memory management (paging, for example). In this way, enable the vast majority of applications to work they way they were intended to, without knowledge nor worrys about mandatory policies. If they're good applications, teach them to use search paths to aggregate their data sources, so they can "read down" without having to be taught anything about MLS - just add the appropriate paths to their search and let the TCB control whether and which can see what.
So - don't create a bias towards trusting apps - use trusted systems that protect apps from each other, and protects your data from even hostile apps.
As you point out - on a weak system, anyone with read access to data can probably write it out somewhere, too. Not so with an MLS system supporting data integrity and/or secrecy protections, combined with adequate label integrity mechanisms for exported data (a form of strong DRM, if you like). Of course, protecting against undocumented features (Easter eggs) required another level of assurance, and the ability to verify that there are no hidden trap doors available for (or planted by) determined adversaries.
Good luck implementing a system like that on anything but dedicated proprietary hardware.
One, at least, has been developed, and certified multiple times, using x86 commodity PC hardware, with a proprietary security controller (to provide isolated identity secret key and crypto support, like would be provided via TPM chip, today)
Virtualization is enough to blow mandatory access controls out of the water without even talking about Van Eck phreaking, physical separation between networks of different privilege levels, etc.
Virtualization DOES require special attention, which is what is so disturbing about the half-baked virtualization support provided for current architectures - see Karger's papers on requirements for MLS VMMs and experience learned working on the DEC Class A1 VMM effort.
In general, I would also disagree with your claim that a proper mandatory access control system allows users of different clearances to use the same device. Covert channels are too difficult to prevent without severely limiting the usefulness of the system. Basically if two users share the same CPU or hardware they can almost always find a way to use some resource conflict as a covert channel, whether it's just the average response time for a certain operation to complete or something like the key recovery attacks that use cache latency to actually steal keys from a non-cooperating process.
Covert channels are hard, but they're more manageable than the hopeless pursuit of zero-day 'sploits that characterizes modern commercial practice. That evaluated system I mentioned above included in its configuration options for the elimination of any storage channels, and controls to manage bandwidth of timing channels.
The disconnect is this - customers have arguably MLS applications (in the commercial sense) that they're running without benefit of even the most rudimentary controls on information flow. The security industry is wrapped up in a hopeless test-and-patch cycle that is demonstrably flawed. The consumer has to conclude, in this market, that computer security is an oxymoron at its heart, and unattainable by any means.
That's too bad. You CAN control information flows according to a sound, reasonable, usable security policy (integrity, secrecy, whichever). You CANNOT do it using systems that were never designed nor intended to do that. You CAN combine trusted systems with untrusted systems such that trusted systems prevent unintended information flows, while untrusted systems provide expansive functionality on the information you allow them to access. You CAN allow "read-down" by untrusted systems to lower security data IF the sharing of that data between sensitivity levels is provided by a trusted system (complete with controls on channels). No, you shouldn't let high systems issue their own request to low networks (ie, browse the Internet) without trusted mediation - either by doing the browsing from a trusted (high assurance) client with trusted cut-n-paste (a thin client would do), or via some trusted server intermediary to cache and clear low data for high system consumers.
But in today's world, everything, and I do mean everything, from routers to hubs and switches to firewalls, workstations and servers, run on multi-million line monolythic kernel systems, whether Linux, Solaris, BSD or Windows. None of those are evaluable above EAL4 (which is "low assurance" by definition).
That having been said, no matter how 'secure' your OS, right down to privilege separation by process (can't have a Top Secret level document open at the same time as a Secret level notepad
Actually, with a sufficiently secure OS, you can give TS subjects within your process ability to read, but not write, information at lower levels without copying it up to TS, without any trusted code. But as you note below, that's not entirely sufficient.
) you can still write down notes, take pictures of the screen, and so on. Hell, memorize the salient points and take them home.
Any document, once read, is in the wild. The best you can hope to do is a) make it expensive to copy, be it in time, effort or money, and b) make any given copy of the document identifiable enough to find a scape goat.
Which is why a security policy must incorporate both technical and non-technical measures. If you really can't trust the people you let read your sensitive information, you're sunk. THAT is my point.
Most IT environment security fails because they don't really have a crisp idea of what they want to accomplish - for instance, they want to give untrusted partners access to really sensitive information and then try to control what the untrusted partner does with their newfound knowledge.
That's the domain of contract law. You wrap up the untrusted partner in contracts that spell out consequences of violating what little trust you place in them.
You audit to verify they adhere to the contract terms, which spell out the security policy you require them to enforce.
You use MAC and MLS policies to keep them from getting to stuff you really don't trust them, under any circumstances, to see - your really private stuff, your other partners stuff, and stuff they just have no business seeing from you.
If only "defense in depth" had been defined in terms of MAC, DAC/Audit, Personnel Policy and Contract Law, instead of in terms of multiple broken unaudited DAC systems leaning against one another like a pile of dominoes.
Sorry, no - mandatory access controls mean that users of the system, including administrators, cannot override the security policy - which is usually expressed in terms of sensitivity labels on protected objects (data, devices, etc.) for comparison to clearance labels according to a dominance relationship.
NT and its successor OSes have always been considered "single level", lacking any concept of labels or supporting multiple clearances of users. Consider that they have been consistently evaluated under the Controlled Access Protection Profile (CAPP) of the Common Criteria, which maps to the TCSEC Orange Book C2 system requirements.
Whether NT was "built from the ground-up to enforce" mandatory access controls is moot - it's never been sold that way. And it can't be used that way, if you really care about "this class of users can have access to this, but THIS OTHER class of user can't". Which is what makes it so dangerous to use Windows on a DMZ supporting Internet users while giving the DMZ host access to internal systems.
In the case of the original post - DRM is a poor-man's attempt to use cryptography to get around the inherent weakness and insecurity of the operating system they've chosen to use - a fools game.
As you point out - on a weak system, anyone with read access to data can probably write it out somewhere, too. Not so with an MLS system supporting data integrity and/or secrecy protections, combined with adequate label integrity mechanisms for exported data (a form of strong DRM, if you like). Of course, protecting against undocumented features (Easter eggs) required another level of assurance, and the ability to verify that there are no hidden trap doors available for (or planted by) determined adversaries.
But that's grist for another post. This is already more than most are likely to read.
First, though, if you don't have a document handling and marking policy for PAPER documents, you're unlikely to succeed implementing one for electronic documents. In other words, if you don't presently mark printed documents with restrictive handling requirements ('secret', 'confidential', 'proprietary', 'atty-client privileged'), it won't do you any good to try to control their electronic versions.
Second, Windows has never been designed to try to enforce more than discretionary controls. What does that mean? It means that EVERYONE who touches the machine or its data is presumed to be cleared to see whatever is on the machine. They may not have the need to know what's there (that's what DAC does), but they're cleared to see it - so they're TRUSTED to handle it correctly.
If that doesn't describe your environment, you should reconsider whether a single-level system, like Windows, is suitable for storing, printing and using your documents in your environment.
Well, it's Fox News - that cub reporter was oh so promising in his better days at another network. But now...
Thank Rupert Murdock for yet another sterling contribution to public science...
And, herein lies the rub - the separate domains are interconnected, and there remains the question as to the assurance that is provided by the hardware and software systems that are responsible for keeping them segregated.
Today, those interconnections do not use (m)any of the principles of the old Orange Book (Trusted Computer Security, or TCSEC) Class A1 system security designs to defend against subversion - of their supply chain, of their maintenance processes, patch distribution, nor even the higher assurance design approaches that might lead to even EAL5 or EAL6 Common Criteria systems.
Rather, they rely on "defense in depth", which is a sort of fiberglass, or plywood, approach to construction - light, strong, but never designed to be penetration proof.
The TCSEC Class A1 (and to some extent CC EAL7) assurance measures are designed, specifically, to be able to demonstrate to an impartial 3rd party that there are no hidden back doors in the system to bypass security, whether intentionally or accidentally introduced. They do this through both rigorous analysis of design and correspondence checking between objectives (enforce a policy), requirements (implement the policy), design, development and maintenance of the security enforcing functions of the system. They're required to be formally specified, and demonstrably minimal in their implementation.
Full disclosure: I work for a company attempting to resurrect Class A1 (TNI Red Book, specifically) products for use in cyberspace applications. Its been done successfully multiple times, for multiple products. Some of those products have been specific function devices, and others were multi-purpose systems designed to provide trusted (no back door) enforcement of security functions (MLS) so that untrusted applications running on them don't have to. It takes a decade or more to accomplish from scratch.
Large systems are composed of many smaller systems. Plywood is a fact of life in both hardware and software. But when the security (assurance) of the system rests on small pieces known not to already contain holes, you can concentrate on the functionality provided by the plywood, instead of pretending you'll use it for strength and endurance.
It IS possible to create secure hypervisors and secure virtualization (see significant research results summarized in P.A. Karger, M.E. Zurko, D.W. Bonin, A.H. Mason, C.E. Kahn, "A Retrospective on the VAX VMM Security Kernel," IEEE Transactions on Software Engineering, vol. 17, no. 11, pp. 1147-1165, Nov., 1991. The abstract and the opportunity to purchase a PDF of the full paper are at http://doi.ieeecomputersociety.org/10.1109/32.106971 ).
But they're rare, and the current raft of hypervisors don't rate as being possibly secure.
One area in which they fail to pass muster is in regard to their layering. From the DEC paper:
"Strict levels of abstraction . . . as a means of reducing complexity and providing precise and understandable specifications. Each layer of the design implements some abstraction in part by making calls on lower layers. In no case does a lower layer invoke of depend upon high layer abstractions."
One noted security practioner (not me) has opined in private correspondence that, while "[c]learly much more than this is required (as reflected in the rest of the DEC paper), but without such a strict layering a VMM design cannot be considered a serious candidate, and is probably not worth spending time and energy on. The precise number of layers will depend on the particular design, but consistent experience over several decades indicates that for the kind of functionality in a VMM something on the order of the 16 layers in the DEC design are essential to "minimizing the complexity". A small integer number of layers is an immediate tip-off that something "smells rotten" in the design."
Such minimization of complexity is necessary to support the formal modeling and analysis that would allow you to verify that, for instance, there is no unnecessary code in the hypervisor that might be exploited by an attacker (whether deliberately inserted or not).
...sarcasm on
But, in today's world, who cares? These lessons were learned decades ago - they couldn't be relevant today...
...sarcasm off
Re:His involvement with the UniXware purchase?
on
Ray Noorda Dead at 82
·
· Score: 2, Interesting
Recall that Novell had also promoted the GEM desktop as an alternative to Windows, and purchased DRI to get an alternative DOS operating system. I joined Novell in '94, before Ray left, after the Unixware deal. So I think adding UNIX to the mix, along with WordPerfect, was part of Ray's idea of how to build an across-the-board competitor to the Microsoft dominion. Later, after Ray left the reigns to Bob Frankenberg (moved over to Novell from HP), I think we over-reached.
The dream was to combine UNIX with NetWare to create a kick-ass application server to counter the emergent Windows NT vision. Recall that UNIX had split into two camps - ATT/SUN and IBM/DEC/HP - but they were starting to work together better.
Novell had great ties to IBM. Novell got along okay with HP. Novell got along great with AT&T.
This was also the period in which Chorus and MACH micro-kernels were making great strides in getting attention from OS vendors.
Well, there was one proposal to bring things together around a micro-kernel. There was even a chance to bring OS/2 into the grand unification effort.
But it was too much - too many conflicting performance / security / legacy issues to deal with. The technologists couldn't bring themselves to make all the compromises necessary for such a combination to succeed.
In the end, Novell realized the unification wouldn't happen, and split up UNIX, selling part to HP and the distribution rights to the old SCO, who needed it to upgrade their OpenServer products (I think).
The rest, as they say, is history - Linux ascendent, SCO sold their name and UNIX distribution rights to Caldera (a Novell spinoff, funded by Ray Noorda). Caldera management changes then led to their ill-advised resurrection of the SCO name and disasterous law suit against IBM and Novell.
However, the legal risk of the kernel right now due to submarine patents is significant. I wouldn't be surprised if Microsoft were planning to fund a company to do this right now. It would be far cheaper than their current SCO-funded lawsuit, and a lot more effective. This risk, and potential downside, far outweighs that of going to GPL 3.
But spinning new ideas is only a small part of the plan. Sources familiar with Myhrvold's strategy say that he has raised $350 million from some of the largest companies in high tech: Microsoft, Intel, Sony, Nokia and Apple. Google and eBay also recently invested. With this large bankroll, the company is out buying existing patents in droves. (Myhrvold won't comment on these activities, but sources say he has already purchased about 1,000 patents.) The strategy is to set up a sort of patent marketplace. Patent owners get money upfront for the dusty ideas sitting on their shelves, the investors get the rights to use the ideas without being sued and Myhrvold gets to rent those same ideas to other companies that need them to continue creating products. Intellectual-property experts say his plan is audacious and unprecedented, customized for a new, rapidly dawning business environment."
Anecdotally, you don't want to ignore their first "invitation" to join their investment fund, either, I hear - it can be very, very expensive the second time they approach you...
Hmm, but it's okay to restrict its use in systems and devices that restrict users rights, like DRM?
Interesting.
Considering this post ironic (or not) is reserved as a freedom of the reader, and the use or redistribution or publication of the post by recipients may not unduely infringe on the readers right to make their own determination. Efforts to influence or bias the opinion by the reader as to the irony, or lack thereof, contained in the post constitute a violation of the authors' rights passed directly to readers, and a violation of those readers rights to make their own determination, and are so prohibited under the terms of this license. Redistribution of this post, including this license in its entirety, is permitted as long as the license is reproduced with such publication.
Well, if restrictions on use in DRM products is a "reasonable restraint" in GPLv3, wouldn't a restriction on use in products and devices designed to maime or kill also be reasonable?
After all, what are our priorities?
Considering this post ironic (or not) is reserved as a freedom of the reader, and the use or redistribution or publication of the post by recipients may not unduely infringe on the readers right to make their own determination. Efforts to influence or bias the opinion by the reader as to the irony, or lack thereof, contained in the post constitute a violation of the authors' rights passed directly to readers, and a violation of those readers rights to make their own determination, and are so prohibited under the terms of this license. Redistribution of this post, including this license in its entirety, is permitted as long as the license is reproduced with such publication.
Other posts are correct - IBM made this happen through manpower and expenses, to create the documentation needed for so many open source projects (lacking design documentation, for the most part), and for underwriting the evaluation labs effort.
But Novell/SuSE also deserves credit for running a top-notch configuration management system (Autobuild), having controls and procedures for keeping track of where which patches that get incorporated come from, and for having a patch notification and publication process that enables customers to get timely notification of necessary patches.
The business processes surrounding manufacturing the distribution and supporting customers on a global basis are valuable Novell/SuSE contributions.
Disclaimer: I work for Novell and work with the folks at SuSE on a daily basis.
Slashdot Mirror
It's not what happened to you that matters. It matters who you know, how often you talk to them, and who they talk to. Someone else will decide what that leads them to believe about you.
In other news, open source community takes another swing at Privacy Enhanced Mail, but this time with no trust anchor ...
I'm still not convinced that anonymity and accountability can coexist. At the very least, they need their servers to be accountable for the anonymity assurances given to their users.
It's the device drivers IN the motherboard I'm talking about - they constitute a huge block of code, supplied by who knows whom from who knows where that make up the BIOS and EFI bootstrap framework. They're what inform your OS kernel what devices are present, their characteristics, and in many instances provide standardized interfaces to them that the OS drivers themselves can simply invoke.
They operate BELOW the OS layer.
Check out the OpenFirmware.info community for more details, and know the motherboards you buy and use have them, too.
Hive mind, and all that?
It's not really possible to "opt out" of public surveillance. Can you imagine the difficulty of claiming the right to "disappear" off of other people's Google Glass (maybe by broadcasting a disruptor signal of some sort saying "ignore me, nothing to see here, move along"?
And how do you assure privacy to those who deprive others of it, themselves?
If privacy is outlawed, only outlaws will have privacy...
New thought really is required. Not sure all the angles can be squared.
Worrying about compromise of the Linux or Windows kernel is foolish - they're so large, they could have anything hidden inside and you'd never find it (searching for such is literally uncomputable). Begin your concerns with the device drivers from who knows where that are put into place by your motherboard BIOS or EFI boot systems. Conventional operating systems are entirely dependent on them, and they're completely beyond your ability to inspect or trust. And the Open Source variations have the same issue as the operating systems - large, monolithic blocks of code impenetrable to analysis.
You fear what you know about. Fear, instead, what you don't.
Ha Ha. Hahaha. I guess you missed the bit about how it is computationally infeasible (as in, halting problem) to definitively determine whether there are artifices in source or object code that deliberately mask and hide their behavior. See Naval Post Graduate School thesis and papers on how few lines of code need to be introduced to turn IPSEC implementations into clear text relays - turned on and off via encrypted key triggers.
A few years back, it was discovered that virtually every one's - and I mean EVERYone's - SSL and LDAP and PKI and IPSEC and SMIME and OpenSSH implementations were FILLED with defects - because they all were using the same open source ASN.1 library that was RIFE with buffer overflows.
The wonderful thing about open source code is that everyone uses it, thinking SOMEONE else MUST have vetted it, so all too many times, no one actually does.
No, actually, you can't. Its computationally infeasible to find deliberately hidden malware in a body of code, whether source or object. So no amount of analysis and/or testing can ever reliably tell you whether in fact your existing system is corrupt. You can only accomplish that by starting with a formal set of requirements that you can then successively refine into code that is (a) minimal, and (b) demonstrably maps directly to your formal specifications and their requirements. Any excess beyond what is minimally required to accomplish your task is a potential reservoir of latent malware. Note that such malware may be present in the source (ref. Ken Thompson's attack), or if it is, it may make use of various global state variables on the system as a trigger, or key, to unlock its functionality.
Give the long established practice in high assurance computer systems design to use segments to represent base-level security objects (so as to maximize alignment of hardware-enforced security policies with promised protections of the objects), will your new OS design rely on segments to represent security objects, or if not, what hardware abstraction will you use, instead?
Given the the long established history with reference monitors and Class A1 design, will your from-scratch OS follow TCSEC (Orangebook) guidance so as to provide verifiable assurance that no trap doors or Trojan horses exist in the code? If not, what is your approach, instead?
One, at least, has been developed, and certified multiple times, using x86 commodity PC hardware, with a proprietary security controller (to provide isolated identity secret key and crypto support, like would be provided via TPM chip, today)
What would it do if it ran in a virtual machine with thunks provided so that the virtual machine had direct access to the proprietary security controller? In other words, how easy is it to perform a MITM attack on the OS and security controller?
With a Class A1 security kernel, or a Class A1 VMM, each virtual machine access to hardware would necessarily be mediated by the TCB - thus the reference monitor - whether that's done via partitioning hardware to the VMs, or virtualizing some hardware (like network interfaces, console, etc) via trusted services provided by the TCB. The design would necessarily preclude your MITM attacks.
I wouldn't blame monolithic kernels per-se. In my secure computing utopia, hardware privilege separation wouldn't even be necessary. Formal verification at the instruction level provides everything (and more) that hardware protection could, while ECC verification prevents the exploitation of bit flips in pointers that was used against the JVM. Formal verification could be attempted on an existing monolithic kernel, and might even succeed, but the work would be in defining a secure operating model and then tracking down all the bugs that violate the model when the proof generator fails, and writing proofs by hand for the hairy parts.
No, formal verification of the monolithic kernels is not possible. At the system level, we want the formal verification to take the form "demonstrate that there is no insecure state into which the system may enter". Specifically, the verification needs to demonstrate that there are no hidden interfaces, not even cryptographically protected ones that use long keys of system-wide state to decrypt or enable them, as those are the sorts of attack that a determined adversary might be expected to use.
A rational approach is to use hardware mechanisms, like segmentation, and MMU-enforced privilege level separation mechanisms (e.g., rings) to reduce the footprint subject to subversion attacks. Yes, the hardware mechanisms need also to be verified and protected against modification (whether by changing resistance or capacitance values, voltage levels, or loading hostile microcode). But that's all part of the environmental and trusted distribution aspects of the system security policy, overall.
I'm a believer in layered, modular composition in this regard - it gives you at least a prayer of analyzing and understanding the nature of a system. Formally verify the hardware and the software allowed unmediated access to it. Allocate (TCB Subsets and partitions) responsibility for other aspects of your security policy to high layers and other processors. Rely on the formally verified TCB to enforce separation and controlled sharing of information according to the policies it implements.
Let applications be applications. Put your foot down when they try to be trusted, particularly with regard to memory management (paging, for example). In this way, enable the vast majority of applications to work they way they were intended to, without knowledge nor worrys about mandatory policies. If they're good applications, teach them to use search paths to aggregate their data sources, so they can "read down" without having to be taught anything about MLS - just add the appropriate paths to their search and let the TCB control whether and which can see what.
So - don't create a bias towards trusting apps - use trusted systems that protect apps from each other, and protects your data from even hostile apps.
As you point out - on a weak system, anyone with read access to data can probably write it out somewhere, too. Not so with an MLS system supporting data integrity and/or secrecy protections, combined with adequate label integrity mechanisms for exported data (a form of strong DRM, if you like). Of course, protecting against undocumented features (Easter eggs) required another level of assurance, and the ability to verify that there are no hidden trap doors available for (or planted by) determined adversaries.
Good luck implementing a system like that on anything but dedicated proprietary hardware.
One, at least, has been developed, and certified multiple times, using x86 commodity PC hardware, with a proprietary security controller (to provide isolated identity secret key and crypto support, like would be provided via TPM chip, today)
Virtualization is enough to blow mandatory access controls out of the water without even talking about Van Eck phreaking, physical separation between networks of different privilege levels, etc.
Virtualization DOES require special attention, which is what is so disturbing about the half-baked virtualization support provided for current architectures - see Karger's papers on requirements for MLS VMMs and experience learned working on the DEC Class A1 VMM effort.
In general, I would also disagree with your claim that a proper mandatory access control system allows users of different clearances to use the same device. Covert channels are too difficult to prevent without severely limiting the usefulness of the system. Basically if two users share the same CPU or hardware they can almost always find a way to use some resource conflict as a covert channel, whether it's just the average response time for a certain operation to complete or something like the key recovery attacks that use cache latency to actually steal keys from a non-cooperating process.
Covert channels are hard, but they're more manageable than the hopeless pursuit of zero-day 'sploits that characterizes modern commercial practice. That evaluated system I mentioned above included in its configuration options for the elimination of any storage channels, and controls to manage bandwidth of timing channels.
The disconnect is this - customers have arguably MLS applications (in the commercial sense) that they're running without benefit of even the most rudimentary controls on information flow. The security industry is wrapped up in a hopeless test-and-patch cycle that is demonstrably flawed. The consumer has to conclude, in this market, that computer security is an oxymoron at its heart, and unattainable by any means.
That's too bad. You CAN control information flows according to a sound, reasonable, usable security policy (integrity, secrecy, whichever). You CANNOT do it using systems that were never designed nor intended to do that. You CAN combine trusted systems with untrusted systems such that trusted systems prevent unintended information flows, while untrusted systems provide expansive functionality on the information you allow them to access. You CAN allow "read-down" by untrusted systems to lower security data IF the sharing of that data between sensitivity levels is provided by a trusted system (complete with controls on channels). No, you shouldn't let high systems issue their own request to low networks (ie, browse the Internet) without trusted mediation - either by doing the browsing from a trusted (high assurance) client with trusted cut-n-paste (a thin client would do), or via some trusted server intermediary to cache and clear low data for high system consumers.
But in today's world, everything, and I do mean everything, from routers to hubs and switches to firewalls, workstations and servers, run on multi-million line monolythic kernel systems, whether Linux, Solaris, BSD or Windows. None of those are evaluable above EAL4 (which is "low assurance" by definition).
That having been said, no matter how 'secure' your OS, right down to privilege separation by process (can't have a Top Secret level document open at the same time as a Secret level notepad
Actually, with a sufficiently secure OS, you can give TS subjects within your process ability to read, but not write, information at lower levels without copying it up to TS, without any trusted code. But as you note below, that's not entirely sufficient.
) you can still write down notes, take pictures of the screen, and so on. Hell, memorize the salient points and take them home.
Any document, once read, is in the wild. The best you can hope to do is a) make it expensive to copy, be it in time, effort or money, and b) make any given copy of the document identifiable enough to find a scape goat.
Which is why a security policy must incorporate both technical and non-technical measures. If you really can't trust the people you let read your sensitive information, you're sunk. THAT is my point.
Most IT environment security fails because they don't really have a crisp idea of what they want to accomplish - for instance, they want to give untrusted partners access to really sensitive information and then try to control what the untrusted partner does with their newfound knowledge.
That's the domain of contract law. You wrap up the untrusted partner in contracts that spell out consequences of violating what little trust you place in them.
You audit to verify they adhere to the contract terms, which spell out the security policy you require them to enforce.
You use MAC and MLS policies to keep them from getting to stuff you really don't trust them, under any circumstances, to see - your really private stuff, your other partners stuff, and stuff they just have no business seeing from you.
If only "defense in depth" had been defined in terms of MAC, DAC/Audit, Personnel Policy and Contract Law, instead of in terms of multiple broken unaudited DAC systems leaning against one another like a pile of dominoes.
Perhaps in another lifetime.
Sorry, no - mandatory access controls mean that users of the system, including administrators, cannot override the security policy - which is usually expressed in terms of sensitivity labels on protected objects (data, devices, etc.) for comparison to clearance labels according to a dominance relationship.
NT and its successor OSes have always been considered "single level", lacking any concept of labels or supporting multiple clearances of users. Consider that they have been consistently evaluated under the Controlled Access Protection Profile (CAPP) of the Common Criteria, which maps to the TCSEC Orange Book C2 system requirements.
Whether NT was "built from the ground-up to enforce" mandatory access controls is moot - it's never been sold that way. And it can't be used that way, if you really care about "this class of users can have access to this, but THIS OTHER class of user can't". Which is what makes it so dangerous to use Windows on a DMZ supporting Internet users while giving the DMZ host access to internal systems.
In the case of the original post - DRM is a poor-man's attempt to use cryptography to get around the inherent weakness and insecurity of the operating system they've chosen to use - a fools game.
As you point out - on a weak system, anyone with read access to data can probably write it out somewhere, too. Not so with an MLS system supporting data integrity and/or secrecy protections, combined with adequate label integrity mechanisms for exported data (a form of strong DRM, if you like). Of course, protecting against undocumented features (Easter eggs) required another level of assurance, and the ability to verify that there are no hidden trap doors available for (or planted by) determined adversaries.
But that's grist for another post. This is already more than most are likely to read.
First, though, if you don't have a document handling and marking policy for PAPER documents, you're unlikely to succeed implementing one for electronic documents. In other words, if you don't presently mark printed documents with restrictive handling requirements ('secret', 'confidential', 'proprietary', 'atty-client privileged'), it won't do you any good to try to control their electronic versions.
Second, Windows has never been designed to try to enforce more than discretionary controls. What does that mean? It means that EVERYONE who touches the machine or its data is presumed to be cleared to see whatever is on the machine. They may not have the need to know what's there (that's what DAC does), but they're cleared to see it - so they're TRUSTED to handle it correctly.
If that doesn't describe your environment, you should reconsider whether a single-level system, like Windows, is suitable for storing, printing and using your documents in your environment.
Then fake up your pictures of yourself. Public speech - it's PUBLIC!!!! OMG!!!!
Well, it's Fox News - that cub reporter was oh so promising in his better days at another network. But now... Thank Rupert Murdock for yet another sterling contribution to public science...
And, herein lies the rub - the separate domains are interconnected, and there remains the question as to the assurance that is provided by the hardware and software systems that are responsible for keeping them segregated.
Today, those interconnections do not use (m)any of the principles of the old Orange Book (Trusted Computer Security, or TCSEC) Class A1 system security designs to defend against subversion - of their supply chain, of their maintenance processes, patch distribution, nor even the higher assurance design approaches that might lead to even EAL5 or EAL6 Common Criteria systems.
Rather, they rely on "defense in depth", which is a sort of fiberglass, or plywood, approach to construction - light, strong, but never designed to be penetration proof.
The TCSEC Class A1 (and to some extent CC EAL7) assurance measures are designed, specifically, to be able to demonstrate to an impartial 3rd party that there are no hidden back doors in the system to bypass security, whether intentionally or accidentally introduced. They do this through both rigorous analysis of design and correspondence checking between objectives (enforce a policy), requirements (implement the policy), design, development and maintenance of the security enforcing functions of the system. They're required to be formally specified, and demonstrably minimal in their implementation.
Full disclosure: I work for a company attempting to resurrect Class A1 (TNI Red Book, specifically) products for use in cyberspace applications. Its been done successfully multiple times, for multiple products. Some of those products have been specific function devices, and others were multi-purpose systems designed to provide trusted (no back door) enforcement of security functions (MLS) so that untrusted applications running on them don't have to. It takes a decade or more to accomplish from scratch.
Large systems are composed of many smaller systems. Plywood is a fact of life in both hardware and software. But when the security (assurance) of the system rests on small pieces known not to already contain holes, you can concentrate on the functionality provided by the plywood, instead of pretending you'll use it for strength and endurance.
Looking forward to reading her reaction on Groklaw...
But they're rare, and the current raft of hypervisors don't rate as being possibly secure.
One area in which they fail to pass muster is in regard to their layering. From the DEC paper:
One noted security practioner (not me) has opined in private correspondence that, while "[c]learly much more than this is required (as reflected in the rest of the DEC paper), but without such a strict layering a VMM design cannot be considered a serious candidate, and is probably not worth spending time and energy on. The precise number of layers will depend on the particular design, but consistent experience over several decades indicates that for the kind of functionality in a VMM something on the order of the 16 layers in the DEC design are essential to "minimizing the complexity". A small integer number of layers is an immediate tip-off that something "smells rotten" in the design."
Such minimization of complexity is necessary to support the formal modeling and analysis that would allow you to verify that, for instance, there is no unnecessary code in the hypervisor that might be exploited by an attacker (whether deliberately inserted or not).
But, in today's world, who cares? These lessons were learned decades ago - they couldn't be relevant today...
...sarcasm off
The dream was to combine UNIX with NetWare to create a kick-ass application server to counter the emergent Windows NT vision. Recall that UNIX had split into two camps - ATT/SUN and IBM/DEC/HP - but they were starting to work together better.
Novell had great ties to IBM. Novell got along okay with HP. Novell got along great with AT&T.
This was also the period in which Chorus and MACH micro-kernels were making great strides in getting attention from OS vendors.
Well, there was one proposal to bring things together around a micro-kernel. There was even a chance to bring OS/2 into the grand unification effort.
But it was too much - too many conflicting performance / security / legacy issues to deal with. The technologists couldn't bring themselves to make all the compromises necessary for such a combination to succeed.
In the end, Novell realized the unification wouldn't happen, and split up UNIX, selling part to HP and the distribution rights to the old SCO, who needed it to upgrade their OpenServer products (I think).
The rest, as they say, is history - Linux ascendent, SCO sold their name and UNIX distribution rights to Caldera (a Novell spinoff, funded by Ray Noorda). Caldera management changes then led to their ill-advised resurrection of the SCO name and disasterous law suit against IBM and Novell.
See http://www.intellectualventures.com/
And from a Newsweek article: http://www.msnbc.msn.com/id/6478691/site/newsweek
Anecdotally, you don't want to ignore their first "invitation" to join their investment fund, either, I hear - it can be very, very expensive the second time they approach you...
Hmm, but it's okay to restrict its use in systems and devices that restrict users rights, like DRM?
Interesting.
Considering this post ironic (or not) is reserved as a freedom of the reader, and the use or redistribution or publication of the post by recipients may not unduely infringe on the readers right to make their own determination. Efforts to influence or bias the opinion by the reader as to the irony, or lack thereof, contained in the post constitute a violation of the authors' rights passed directly to readers, and a violation of those readers rights to make their own determination, and are so prohibited under the terms of this license. Redistribution of this post, including this license in its entirety, is permitted as long as the license is reproduced with such publication.
Well, if restrictions on use in DRM products is a "reasonable restraint" in GPLv3, wouldn't a restriction on use in products and devices designed to maime or kill also be reasonable?
After all, what are our priorities?
Considering this post ironic (or not) is reserved as a freedom of the reader, and the use or redistribution or publication of the post by recipients may not unduely infringe on the readers right to make their own determination. Efforts to influence or bias the opinion by the reader as to the irony, or lack thereof, contained in the post constitute a violation of the authors' rights passed directly to readers, and a violation of those readers rights to make their own determination, and are so prohibited under the terms of this license. Redistribution of this post, including this license in its entirety, is permitted as long as the license is reproduced with such publication.
All platforms.
But Novell/SuSE also deserves credit for running a top-notch configuration management system (Autobuild), having controls and procedures for keeping track of where which patches that get incorporated come from, and for having a patch notification and publication process that enables customers to get timely notification of necessary patches.
The business processes surrounding manufacturing the distribution and supporting customers on a global basis are valuable Novell/SuSE contributions.
Disclaimer: I work for Novell and work with the folks at SuSE on a daily basis.