Indian Military Organization To Develop Its Own OS 466
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.
Re:Who can be trusted? (Score:5, Informative)
It was Ken Thompson, the man himself, that you're referring to. The talk in question can be found here: http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]
"Trusting trust" attack can be countered using DDC (Score:5, Informative)
You're talking about the trusting trust attack, which was made famous by Ken Thompson [bell-labs.com].
Thankfully, you can counter the "trusting trust" attack using a technique called "Diverse Double-Compiling" (DDC) [dwheeler.com]. See the linked PhD dissertation for details.
Re:Why not do *BSD or Linux code review and use it (Score:4, Informative)
Seems to me that plenty of countries (including the US) manufacture weapons for use and for distribution to other countries. Thing is, you're not at war most of the time, and you're almost never at war with everyone.
Re:Oh For Chrissakes (Score:3, Informative)
Re:offtopic but hilarious (Score:4, Informative)
Hotmail does run on Windows. When it was purchased it did not, and it took them some time convert it. The "stories" about conversion failures were rediculous, the timelines did not give enough time for a real conversion of such systems, and people probably mistook various prototype testing as real attempts.
Sourcesafe was also never meant for anything other than workgroup projects, not large scale. As such, nobody would be expected to run something the size of the windows code base on vss. Nowadays, Microsoft has an enterprise class version control in Team Foundation Server, but I imagine they have a lot of legacy to convert to move that to TFS any time soon.
They also ran a large part of their internal processes for years on an AS/400, including accounting and other aspects. Microsoft didn't have applications to do what they needed on Windows, and didn't really want to invest in building them. However, now that they bought Great Plains.. that's a different story.
Due to legacy concerns, they aren't likely to convert from p4 for a very long time, although the beauty of git is that in workgroups you can use git and push changes upstream. If anything, they're most likely to convert to TFS, for long term overall project.. Already most of the tools development, web development, etc.. is done on TFS.
Re:Oh For Chrissakes (Score:3, Informative)
If their intention is to "run Windows software", as the summary states, then I think they'd get farther along by forking ReactOS.
Sure, its basis isn't "written at home", but unless it's merely a matter of national pride, you still have essentially the same advantage with OSS. Namely, that you can look at everything and verify what it does before using it in a security-critical environment.
Re:I hope they name it CURRY (Score:3, Informative)
Actually, a Haskell Indian Nations University, named after a guy named (Dudley) Haskell, a white guy tangentially involved in its creation. But the irony is still appreciated.
Re:Mod parent up. (Score:4, Informative)
Well OpenBSD it practically is. Some articles claim it is written ground up for security, but in reality they audited the entire BSD codebase many years ago, rewriting large parts [openbsd.org] and all new code is ground-up secure. In practice it is extremely secure, many of the bugs that occur in other BSDs or linux turn out to have been fixed months or years before in openBSD
Re:Already an open source alternative to windows (Score:5, Informative)
The trouble with Windows [compatible] OSes is not that it should be capable of running software written for Windows. It is that Windows itself has design weaknesses for various reasons not the least of which are related to its DOS based origins and support for old, misbehaving "legacy" software. To write a Windows compatible OS, you would also have to mimic a wide range of idiosyncratic behaviors in order to support Windows applications.
Now, if for some reason, all the bad-behaving software were cast aside and only good Windows software were used, the notion might stand a chance. I remain quite skeptical it, or any Windows-compatible OS, would become completely viable.
Looking at it another way, the SaMBa project is constantly playing catch-up against the moving target that is Windows networking. And that is just one aspect of the Windows OS family. Imagine this on an entire OS? It would be hard pressed to actually work.
They'd be better off making a BSD modified OS and pulling in WINE.
Re:Mod parent up. (Score:3, Informative)
Until the early to mid '90s, the term 'UNIX Security' was considered a joke. In comparison to systems like OS/370, VMS, and so on that were designed for security, UNIX was a toy. It didn't even have access control lists for files, and trust was entirely binary - if your web server needed to be able to bind to port 80, it also got the ability to modify every single file on the system, write directly to devices, and so on. Linux adopted the UNIX lack-of-security model from the start, although has recently gained some slight improvements.
In contrast, Windows NT was designed to be secure from the start. Every kernel object (file, thread, process, and so on) has an access control list associated with it. This can grant fine-grained permissions to individual users or processes. Unfortunately, the kernel was then given to the UI and DOS compatibility teams, who decided that world-accessible was the correct permission for pretty much everything and that the default user should be the administrator, who can override most permissions.
Plan 9 is closer to what the UNIX model would look like if security had been a concern. It's recursively virtualisable, so you can trivially jail processes.
Re:Mod parent up. (Score:5, Informative)
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.
Re:Mod parent up. (Score:3, Informative)
And when I was young, we had to walk to school, uphills both ways. We had to wrap barbed wire around our bare feet for traction on the dry ice that formed due to the cold.
In other words: I did claim that *NIX has always been perfect. I am simply saying they got their shit together a lot better, faster and more thoroughly than the Windows world.
Not true. The security model of UNIX is DAC based, reflecting a past when systems were secure by isolation. Almost no one was connected back then. The systems of the day did not reflect any of the realities Windows systems face nowadays. Not that it absolves the security blunders committed in some of the design of Windows. But the security architecture of NT (based in great part on VMS which was a lot more secure from the ground up than UNIX) is superior than what you find in a typical out-of-the-box Unix system.
Very few people armor their Linux distros to support MAC/RBAC (even when there are business reasons screaming for it). And the poor security track record of Windows systems have little to do with the NT security architecture, and more to do with the sheer number of deployments; the ambiguous role of providing "easy of use" in a time of great internet connectivity; and poor configuration practices (of which Linux folks aren't that innocent either.)
That the UNIX world got a security model faster than NT is trivially true. After all, the security model is DAC based and a reflection of the state of systems security and nature of installations 30 years ago.
Re:Already an open source alternative to windows (Score:3, Informative)
They can have it. They could use BSD as a base.
Or they could just start with Linux and the GNU tools and make their own variant. The code is all theirs. The GPL only requires source code be provided when the software is transferred. Merely providing the software for use doesn't entitle each person sitting behind the keyboard to a copy of the source. If it's all under control of the DRDO at all times, they are not required to provide the source code to anyone.
Also, the GPL is only effective due to strong copyright laws. If they wanted to add a copyright waiver to their laws for national security reasons(which may or may not already be there), that would work too.
All I'm saying is if they wanted to use Linux, they could. And they don't need to share the source with anyone.
Re:Already an open source alternative to windows (Score:3, Informative)
ReactOS does pull in wine - last I read. But as the wine developers will tell you, Windows basically sucks. There are so many hacks and kludges which have been developed in Windows over the years, the wine guys are forced to constantly re-implement them. Far too many applications actually demand improper behavior from the OS APIs to function properly. Even worse, this behavior can depend on which MS OS variant its running under.