Slashdot Mirror
Indian Military Organization To Develop Its Own OS
An anonymous reader writes "Several newspapers have reported that DRDO (the defence R&D organization of the Indian military) is planning to create an OS. The need for this arose due to the cyber security concerns facing India and that all [conventional] operating systems are made outside India. About 50 professionals in Bangalore and New Delhi are expected to start work on this operating system." At least one of the linked articles says the new OS, though home-grown, would run Windows software.
WINE doesn't stand for "Wine is not a complete, Windows-compatible operating system sans the security vulnerabilities".
I can't wait for the poor bastards to try outsourcing development to India.
The Wheel: It's tired of getting reinvented.
I know this is obvious, but come on...
Seriously, why not take a *BSD or Linux OS release and do a full source code review on it? It will take a lot less effort than creating anything from scratch, plus they can submit bug reports and code fixes back to the corresponding opensource projects. (Everybody wins!!!) Any mature OS would not be plagued by bugs that commonly occur in large new code bases. After reviewing and approving the OS, they can simply track changes of future releases in order to maintain trust.
Don't use Binary Blobs, I agree, absolutely, if you care at all about your Sovereignty. Get the source tree for an already very well secured OS like, say, OpenBSD, or perhaps Linux (though OBSD is, I believe, generally developed with practices that encourage better security - less focus on feature, more on audits and exploit finding/fixing). Have your 'trusted' developers from your nation go over every line of code, to make sure no trojans/backdoors/intentional exploits were added, then build it all yourself.
Of course, there is still always the possibility you have a hacked C compiler. Man, I can't remember the name of it now, but sometime in, I think it was the 80's, someone made a pretty famous presentation/paper about putting a self-perpetuating trojan into a compiler. You could give the compiler source code, and the binary of the compiler to the 'mark', but you could completely remove the exploit from the source code, as long as the exploit was coded to compile itself into subsequent builds of the compiler; that is, the binary was infected, but the source was not, but it didn't matter since the infected binary could build a copy of itself into the next build of the compiler. The exploit could then additionally do something like whenever it built other binaries or libraries, add some exploit code to them as well.
I suppose you need your own people to do a dis-assembly of the compiler to verify that. Or, build your own assembler in machine language, then build your own compiler with your assembler. Once you've done that, if you have a trusted compiler, and verified source code, you don't really lose security by using Open Source. If anything, it'll *probably* be more secure, if it's popular enough to have a lot of devs analyzing it and fixing problems.
Simple reason: "Everybody wins" is not an option in real wars.
Of course, there is still always the possibility you have a hacked C compiler. Man, I can't remember the name of it now, but sometime in, I think it was the 80's, someone made a pretty famous presentation/paper about putting a self-perpetuating trojan into a compiler. You could give the compiler source code, and the binary of the compiler to the 'mark', but you could completely remove the exploit from the source code, as long as the exploit was coded to compile itself into subsequent builds of the compiler; that is, the binary was infected, but the source was not, but it didn't matter since the infected binary could build a copy of itself into the next build of the compiler. The exploit could then additionally do something like whenever it built other binaries or libraries, add some exploit code to them as well.
That would be Ken Thompson.
What the fuck? A government checking the code it runs on computers with sensitive data is "national socialist"? You think the United States government doesn't do this on CIA and DOD computers? Or are you a nut against building roads?
We're talking about doing this only for government computers used for sensitive government data.
I find it amusing that some people think that a nation's defense research organisation, which helps build ICBMs, supersonic aircraft, tactical software and so on, needs advice from someone who reading slashdot on how to write an operating system.
Well, in the US -- I don't know about the Indian military -- the same defense establishment that operates those ICBMs etc. also mostly runs Windows. Which is a pretty clear indication that they do need help, and the Slashdot crowd would probably be a good place to get it.
This is at least partly personal experience talking. When I was a medic in the USAF, one of my secondary duties was "computer systems security NCO" for the ER where I worked. Which mainly meant light sysadmin duties, trying to keep machines patched and virus-free with absolutely zero support from the actual hospital IT staff, and debunking "I LOVE YOU virus" warnings and similar bouts of hysteria that Col. So-and-so forwarded to everyone's e-mail ("it must be true, the Colonel said it!") Actual security was a joke.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
As someone who knows a bit about the origins of NT, with regard to Windows NT, you are full that substance that leads to substantial growth in the business...
...". Eventually OS2LDR.exe got renamed, but it remained the same through at least the first release (I left Micrografx before the next release of Windows NT came out). In the end, Windows NT was more secure than it was when it started, but it was not "secure".
Windows NT first several beta's booted using the OS2LDR.EXE file from prerelease versions of OS/2 2.0. The first thing you saw on the console was "OS2LDR.EXE
Windows NT was not designed for security -- The first version was hacked together using bits of OS/2 2.0 code, ports of existing Windows code, etc. For the record, I worked at Micrografx when they (a) had source code and early binaries of Windows NT, and (b) was part of the team that worked on OS/2.
With regard to your spurious example implying ACLs make something secure, again, you've been shoveling out the stables. ACLs do not make something secure (they may contribute to a security solution) and the lack of ACLs does not make something insecure. Security is not about how you achieve something, security is about what is achieved. Fundamentally, the only truly secure computer is one that not connected to a network, kept behind several locked doors, with guards that are so well paid or loyal such that they cannot be bribed. This goes on and on, no software added after security is certified, no external access other than keyboard, no externally accessible disk drives/cdrom/usb, etc. Everything else is a careful balancing act of risk, vulnerabilities, and mitigation.