3 ms·
No, the best that could be expected in the early 90’s is formal proofs of security enforcing multiple independent levels of security (MILS) allowing the executi
by Veserv 4y ago
No, the best that could be expected in the early 90’s is formal proofs of security enforcing multiple independent levels of security (MILS) allowing the execution of arbitrary, malicious programs on the same systems handling TOP SECRET data in complete safety as achieved by TCSEC Class A1 certified systems contemporaneously.
In contrast, OpenVMS only ever achieved C2, security enhanced VMS B1 [1], and the NT kernel C2 [2]. NT kernel based systems subsequently maximally achieved EAL4+ indicating independent verification that it is adequate to protect against “casual, and inadvertent attacks”, but failed to demonstrate resistance against attackers with a “moderate” attack potential.
So, no, it is not the very best that could be expected in the early 90’s.
[1] https://web.archive.org/web/20151119105617/http://h71000.www7.hp.com/openvms/products/sevms/ https://web.archive.org/web/20151119105617/http://h71000.www...
[2] https://www.microsoftpressstore.com/articles/article.aspx?p=2228450 https://www.microsoftpressstore.com/articles/article.aspx?p=...
- dsr_ 4y agoWhat commercially available A1-evaluated systems existed with an evaluated TCP/IP stack?
- Veserv 4y agoIf you are not asking that rhetorically, then the Gemini Trusted Network Processor (GTNP) using GEMSOS achieved a Class A1 certification in 1995 [1] and included ethernet device support in its specification. This is adequate to implement a TCP/IP stack in a unprivileged context. My quick read of the report does not allow me to confidently assert that they do simultaneous ethernet device multiplexing which would allow a trivial implementation of multiple independent data streams over the same link, but they do appear to provide at least a generic time-partitioned device multiplexing solution which would allow multiple programs to transmit and receive serially rather than just being bound to a single program at boot time. This is adequate for a large number of use cases and removes the TCP/IP stack from the TCB and thus requires a lower degree of scrutiny as its failure modes do not cause whole system failure. If you are asking rhetorically, then what NT kernel, NT kernel derived, NT kernel component, or even any code associated with the NT kernel in any context has been evaluated to Class A1, Class B3, EAL6, EAL7, or equivalent demonstrating proofs of security adequate for usage in high assurance systems? Arguing the NT kernel has achieved less security as a tradeoff to allow it to solve a broader use case is only valid if they have demonstrated the ability to actually make a tradeoff by achieving high security in a narrower use case nominally or at least qualitatively similar. If they can not actually demonstrate the ability to achieve the alternative, then they are not making a tradeoff, they are choosing the only option they can do. And this is what they have demonstrated. At no point have they ever demonstrated a equivalent, or even qualitatively similar level of security at any scale within orders of magnitude of the scale demonstrated by the Class A1 systems. And it is not like they have not tried. They have attempted numerous times to certify, demonstrating a desire to succeed and at least meaningful effort to do so, and have failed to certify at anything more rigorous even in highly constrained configurations to the extent that they have given up. To use a analogy, this is like having two energy companies and one of them says, "We have chosen a fusion energy solution that does not generate net energy because we believe that only fusion will be adequate when we have a interstellar civilization that needs to operate in the interstellar void." while the other has a working, economically efficient, solar energy solution that generates energy on the Earth today. Asking, "Can you point to a solar energy system that could generate adequate energy in the interstellar void?" as a counter argument is just plain silly because the existing fusion energy solution also does not work there and in fact does not work anywhere in any context. [1] http://www.aesec.com/eval/NCSC-FER-94-008.pdf http://www.aesec.com/eval/NCSC-FER-94-008.pdf
- dsr_ 4y agoNot only was I not asking rhetorically, but I saw the Gemini TNP and am aware that it never had an evaluated TCP/IP stack, only, as you said, the potential for someone to write one. For about 4 months I was in charge of a Harris NightHawk running a B1 version of SVR3, which was two and a half pains in a half-pain glass. I'm not an NT kernel fan, either.