...making Linux just a little more fun!
By Cezary M Kruk
|
...making Linux just a little more fun! |
By Cezary M Kruk |
This article was translated from the Polish by the author. The original will be published in the summer issue of CHIP Special Linux.
Whenever a new version of your preferred distribution arises, you always have the same dilemma: to install everything from scratch or to try updating the system or to continue with something you are used to so far?
Let us take two extreme possibilities into consideration: installing and configuring the system from scratch lets you find out and use all its new properties, while staying with just what you have gives you the certainty that you could continue your projects without any obstacles. What you face is a standard opposition between innovation and stabilization.
The basic configuration of the system is not difficult. But the more you need to have, the more effort you must put into it. Is it possible to simplify the installation and the configuration of the system to do it easier? A complete and clearly designed base containing the information about the changes you have introduced working with previous versions of the system makes tuning of the new version much easier. This method is not much complicated when you collect data but it demands more work when you restore the configuration. How could you automate and simplify it?
Fortunately Linux stores the information about the configuration of each individual service in the text files. Moreover it gives you a bunch of very good tools for processing such files. So it should be enough to prepare the right scripts and to use them when you need to install the system once again.
This article describes two groups of the scripts: the first used for installing and removing individual packages, and the other one used for securing the system against the potential aggression. Both of them are designed for Slackware Linux. The tools for installing and removing packages are not as sophisticated as the programs from SlackPkg or Packware packages are, but they offer you the full control over the system instead. The same is true about the scripts for securing the system. They perform only elementary operations. Both sets of the tools we collected in the slack*more bunch.
Having it as a pattern you can prepare other tools for automating the process of the configuration of any services or programs. If you decide not to tune the system manually at all but to supplement the appropriate script with the consecutive procedure instead you will soon gain your own kit of programs for configuring the system. Moreover, because you will prepare these scripts by yourself, they will perfectly meet your needs.
We have discussed it using as an example Slackware Linux because that distribution in a natural way makes users interfere with the configuration files directly. Other Linuces, offering complex programs for those aims, separate users from the files containing the information about the configuration. Thus the programs either make them lazy or force them to make sophisticated investigations to establish what and where was actually changed in their system by so-called friendly programs.
Slack*more is divided into two parts. INSTALL.tgz archive contains the tools for installing, removing or upgrading programs, and SECURE.tgz archive -- the tools for the preliminary securing of the system.
Figure 1. Thanks to SCRIPT.sh script from ./Slackware-9.0 directory you will generate a bunch of clear lists of packages from the individual groups. The figure shows the list of the packages from the d group (development)
The most important components of INSTALL.tgz package are INSTALL.sh script and ./Slackware-9.0 directory, containing SCRIPT.sh script and Slackware file.
To initialize those tools, you need to mount in /mnt/cdrom directory the installation version of Slackware, and then to run SCRIPT.sh from ./Slackware-9.0 directory. The script will look through the directories on the CD-ROM, and, guided by the tagfiles placed there, it will create the files containing information about the packages (Figure 1.). Each file will have the name corresponding to the name of the given group. For example: in the e file, registering the packages building Emacs, you will find among other things the following entries:
emacs: ADD emacs-misc: REC emacs-nox: OPT
The users who know Slackware Linux know that ADD category points out the packages essential to use in the given program, REC category means the recommended packages, and OPT category means the optional ones.
If you have such basic information about the packages, you can decide which components you want and which ones are useless for you. So if you modify the content of the above-mentioned e file in the following way:
emacs: ADD #emacs-misc: REC !emacs-nox: OPT
the emacs package will be expected to be installed, the emacs-misc package will be ignored, and the emacs-nox package will be not only ignored, but also -- if it was previously installed in the system -- will be removed.
In Slackware file from ./Slackware-9.0 directory there is some information about the individual groups of the packages:
a ap d e f ...
Basing on it the script will decide which groups of the packages should be taken into consideration. If you customize that file in the following manner:
a ap #d !e f ...
the d group will be ignored, and each package from the e group installed previously in the system, will be removed.
Thus: if you precede the name of the package or the name of the group by # , they will be omitted, and if you precede those names by ! , the corresponding components will be removed from the system. If a package or a group of packages have not been installed yet, the meaning of # and ! signs is equivalent. The entries from the files containing the names of the groups have priority over the entries in the files containing the names of the packages. So if you decide to ignore the whole group or to remove the packages belonging to it, the script will do it regardless of the information written down in the files collecting the names of the individual packages.
When you have prepared Slackware file and the files containing the information about the individual packages, you may run INSTALL.sh script. The script will add or remove the corresponding components from the system. If it is a preliminary installation of Slackware, and the system has not been tuned adequately yet, it is a good idea to optimize the work of the hard drive used as a platform for the new distribution. You can use for it one of -- INSTALL.hda or INSTALL.hdb scripts. Thanks to it the process of installing or removing the packages will be faster.
INSTALL.sh is designed for multiple usage. If there is nothing to do, it will do nothing. Using that script you can also perform the basic installation of Slackware. It is enough to install the packages from the a group first using Slackware's setup program, and next to put the script into the system, to comment the names of the packages or groups you do not need, and to install the rest, calling INSTALL.sh.
In ./Packages directory there is another SCRIPT.sh script. If you mount Slackware CD-ROM, and run the mentioned script, it will create the structure of the directories containing the files with information about individual packages of the system. Such reference data base about the packages is convenient because you do not have to mount the installation disc each time you want to check what the selected package is for. Building a base like that is reasonable only if you have not decided to install the entire Slackware Linux. Otherwise you will find the information about all its packages in /var/log/packages directory.
./Patches directory contains two scripts. If you want to use them, run 0.check first. It will check the sunsite.icm.edu.pl server looking for the available updating for Slackware 9.0 and will create the Packages.html file with the information about the updates and the Packages.txt file with the names of the packages:
mutt-1.4.1i-i386-1 sendmail-8.12.9-i386-1 sendmail-cf-8.12.9-noarch-1
1.get script will use the last file to get the packages, the appropriate .txt files, and the .tgz.asc files. In order to do it this script uses the command wget -c -t0 so there is no risk you will get the same files repeatedly. On the other hand checking if the given file is already got takes some time so it could be favorable to look through the Packages.txt file before you start 1.get, and to remove from it the names of the packages you already got or you do not care of. But this is not necessary.
You can change the command for getting of the files for wget -c -t0 -b . Then all the files will be got from the server at the same time -- in the background. But not every server allows you to establish such simultaneous connections. If the sunsite.icm.edu.pl server does not suit your needs, you can register in the 0.check and in 1.get scripts another host. Then you should customize the content of the command adequately generating the Packages.txt file from the Packages.html file. Originally it is the command:
cat Packages.html | grep ".tgz.asc" | sed 's/.tgz.asc//g' | sed \ 's/.*A HREF="//' | sed 's/">.*//' > Packages.txt
1.get script registers the information about casual packages only. The huge bunches of the updates for Slackware are put into separate directories (kde, kdei, etc.). If you want to get them, you will have to do it manually or to modify the original script suitably.
In ./usr/local/bin directory there is catpkg script which makes reviewing the files available in /var/log/packages directory for the information about all the packages installed in the system easier. INSTALL.sh copies the entire contents of the local ./usr/local/bin to its systemwide equivalent. So you can put here different scripts you want to use during the initial work with the system.
Figure 2. SECURE.sh script takes SUID and SGID bits away from the selected files and displays the information about it
The main script in SECURE.tgz archive is SECURE.sh. It performs the following tasks:
Sets in /etc/login.defs file the PASS_MAX_DAYS variable for 182. Thanks to it the validation time of the passwords of the new users will be limited to six months.
Sets in /etc/profile file the HISTFILESIZE variable for 100. Thanks to it the file of the commands history will be limited to one hundred lines.
Sets in the /root/.bashrc file the TMOUT variable for 900. Thanks to it the non active session of the root will be killed after fifteen minutes.
Comments in /etc/inetd.conf file all non commented, but potentially dangerous network services.
Puts in /etc/hosts.deny file the ALL: ALL@ALL entry, for blocking all exterior access to the machine.
Puts in /etc/hosts.allow file the ALL: [email protected] : ALLOW entry, giving access to the resources of the local machine.
Changes in /etc/host.conf file the order hosts, bind sequence into the more secure order bind, hosts and adds the nospoof on sequence.
Blocks in /etc/securetty file the access for the root to all consoles except /dev/tty1.
Removes from /etc/group file the news and uucp groups superfluous in most cases. It is equivalent to give groupdel news and groupdel uucp commands.
Removes from /etc/passwd file news, uucp, operator, sync, and shutdown users. It is equivalent to the sequence of consecutive userdel commands taking the appropriate parameters.
Performs the parallel actions with reference to /etc/shadow file.
Sets in /etc/inittab file the comment sign at the line starting from ca::ctrlaltdel:/sbin/shutdown . Thanks to it the Ctrl-Alt-Delete shortcut stops to cause the reboot of the machine.
Takes away from all the scripts from /etc/rc.d directory the rights for reading or executing them by the group or by other users.
Adds to /etc/rc.d/rc.local file a few commands turning off or on different services. To make these commands work you should add to the kernel the IP: TCP syncookie support module.
Tests a few dozen of trouble programs and takes the SUID bit away from them. It stores the information about those modifications in the log file (Figure 2.).
Does the similar action with reference to a dozen or so of the programs, taking SUID and SGID bits away from them.
Puts in /etc/mail/sendmail.cf config file the entries O PrivacyOptions=noexpn and O PrivacyOptions=novrfy . It prevents the system from remote checking of the accounts.
Copies to /etc/cron.daily directory the remove script. It is used for automatic removing different temporary directories and files from the system.
Copies to /root/bin directory a few useful scripts.
Those actions increase the security of the system significantly, though it is just a beginning of the sealing it against the possible crack. SECURE.sh script was written in a way that it can be run repeatedly. So you can add any procedures to the script and to apply them without any problems.
The script modifies different services, but does not overload them. To reread /etc/inetd.conf, use killall -HUP inetd command. To execute the changed /etc/inittab, run init q command. To restart the sendmail use /etc/rc.d/rc.sendmail restart or kill -HUP `head -1 /var/run/sendmail.pid` command.
You may include those commands in the script, but it involves a potential risk you should take into consideration. If you make a small error in the call of the sed program, instead of the modified /etc/inittab file you can stay with an empty file. As a result after rebooting of the init you will lose the access to the system, and you will be forced to restore /etc/inittab from the copy, using Linux system installed on the other partition or disc. It is not always pleasant, particularly if you do not have another partition with Linux.
Figure 3. The list of the files of the huge size. As you can see, the prominent places are taken there by the files of the OpenOffice.org suite installed in /opt directory, as well as the RealPlayer and the Pingus files
TEST-SECURE.sh script seeks the system for some kinds of files:
The files having set SUID or SGID bits.
The huge and old files (the files over 1 MB, modified or used for the last time three months ago or before).
Exclusively the huge files (Figure 3.).
The files without any association to the user or group existing in the system.
The information about each category of the files is registered in the separate log file. Moreover TEST-SECURE.sh uses the results of the work of SECURE.sh script, showing the content of the log file with information about programs without SUID or SGID bits.
Because not always you will want to perform all these tests together, in /root/bin directory you will find 1.suid, 2.huge+old, 3.huge, and 4.nobody scripts-each of them does one particular test only.
It is worth extending SECURE.sh script with other procedures which will be responsible for configuration and installation of the further protections. Following the procedures used in the script you will be able to draw up the next scripts for tuning other services: configuring the accounts of the users, setting the network, e-mail and WWW services and clients, X Window environment, etc. The only limitation is your imagination because in that way Linux allows you to manage almost everything. So when you finish creating those scripts you will be able to configure the entire system exactly to your needs, just pressing the Enter key a few times.
Slack*more:
freshmeat.net/projects/slackmore
SlackPkg:
freshmeat.net/projects/slackpkg
Packware (Polish site):