I have finally found a way to write more blogs!!! When I am in the office I have so much work that I rarely get enough time to sit down and concentrate on a blog. When I get home (My wife tells me normally later than she wants me to) I do not always have the desire to write a blog. But I am flying for work this week and I am finding all kinds of time!
What for me the line is that epitomizes the fact that I must have turned into my parents is “When I was Young”. Yet I am finding myself starting this blog with exactly that.
First a let me describe he catalyst for this blog;
A few months ago I attended OSCON 2006, one of the sessions I went to was called ‘PHP Security Hoedown’ given by Ed Finkler (http://homes.cerias.purdue.edu/~coj/phpsecinafo)
Basically, what this session was about was talking about PHP security. The session was a response to security problems people have been finding with PHP. Specifically the installations and running of PHP.
He stated that a large part of the Security problems that PHP seems to be suffering from can be summed like this (I have taken some liberty to paraphrase some of the things that where said, but check the above link to his original presentation.);
PHP has a fairly shallow learning curve. Because it is a shallow learning curve, there is a lot of variety of people that are wide in range of skill sets. Basically almost anybody can get started in PHP and get something running pretty quickly.
There are really only a small percentage of top level people who could be considered ‘experts’ in the language.
So, now we are getting to the part that I warned about. ‘When I was Young’.
Many moons ago, now more than I am willing to legally admit to, I started my career with Philips/AT&T who at the time had a joint venture, they developed very complex digital telephone switches. The 5ESS line. This was a very sophisticated telephone system that was almost completely written in C.
When I started my programming career with AT&T (Now over 20 years ago) you had to go through a lengthy process of learning the language C. Carrier grade software was and still is of very complex nature. Since people that have ever written in C know, it is a very powerful language that provides you with a very large gun to shoot yourself in almost every body part you can if you are not careful. So we where trained very well before we where let loose writing switching code. One of the other things that was required, if you wanted to make the jump into C++ (Mind you this was when there was no C++ compiler yet, but only CFront which was a pre-compiler/parser), you where not allowed to write in C++ unless you have been programming C for at least 3 years consistently.
There really where not that many higher level languages as there are today.
For the last few years I have seen more and more computer languages born, and in some cases die. And they all try to fix what their authors thought where missing in the languages that came before it. Another trend has been to make languages more accessible and easier to use to people who want to program of all walks of life. Imagine that! A language that does not require a 4 year degree to work in!
Some of these languages for example PHP and Ruby (They sure are not limited to these languages I might add!). They allow people with limited computing background to make in fairly decent programs in a small amount of time.
But this is where some of the security issues are showing up. The languages are becoming easier to use. But a lot of the operating systems they run on really have not become easier. So, many of these programs are now used without the realization on the part of the installer or programmer what the effect and impact of running their programs are on the operating systems. This seems to be a problem on both Linux and Windows platforms.
Although I applaud making programming languages easier for the more casual user, I do see that we are forgetting in many cases to make the environments these programs need to run in safer and easier as well.
I have seen so many times programs that write their files in ‘interesting’ and unsecured places. The presence of multiple libraries that might or might not support the application (heck, I am not sure what makes the thing run, so I will just copy all kinds of libraries in an attempt to make the application work).
File permissions that are set incorrectly, readable by the world. Incorrect owners etc.
And these are just some of the issues that seem to be present. And unfortunately a lot of these problems are easily fixed.
But I think that we need to do more as developers and system architects. Some of the suggestions that come to mind are:
- Provide Security and architecture primers as part of the languages that are being developed. This should make it easier for the end app developer to have an appreciation of the program they wrote and what environment it will run in. (Tips and tricks documents, do’s and don’t documents etc)
- Keep up with the development of the operating systems to make if safer/easier to deploy these new languages. UML in Linux might be a step in the right direction, and so is the new security mode that Internet Explorer runs in on Vista. But more needs to be done.
- Have experts in the language provide more support in the area of the interaction with the OS and application programming for the target audience.
- Make installers easier to use and smarter. Taking a lot of the work of deployment out of the hands of those who want to write code without needing a masters in the OS they are deploying on. WIX for Windows does a very nice job. And there are a few on Linux as well (rpm for example) but I would say they have some way to go so that they are easy and safer to use.
- Have ‘self check’ modes on the languages that are being developed. E.g. Start the program the end user just wrote and the language will have a mode that will warn/comment/suggest things to the app developer. (Such as there was lint in Unix. But it should be part of the execution of the application program. And it has to be user friendly. Lint at times was downright sadistic in trying to decipher J)
- Force files to be created in safe areas.
- A lot of OSS software comes with ‘configure’, which is a very old and robust way of building make files and their dependencies. Now create something called ‘deploy’ that will do the same thing for the completed applications the end programmer just created. The things it should check for example are:
o Are the libraries it needs in the correct place
o Set up the environment variables if needed
o Does it follow the language authors best practices for deployment. (Make application programs go to /usr/local/bin instead of /bin)
o Make sure that the directories it gets deployed in are not owned by the wrong owner/groups
- Have more interaction with the OS developers and the Language developers to help each other build better languages and safer deployments on the OS.
It seems to me that languages need to be developed more with the end user in mind regarding deployment and the OS’s they will be running in. A language can have all the cool features you ever thought off, but if on deployment you create system issues of worse a bad security hole, than it all will have been just a hobby.
I can equate it to getting your drivers license, getting your license is fairly easy (at least in the US it is). And you can get it without knowing anything at all about cars. Car manufacturers have realized this and have made their cars tell the driver what is wrong with it. Now if you keep on driving your car with the ‘check engine light’ on, well than you are on your own.
If we want languages to be adopted and thrive, we better find a way to build in a ‘check program’ light.