[ Site Index] [ Linux Index] [ Feedback ]
Logging
In the wake of the recent ILOVEYOU email virus, UNIX and Linux users may be feeling a bit smug. After all, these systems are immune to email viruses, aren't they? ILOVEYOU (and the destructive Melissa virus that preceded it by a year) rely for their efficacy on big security holes in Microsoft's desktop operating systems; notably, the lack of any kind of privilege system to control access to files and system resources, and the ability of a mail client (Outlook) to run scripts that can do things to files without any kind of authentication.
These vulnerabilities exist because Microsoft's operating systems evolved in the precambrian era of computing, on single user, non-networked machines. UNIX and Linux, in contrast, were networked almost from the beginning and support multiple users, so some degree of security is built in. But by the same token, they're vulnerable to different types of attack.
If you run a Linux system, your first line of defense against attack is the system's own logging mechanism. Linux provides powerful tools for recording events that hit your machine -- everything from login attempts, to people making unauthorised network connections.
A logfile is a text file containing a list of events, usually ordered by time, that some piece of software on your system has written. To make logging easier, UNIX-like systems use a daemon called syslogd, the system logger daemon. A program can open a connection to syslogd, send a message, then close the connection, and syslogd will work out which file to put the message in, what extra information to save (such as which program sent the message), whether it's urgent enough to echo on your system console. To say nothing of other capabilities: syslogd can write messages to other machines via the network, or dump them straight to a printer or out over a serial port.
On most (almost all) Linux systems, syslogd loads from the system-wide rc scripts when the system starts up. (You can find the startup script in /etc/rc.d/init.d/syslog on Red Hat, /sbin/rc.d/init.d/syslog on SuSE, and in /etc/init.d/sysklogd on Debian/Corel). It is usually accompanied by a daemon called klogd; while syslogd logs general messages from processes running on UNIX, klogd intercepts messages from the Linux kernel (a job that used to be part of syslogd on earlier UNIX-type systems but is now separated out to make it easier to keep an eye on the kernel). syslogd reads a configuration file -- almost always called /etc/syslogd.conf -- which defines a bunch of services, the logfiles their messages go to, and rules for controlling where messages with different priorities get sent. (When a process sends a message to syslogd, it tags it with a service -- mail, or lpr, or something -- to indicate what category it falls in, and with a priority -- notice, or error, or critical -- to indicate how important it is.) You can find the details in the man page for syslog.conf (type 'man 5 syslog.conf' in a terminal window to read this).
Why do you need to know all this?
Well, If someone is trying to hack into your system, the system log files are the first place you'll spot this. For example, the logfile /var/log/secure contains a log of connections from different machines (or TCP/IP addresses), along with the service they came in on. If you're running Red Hat, or another distribution that uses PAM (pluggable authentication modules) you'll see messages from the PAM system telling you who has started a session -- and more importantly, who's failed to authenticate themselves.
Most homes aren't burgled happen because some stranger comes knocking on the door and sees if they can unlock it (by trying every key on their keyring, at random). As with burglars, crackers use a variety of tools to get in. These may scan thousands of internet hosts simultaneously, looking for machines with old server software that contain known security flaws: the script kiddies can accumulate a list of hosts running, for example, an insecure version of BIND. Once they have a target, they can obtain a login on the system and install a 'root kit' -- a set of corrupted programs that mask their presence from you, the system administrator, and which they can use to gather passwords. A typical root kit replaces commands like 'ls' and 'ps' and 'top' so that they won't list some special programs the cracker has installed as daemons, and won't show the existence of a special directory containing the root kit tools. They can leave the root kit daemon running, and it will gather information about your activity -- possibly by monitoring passwords you send by logging into other machines -- and then email the treasure trove of passwords back to the cracker (via, for example, an anonymous HotMail account). They will also typically delete the evidence of their attack from the system logfiles, so you need to keep an eye open for gaps in the logs.
This is not so important to you if you run a dialup system and only connect to the net for a minute or two at a time -- when collecting mail and news, for example -- but as we spend more time online, the hazard becomes worse. With broadband connections via ADSL, cable modem, or leased line, the risk is huge: machines connected via broadband are on the net twenty four hours a day, seven days a week. The situation is only aggravated by negligent internet service providers who fail to take action against customers who run attacks from their accounts (for example, BTInternet, who recently notified a complainant that they would take no action against a cracker who was repeatedly probing their site, because all the complainant had to do was "spend less time on-line"!).
By adding a couple of daemons that look out for intruders to your system and by configuring your system logging carefully -- and by checking the logs regularly -- you can give yourself early warning that an attack is in progress. The first thing to download and install is Tripwire (free for use on Linux), a tool that monitors your important system files and regularly sends a report -- if any of them are modified, it'll tell you. Snort is a lightweight network monitoring and intrusion detection tool that can log via syslog and detect a variety of different types of attack. For added security if you're on a broadband connection, it's a very good idea to set up firewalling rules to ban incoming connections on all ports that you don't specifically want to let in, and copy the logging output from snort and tripwire to a different machine (preferably with no networking connectivity at all -- you can do it all via the serial port, and put that ancient 486 to good use as a logging box) so that if an intruder gets in, they can't pull the wool over your eyes.
Guilty as charged?
The Microsoft anti-trust lawsuit is a done deal; it's no longer a legal trial, but a political one. When Judge Jackson found Microsoft guilty of behaving as a predatory monopoly, nobody was very surprised: nor was the verdict -- break Microsoft in half -- unexpected. That Microsoft will appeal, and try to use all the political leverage that comes with being the USA's most valuable corporation, goes without saying. But the sting is in the tail: some interim measures will come into effect a month after the judgement, and remain in effect until the breakup (or until the verdict is overturned), that will make life very interesting for open source developers.
The DOJ and the State attorney generals filed a most interesting proposed final settlement at the end of April; given that Judge Jackson has found in their favour right down the line against Microsoft, it looks like this may set the pattern for the final verdict. (You can find the proposed settlement at The DOJ website; predictably, Microsoft spokespeople have gone into full spin mode denouncing this as unacceptably draconian and unneccessary.)
The proposed final settlement centres around the idea of splitting Microsoft into two divisions -- an applications house, and an operating system company. Internet Explorer would belong to the applications house, and the operating systems company wouldn't be allowed to develop or license it.
So far, so good; this is a rather conservative approach to the breakup solution. However, the interim measures make for fascinating reading. Pending an appeal or final breakup, Microsoft is banned from threatening OEMs with action that might restrict their ability to use or sell on products. Windows would have to be licensed on standard, published terms -- rather than by secret negotiated license deals that favour OEMs who do as they're told and punish those who don't. In particular, OEMs are allowed to do anything they want to modify the boot sequence and initial desktop of the Windows system including "launch automatically any non-Microsoft Middleware, Operating System or application, offer its own Internet access provider or other start-up sequence, or offer an option to make non-Microsoft Middleware the Default Middleware and to remove the means of End-User Access for Microsoft's Middleware Product."
On top of all this, Microsoft are required to disclose all their APIs, interfaces, and technical information, both to customers and to representatives of OEMs and independent software vendors. Such people have the right to study the Windows source code to enable their products to interoperate effectively with Windows.
Microsoft is banned from doing anything that interferes with the performance of non-Microsoft products when interoperating with Windows (guess that means they'll have to disclose their modified Kerberos specification!), and they're banned from threatening to withhold information or sales from people who compete on their turf. They're also banned from signing exclusive agreements (which freeze competitors out of a customer market). Most importantly, Microsoft are simply not allowed to render any "middleware product" (read: web browser, email client, multimedia application, or just about anything used for viewing internet content) incompatible with their platform by the Halloween Memo gambit of decommoditizing protocols.
If this isn't enough, there are draconian compliance requirements. Microsoft is to recruit a Compliance Officer who is to ensure that not so much as a post-it note that might be of interest to a competitor or judge is deleted -- much less mailboxes and office files. Just about anyone who can come up with a court order can "demand Microsoft provide copies of all books, ledgers, accounts, correspondence, memoranda, source code, and other records and documents in the possession or under the control of Microsoft (which may have counsel present), relating to the matters contained in this Final Judgment".
None of this has happened yet -- the judge hasn't decided to go with this solution, and there will inevitably be an appeal to the supreme court -- but it is highly suggestive of the way things may go. A Microsoft bound by these restrictions is no longer a major threat to Linux; they simply wouldn't be allowed to modify the open-source Kerberos authentication protocol in some secretive manner, effectively preventing Samba servers from providing primary name service within Windows workgroups -- as they did earlier this year with the release of Windows 2000. Nor would they be allowed to threaten OEMs who chose to ship a Linux partition on their PCs and allow users to choose their operating system of choice. In actual fact, splitting Microsoft into two companies is far less important than the compliance guidelines that come into effect before such a split. If the DOJ get their way, the threat of Microsoft rendering open source solutions incompatible with networks of mostly-Microsoft products will recede -- leaving the operating systems and applications to compete on merit rather than marketing.
A quick tour of KDE 2.0 Beta 1
It's been a long time coming, and it still isn't here quite yet -- final release isn't due until September -- but KDE 2.0 is finally in beta test, and available for download. Is it worth the wait?
We can get a sneak preview by installing KDE 2.0 beta 1, code-named Konfucious; hopefully this isn't the start of a series of atrocious puns. Konfucious isn't simply an incremental improvement over KDE 1.1.2; it bears about the same relationship to KDE 1.1 that Windows 95 bore to Windows 3.1. In every respect, it's a more ambitious, complex, and powerful system.
As this months deadline loomed, Konfucious hadn't shown up on the FTP servers, so I downloaded and installed its immediate predecessor -- KDE 1.90, the second alpha release. (In most respects except numbers of bugs, this is the same as Konfucious.)
KDE 2.0 is layered on top of release 2.1 of the Qt graphics toolkit, from Troll Tech of Norway. Unlike the earlier release of Qt (1.44) at the core of KDE 1.0, Qt 2 is released under an open-source compliant license with a commercial, supported version available on Windows. (It's worth noting that it was the lack of a true open source license that caused the establishment of the rival GNOME project.) On top of Qt, there's a KDE framework that provides a number of new facilities; a set of i/o libraries (KIO), a CORBA-based component object model (KParts), an XML-based GUI class, a new HTML rendering engine (used in the Konqueror filesystem browser/web browser/universal file viewer), and a Desktop Communication Protocol (DCOP) to allow applications to exchange data and request services.
I could go on at length about these libraries and services, which are pretty exciting at a technical level. However, unless you're planning on developing a KDE application of your own you're probably going to want to know what it means for you.
In use, KDE 2.0 looks a bit like KDE 1.x -- the user interface has been tarted up a little and makes use of Qt 2's theme support, but it's still recognizably KDE. You have to dig a little way before the differences come and whack you in the face. Never mind the high-colour icons and different menu fonts; fire up the KDE Control Centre and you'll see a plethora of new settings and controls for different subsystems. Dig into the menus, and it turns out that the Control Centre has now matured into a fairly general control panel for your workstation; it's still not up to doing all the system administration tasks you might need, but it's got a number of much needed features. (Want to share files with a Windows network? Check Browsing->Neighbourhood. Want to use Konqueror as your web browser and see sites that use JavaScript and Java? See Browsing->Web->Konqueror Browser. Yes, the KDE browser now understands Java ...)
Konqueror bears some explanation. KDE 1 used a combination file manager and web browser that wasn't particularly good at either task. Konqueror is a complete re-write, in the form of a modular browsing system that takes plug-ins. It can browse local files, or view the web -- pretty much like Microsoft Internet Explorer in Windows 98. The difference is that it's more flexible; click on a text file, for example, and instead of spawning an external program to view it, Konqueror opens it internally using the KWrite editor component. (Or you can right-click on the icon to obtain a list of applications to use on it, or choose your own -- Konqueror is flexible about such things.) Want to see what's in a spreadsheet or postscript file? Click on it. It's as simple as that. After KDE 1, Konqueror is a blessed relief. This is the first file manager I've run across on Linux that doesn't make me flee screaming back to the command line after thirty seconds. The Nautilus browser promises to provide the same sort of functionality for GNOME, but Konqueror -- in the here and now -- is likely to give Netscape Communicator 6.0 (aka Mozilla) a run for its money as the open source web browser of choice on the Linux desktop.
But that's not all. Most of the programs that come with KDE 2 have been componentised. This essentially means that they plug into each other. Want to insert a diagram in a document you're writing? If you're using the KOffice application KWord, you can just insert a diagram -- and you'll find that you're using the KIllustrator component to edit it. Instead of having a mini-drawing editor built into the monolithic word processor, you get to use the full-powered diagram application in whatever context you need it, from within the word processor. (And vice versa, if you want to embedd a paragraph or two of text in a diagram or presentation.) KOffice is part of KDE 2, and shows up under the K->Applications menu; select 'KOshell' to get started, and you can begin adding parts (actually objects you create using KOffice components) to your document using the available tools. KOffice follows a model first explored publicly by Apple with their unsuccessful CyberDog/OpenDoc system, only this time it actually works. An added bonus is that the Konqueror browser/file manager can use KOffice components to display KOffice files it runs across in a local directory or on the web. There are also plug-in viewers for Konqueror to display things like TeX DVI files, PostScript, and whatever else you need; in fact, Konqueror can use Netscape plugins to view things like RealAudio or Flash files.
KOffice is not in the same league as StarOffice or Microsoft Office -- but it looks like a worthy competitor for lightweight integrated suites like AppleWorks, which is all most people ever really need. More to the point, by using DCOP and the Python (and other) language bindings, you can script any of these applications. There's also a powerful integrated development environment, KDevelop, for writing new KDE applications in C++.
What's missing from KDE 2.0? It's a bit early to tell -- this is, after all, only an early beta release. There should be another four of them before KDE 2.0 is finally an official release. Some components don't seem to be present in 1.90, such as the KDEMultimedia applications; not so surprising, considering that the entire sound support system has been re-written from scratch and is now network-aware. Some necessities aren't ready yet, for example the ability for KOffice to read and write Microsoft Office document formats (regrettably a fact of life in today's software monoculture). Other applications which ought to be present in KDE 2.0 aren't here yet, either: notably Magellan, the killer groupware application (which knocks the existing KMail and KRn programs into a cocked hat). Finally, there are some missing programs that really ought to be there (and aren't); there's no KDE port of Vim or Emacs. These aren't end-user tools, but to us trend-setters who run dodgy beta releases they're a major disincentive to switch to the new environment for everyday use! (As a matter of principle I refuse to employ smileys in this column, but if it suits you please add one to the end of that last sentence.)
These drawbacks shouldn't put you off -- KDE 2.0 is a big improvement over KDE 1, which was already far ahead of the traditional UNIX graphical environments in 1998. It's just not ready for end users yet; it needs the polishing of a few months in beta testing. Linux used to be perceived as difficult to install; now it's easier to install than Windows. When it has matured a bit and been rolled into a release of, say, Corel Linux, KDE 2 is going to go a long way towards redressing the unfortunately widespread belief that UNIX is inherently not user friendly. In fact, Microsoft had better watch out. Newer releases of Windows are becoming so gnarly and full of exceptions and weird inconsistencies in the user interface -- mostly added in the name of customer demand -- that the clean interface, consistency, and component-based architecture of KDE may put the boot firmly on the other foot.
[ Site Index] [ Linux Index] [ Feedback ]