A really secure OS and working environment will require someone manage it. There’s no way around this.
The reason why is that the OS, applications, etc can’t do anything more than give you tools to implement your security model. There’s no way you can automate the creation and maintenance of your security model on a computer.
I’ll give an example: Let’s say we work together on some project. Doesn’t matter what. Let’s say you’re my boss, and you’re a member of the design/review team of some classified product or something where we don’t want everyone in the company seeing what we’re working on.
OK, we need to set up a group for all the members of the project group, so that all members of the group can read/write the files. Let’s say that someone high up in marketing wants to be able to read the files, but we don’t want to allow him to make changes. Well, we now need to have read/write/modify privs for every member of the group, and he doesn’t get write/modify privs.
You, as a manager, need to be able to see management stuff, performance reviews, etc - so those files and programs need another security ID that the workers bees don’t have.
With this trivial example, you see why security will never be something that can be delivered as a turn-key solution, no matter the OS. Both Windows and Unix can do what needs to be done in the example above, with very similar concepts, but someone needs to implement this security model using the tools provided by the OS. The difference is that so many Windows systems run with the user as an Administrator to make sure everything “just works” and with all users as “administrator” they can get around much of the security - and running as Administrator means that any exploit code given to them runs with full access to everything. In Unix, most of the time I’m running as a plain user, and when I need root access, I “su” or “sudo” to perform what needs doing.
Most of the exploits on Windows would be stopped or mitigated if the Windows security model would be set up by more people to eliminate users running as Administrator. Microsoft could help out a lot here too, if they’d make it more difficult (or annoying) for users to run as Administrator by default.
When it comes to vulnerabilities and exploits, I view many of these as a software reliability issue. The #1 issue that I’d change if I had a magic wand to wave over the US software industry to improve s/w reliability (and therefore reduce security exploits) is to banish C, C#, C++, etc from the software industry and require a language like Ada be used. In the old days, we had a saying that expressed how we felt about software reliability from various programming languages:
“C is a language for consenting adults, Pascal is a language for children and Ada is a language for hardened criminals.”
In today’s computing environment, there’s lots of for-real criminals with for-real criminal gangs behind them. If we really want reliable software, we need to ditch the “hippy languages[1]” of the late 60’s and early 70’s and start using modern languages with very tight and explicit specification requirements.
What the US needs now is a model OS written in Ada, with the source code available to all comers. Just put it out there as a easily licensed product of the US government, much as TCP/IP started in the 80’s.
[1] I call C/C#/C++/etc “hippy languages” for their lack of enforcing discipline on the programmer. Want to use an array name as a pointer? “Do it if it feels good, man!” Want to cast a number into a pointer? Groovy, baby. Both Unix and Windows fail in this aspect. VMS (the older VMS, before OpenVMS) was written in a proprietary language called “Bliss-32” which was more explicit about what was happening to pointers. The most secure OS I’ve known of, Multics, was written in IBM’s PL/I, which was a powerful language which was around before Ada, but PL/I had the type, bounds and other checking that I associate with software reliability.
Wow... never thought of Ada as any kind of secure language..heh. Now, C, C++ maybe - less people seemed to know there way around, but Ada, much like Pascal - too English like... Not really sure how you can compare that to secutiry problems...but hey... Each to their own perceptions...
Now you are correct that an Administrator needs to have control for security reasons and does in most large companies (I was one of those awful fellows with a bunch of C, C++. and Assembly programmers) but I did manage to keep things safe (now maybe it was because I was a programmer myself). Not so sure that it would have been any different in a Unix world.
You do seem to be talking a bit out of line...or maybe out of your butt here...
Hey, where did you go NVDave? Was looking forward to a good conversation on programming languages etc... You seem so knowledgeable about them, I was looking forward to gaining additional experience.
After all, have no experience in Ada, only Assembly, C, C++, Pascal, Fortran, DBMS, Databus, and a few others (Oh and have written and had published or should I say provided purchased programs in several languages). Might be interesting to talk.
Agree 100% with this post. (Sigh, I really liked PL/I, back in the days...)