Today news sites repeated the monthly Microsoft execute says "Linux is insecure" articles. And while they are comparing apples with oranges (as Linux distributions ship with far more servers and network services than Microsoft offers), it's hard to deny the fact that Linux is also insecure. Essential and security critical packages like OpenSSH, LSH and OpenSSL had exploits in the last weeks and this should have convinced the last conservatives that it is not possible to write a complex server in C without having a remote exploit per year. All these exploits were caused by manual memory management that is relatively hard to avoid in C. But that's not even the point that I want to make, you can also have security problems in other languages. What free software (and also the proprietary competition mostly) lacks is a way to make securing your computer easy.
Let's assume a somewhat experienced user wants to find out which TCP/UDP ports are open, reconfigure all servers to accept only local IP addresses and otherwise shut the service down. In an ideal world the user could use some administration GUI to get a list of all ports that are open, with a user friendly service name (not the path of the binary!) for each port. Then the user right-clicks each of them and selects "Configure this service", a configuration GUI for the service appears and the user does the neccessary configuration.
The reality on a Linux system is different: first you do a "netstat -lp" to get the binary paths and PIDs of your daemons. The command to get the list of open ports is hard to find out unless you have some book about Linux administration. Maybe there is a GUI for this and I don't know it, but it is rather unlikely, as there is another problem on all Unix systems: complex system management functions are only available using the command line. There is no portable way to get the list of ports and the processes that use them, just as there is no good way of copying files without losing extended attributes or mounting a device. As a solution some apps try to call the command line tools, which results in bad progress information and horrible error messages (as you can see when you try to mount something in KDE and it goes wrong). Whatever, when you have the netstat list the real fun begins: trying to find out how to configure the service. Unfortunately Unix developers showed a lot of creativity in inventing new configuration systems for servers. Some, like CUPS, have a web administration interface that's fairly easy to use, when you are able to remember the port number. Others may even have a GUI administration tool, you only need to remember the name of the command to start it. But most of them did the worst imaginable, they invented their own free form configuration file. Each of them is completely different, the configuration files of Apache, Samba and OpenLDAP have nothing in common. And most of them share the property that they are so complex (or powerful, if you want) that it is extremely hard to write a graphical administration tools that can read a hand-written configuration file.
Right now the situation for servers on Linux/Unix is like X11 10 years ago. Almost each popular server is written using its own framework, uses its own configuration file format, has its own way of being configured. Configuration while the server is running is often not possible (and how should it be, if it is configured using a monolithic text file). There is no common way to get online statistics from the server. Many even come with their own user management and their own permission system. The only things that are standardized are starting and stopping them (/etc/init.d) and the syslog.
Servers need what free desktop applications needed before KDE came: a common framework. A common way of configuration, a common way of being configured using GUI tools, a unified view to monitor them... there are also options that many server have in common, like a IP to listen to or the allowed IP ranges. So users would have to configure them only once and maybe select the server that should use this setting. You could also have several 'levels' for network security. E.g. at home you may want to have your personal webserver running for family members, so you set it to 'medium'. But when you take your notebook to a cafe with a WLAN hotspot you switch the network security level to 'high' so other people in the same WLAN can not access your server. I think there are many other new possibilities to make your system easier to configure (and servers easier to write) by letting them use a common framework, just like KDE brought many advantages to X11 applications.
As I argued before I think that desktop applications and servers should share a framework; it doesnt make much sense to maintain two separate frameworks and a server also needs a GUI. And this also explains what's currently going on in kdenonbeta/kdeutil and kdenonbeta/knot.
Syndicate Blogs
what you're talking bout is a register kind of thing...
...or the OSX equevalent (this sound less harmfull
).
Standardising configs (lets say on XML) and adding some tree-like structure (hell we're on UN*X so we use the filesystem for this job!) has been done by others (OSX+, Win >95). Only they thought they could speed it up by putting it all in a database! Database or not -- i don't care: same shit different tools (read: color of toilet-paper).
Today all this 'config handling' is up to the distro -- I cant see a day when this will change. Most distro's are conservative bout their way of doing things (never fix things th'ain't broken).
THINGS AIN'T BROKEN, ohh no, THINGS ARE A BIT OLD FASHIONED! And thats THE WAY WE LIKE IT!!
My list of things that need reimplementation (a fix
) in UN*X:
- the filesystem-tree (I quite like GoboLinux experiment)
- the boot scripts (go multithreading, go python)
- configuration files (I think XML looks to cluttered for this, although it would suit the job)
- the package management, one to rule 'm all! (the best of deb and portage)
- X and the framebuffer should play very nice with eachother...
- one sound system (JACK looks promising)
- one print..sy.t.m....... allready CUPS!
- one documentation format/place (with working links please)
BUT see the satements above for my opinion on why this wont likely happen...
I only intend to talk for the DESKTOP UN*X here! Server will change after new stuff has proven to be rock solid, and mr.admin got used to it
.
Cheeearss -- burp,
Cies.
Webmin
I think what you referring to is already available, it's called webmin. I use it for alot of tasks, it's especially well suited for postgresql / mysql work. Going to a common configuration, would be rather difficult. Comparing a mail server to the sshd daemon is like apples and oranges. You could go with a common configuration database like the widows registry, but that makes configuring it more difficult rather then less and if you corrupt it, your entire system is hosed. Do we really want someone who knows nothing about configuring a systems server thinking "I have this GUI, I know everything"? It hasn't worked so well in the windows world, there are alot of insecure windows systems that were very easy to configure that way. One problem with asking for complete uniformity is who's going to get all the developers on board? They certainly don't answer to kde or gnome or IBM etc. Insecure software is a fact of life, you have alot of people, very smart people, dedicated to exploiting any loophole possible. What is important is vigilance by the developer. Microsoft has had vulnerabilities that have gone unpatched for months. The turn around for openssh and like programs have been recorded in hours. A cool GUI or common configuration won't solve a problem with a developer who is not vigilent. If you want to check open ports and security of your servers, there are easier to use tools than netstat or nmap. Try SAINT it's been around for years and is very easy to use. Network Security is a specialty and information on securing UNIX systems abounds on both the internet and books. Securing your network takes thoughtful planning and research. Why? Because that is what your enemy is doing.
One thing opensource has that the proprietary versions lack is an entire army of people with real world experience documenting that on the web. As an example do a search with google on the words postfix + spamassain + Antivirus. Viola! pages and pages of howto's, mailing list archives etc. The same search applied to windows+spamfiltering+antivirus yields, hundreds of products you can buy, but very little information except how to filter your inbox. That's one of open sources greatest strengths, a community mentality.
Re:Webmin
I think what you referring to is already available, it's called webmin.
No, it is only a superficial solution, comparable to Yast and other tools that distributions ship. It does not help to unify server file formats, to share code, to allow online communication between servers and administration tools. It doesnt even help you to write real GUI clients. It is a complicated solution for some problems, but not for all.
Going to a common configuration, would be rather difficult. Comparing a mail server to the sshd daemon is like apples and oranges.
They share many things, for instance both have a account-based permission system. And both have a TCP port that you can configure (which port to use, which addresses to listen on, which addresses can access it etc).
You could go with a common configuration database like the widows registry, but that makes configuring it more difficult rather then less and if you corrupt it, your entire system is hosed.
A common standard for configuration does not mean that it is not text based anymore or that you can only backup/replace single files, see KDE's KConfig and Gnome's GConf.
Do we really want someone who knows nothing about configuring a systems server thinking "I have this GUI, I know everything"?
Do you really think that you should establish unneccesary hurdles for users to prevent them from configuring their own system? Do you think that this will make the user decide for your system instead of the competition?
It hasn't worked so well in the windows world, there are alot of insecure windows systems that were very easy to configure that way.
This is not because configuring is too easy, but because the administration tools are bad at supporting the user to create a secure configuration. E.g. an administration system should warn the user when she does something stupid. If you are really concerned, then make sure that the administration tool allows only secure settings. If people have insecure systems the user is not too stupid, the developers are. After all even the most experienced users can make mistakes.
One problem with asking for complete uniformity is who's going to get all the developers on board? They certainly don't answer to kde or gnome or IBM etc.
You could have asked the same thing 10 years ago, before KDE and Gnome
existed.. making software better and development easier gets more developers on board.
Insecure software is a fact of life, you have alot of people, very smart people, dedicated to exploiting any loophole possible.
But there are huge differences between platforms. For instance you will not find a single buffer overflow in a pure Java app, simply because Java and its libraries are designed in a way that makes it impossible. But they are the most common and dangerous type of remote exploit for servers.
The turn around for openssh and like programs have been recorded in
hours.
That does not matter at all if people do not patch all their systems immediately. Which they don't. And for various reasons they do not want to have patches applied automatically. In other words, you won't get around a platform with better security. And, of course, users will prefer a system that they have to patch less frequently and has a lower risk of being hacked.
If you want to check open ports and security of your servers, there are easier to use tools than netstat or nmap. Try SAINT it's been around for years and is very easy to use. Network Security is a specialty and information on securing UNIX systems abounds on both the internet and books. Securing your network takes thoughtful planning and research. Why? Because that is what your enemy is doing.
It doesn't make much sense to write applications that check your server, instead of including this into the server (or better: into the server's framework). The author of the server will be better at finding out whether it has a known exploit.
Securing the system is the responsibility of the developer, and it is irresponsible to expect that from a user. More importantly, it does not work. If a system is too difficult to set up, people will go to the competition. All you can do is make it as easy as possible to set up a functional but secure system.
One thing opensource has that the proprietary versions lack is an entire army of people with real world experience documenting that on the web.
That's fine, but for the majority it is still more convenient to find a checkbox in a administration tool than finding a manual in the net, reading the relevant part of it and then do this.
More importantly, this is not realistic for the majority of users. People who find HowTos on the net have more knowledge in orders of magnitude compared to the regular computer user who is proud if she managed to share a folder.
Yesterday I saw a mainstream show on german tv (SternTV) where 'computer experts' showed the stunned audience that when you are using a 'wireless network' and you type something into your computers, 'hackers' can see the words that you wrote on their screen. And all they needed was 'a standard computer with an antenna' (this is no joke, they really said 'with antenna'). Later they recommended that you set a password for your wireless internet.
This is the group of people who sets up most servers. Of course not databases or directory servers, but stuff like file and printer sharing and maybe even small web servers.
Java-style API
I took a glimpse at kdenonbeta/kdeutil and I wonder why the API is so Java-like. Don't you think that it makes it harder to use for C++ programmers since Java has different idioms than C++.
What exactly?
What exactly do you think is too Java-like? The APIs are intended to be KDE/Qt-style, albeit with exceptions in some namespaces and more value-based/explicitly shared types (more like QByteArray and QDom than the QObject classes).
Obviously there are some classes heavily inspired by Java and .Net:
KDE::IO::InputStream/OutputStream are Java concepts, and taken because abstractions for byte streams are extremely useful when they are simple and easy to implement, especially as building blocks for other APIs. I often missed an equivalent mechanism in KDE.
KDE::IO::Console is a concept from .Net, but uses Qt terminology and offers a operator<< for comfortable output in C++.
The whole KDE::Test namespace is similar to JUnit and similar frameworks, but much simpler (I reduced the number of interfaces & classes by including a hierarchical structure in the base class) and with a Qt-slots based Test class.
The rest does not resemble other languages/platforms.
Re: What exactly?
Hi Tim,
My comment was targeted at the InputStream/OutputStream classes. But on a second thought, the idea I had in mind (deriving from streambuf) while looking at your code, would probably be to C++ like. It wouldn't follow the KDE/Qt-style.
I sometimes have a problem with the Qt-API because I was a C++ programmer before I started to work on KDE. So you should probably just ignore me.
Also what is the advantage of the Console class? What does it offer that cout/cerr doesn't have? I'm just curious and lazy.
Christian
Re: What exactly?
My comment was targeted at the InputStream/OutputStream classes. But on a second thought, the idea I had in mind (deriving from streambuf) while looking at your code, would probably be to C++ like.
Actually the main problem with streambuf is that it does too many things. QIODevice has the same problem. Thus not every QIODevice implementation supports all features, for instance a TCP QIODevice can not seek and does not have a size. Some QIODevices may be read-only or write-only. And both QIODevices and streambuf devices have different states, they can be opened (with various modes in the case of QIODevice) or closed etc.
When you now write an API function that needs a byte stream as input and you use a QIODevice or streambuf as argument, the function prototype itself is not enough to describe the data that the function needs. You need to know whether the stream must be already opened or the function will open the stream, you need to know whether the stream must be writable and/or readable, you must know whether the function requires the stream to be seekable and able to specify its size, you may need to know with which flags the stream has been opened, and so on... And these conditions must be put in the API documentation and you should try to validate them in the function itself.
Some properties can not be checked at the beginning (e.g. whether the object can seek), so the function may still fail at runtime when the programmer did not follow the instructions, possibly causing hard-to-find errors.
Another problem is that in order to use them in your APIs you often want to write sub-classes of the streams, and this is more difficult when the class has more capabilities. OutputStream and InputStream can be implemented by writing 1-2 simple functions.
If you need more than InputStream offers, you can still extend it; you can also write filtering streams that add capabilities, such as Java's BufferedInputStream.
Also what is the advantage of the Console class? What does it offer that cout/cerr doesn't have?
It doesn't really offer new capabilities over cout/cerr. It has just a consistent interface, supports Qt'ish data types (such as unicode-correct handling of QStrings) and allows to access STDIN/STOUT/STDERR as Input-/OutputStreams.
The main problem that it intends to solve is that Qt does not have any good support for i/o in command line apps. There are qDebug() and friends, but they are not really comfortable and it is not obvious whether the output will be written to STDOUT or STDERR. Qt also lacks direct support for apps that read or write binary data from the command line.