Documentation: secure-slinux-server-v0.3.0dev-i586-bin.tar.bz2
AUTHOR: Sebastian Faulborn
DATE: 2006/07/07
UPDATE: 2006/07/14 Several additions to the documentation. Fixed the missing helper scripts in /usr/bin.
UPDATE: 2006/08/04 Added note in postfix about setting root alias/adding user postfix_nobody/using postmap
ALL PACKAGES: a list of all packages installed with Secure-SLinux can be found here
LICENSE: GPL (see the license of the individual packages)
SYNOPSIS: Installation of binary archive of Secure-SLinux Server (SSLX-Server)
CONTENTS:
...
Requirements:
To run SSLX-Server you need at least:
For specific purposes such as embedded systems, you can tailor SSLX-Server so that it will consume a lot less ROM/RAM/harddisk space (down to a few MB).
Download:
Download the most recent SSLX-Server binary archive from here.
Documentation:
The core of Secure-SLinux is based on HLFS (glibc branch). Some additional packages are installed according to the instructions in BLFS and further packages are installed according to the package developer's instructions. Both HLFS and BLFS are subprojects of Linux From Scratch. The Linux From Scratch Project provides excellent documentation. Most of Secure-SLinux's configuration must be done as described in the HLFS book. So please have a look there since this documentation will only cover differences to HLFS.
Other places to look for documentation:
Quick Installation:
/etc/sysconfig/console
/etc/hosts
/etc/sysconfig/network-devices/ifconfig.eth0/ipv4
/etc/sysconfig/network
/etc/fstab
/boot/grub/menu.lst
/etc/sysconfig/clock
Installation:
This documentation assumes that you will be installing SSLX-Server on a harddisk of its own using the SSLX-CD live-cd. It is possible to use other linux live-cds. However some linux distros patch their filesystem commands such that extra features become available. If you create partitions/filesystem from within such distros, Secure-SLinux may not be able to boot. Also the SSLX-CD can be ejected while it is running which allows you to copy data from a second cd to the harddisk.
Creating partitions
Also have a look at "HLFS/Chapter03/Creating a New Partition".
Secure-SLinux boots with an initrd which should automatically detect your IDE/SCSI hardware. If the SSLX-CD did not detect your hardware, load your driver with insmode/modprobe.
For simplicity, we will assume in this documentation that you will install Secure-SLinux on a IDE harddisk (/dev/hdX). If you will install on a SCSI harddisk, your device will be /dev/sdX or even something totally different (eg. raid controller).
Secure-SLinux needs at least two partitions to run: swap and root.
swap partition
The swap partition needs to be greater than 512MB since Secure-SLinux by default mounts /tmp on a 512MB tmpfs filesystem. Since tmpfs lives on swap, we need more than that size. 1GB will be plenty for all applications.
There used to be a rather small limit for swap partitions so that people used to create lots of swap partitions in order to get the required ammount of swap. This limit does not exist anymore - so you only need on swap partition. If you use raid1 or some other raid to protect against harddisk failure, make sure that swap lives on your raid array. Otherwise your server will hang when a harddisk fails.
If you want to use a smaller swap partition, adjust the size if /tmp in /etc/fstab.
root partition (/)
Secure-SLinux will be about 950MB in size. So 1GB will be fine, but won't allow you to install much additional software or keep large amounts of data. If your root partition should ever become to small in size, you will spend a lot if time fixing this problem. Modern harddisks come with at least 36GB, so we recommend that you are a bit more generous with your root partition - 10GB will make sure you don't run into problems.
boot partition (/boot)
There seems to be a competition between motherboards and harddisks. The size of modern harddisks increases faster than the BIOS can support. The current limit for most BIOS's is 137GB or above. If your harddisk is larger in size than the BIOS's limit, you will only be able to access the lower part of your harddisk during the boot process. Secure-SLinux can access any sized harddisk once it is up and running. So the restriction only applies for the location of the bootloader and the kernel (ie. /boot/...).
The simplest solution is to always make sure that the /boot partition is the first primary partition starting at the beginning of the harddisk. If you don't want a seperate /boot partition, make sure that your root partition is located on the first primary partition starting at the beginning of the harddisk and that it does not exceed the BIOS's limit on harddisk sizes.
The advantages of a seperate boot partition: you have everything needed for booting on a seperate partition which helps in case of recovery and you can format it with a different filesystem than your root partition making it compatible with any recovery floppy/cd/dvd. You can make sure that this partition is located at the beginning of the harddisk which removes the restrictions on all the remaining partitions. Also /boot is used read-only (although its mounted rw, but linux itself does not write to /boot). This means if somethings hangs and you need to turn off your server while it is running, /boot will still be in a clean state since no writes are done to this partition.
100MB will be plenty for any purposes.
other partitions
Traditionally people used to create lots of extra partitions, such as /usr, /usr/local, /opt, /home, etc. The main reason originally was that harddisks were so small that the OS would not fit on a single harddisk. This is also one reason why linux comes with such a complex directory structure. Nowadays harddisk are much larger than even the biggest OS, so the only practical reasons for partitioning your harddisk are a) to choose among different filesystems for different purposes b) mount different directories with different (restrictive) options for security reasons c) seperate those partitions which contain variable content from the rest to make sure that if an application floods the harddisk, the other partitions are not affected and to OS keeps running.
Recommendations for Secure-SLinux:
Note: the more partitions you have the more difficult it becomes estimating in advance the required size for each partition.
The recommended layout for almost any server usage:
Start fdisk or cdfisk to create the partitions. All partitions should be of type 83 (linux) except for swap which has type 82 (linux swap). For software raids use type fd (Linux raid autodetect).
Formating partitions
Secure-SLinux recommends two filesystems: ext3 and reiserfs.
ext3
Ext3 is based on ext2. It has been on the market for ages. It is stable and fast. It is a journalling filesystem.
reiserfs
Is stable. Claims to be somewhat faster in certain situations than ext3. It is a journalling filesystem.
We recommend that you use ext3 for /boot or if you use a single root partition since ext3 can be accessed by any rescue floppy/cdrom and even by most other operating systems. This makes recovery easier. Reiserfs is recommended for database applications.
So the recommended layout is as follows:
Create swap: mkswap /dev/[swap partition]
Create ext3: mkfs.ext3 /dev/[partition]
Create reiserfs: mkfs.reiserfs /dev/[partition]
Mounting partitions
Create a mount point for Secure-Slinux: mkdir /mnt/sslx
mount root: mount /dev/[root partition] /mnt/sslx
mount /boot: mkdir /mnt/sslx/boot && mount /dev/[boot partition] /mnt/sslx/boot
mount other partitions: mkdir /mnt/sslx/[mount point] && mount /dev/[partition] /mnt/sslx/[mount point]
Copying the binary archive to /mnt/sslx
There are several ways how you can get the binary archive onto your harddisk:
Check the md5 sum of the archive: md5sum /mnt/sslx/[archive]
Installing Secure-SLinux
... is a matter of unpacking the binary archive.
Note: Because of a small bug in the source compilation scripts, some helper scripts are missing. To get those scripts, copy them from here to /usr/bin and "sslx-create_initrd*" also to /usr/src/kernel/sslx/scripts/!
Configuration:
Configuring the setclock Script
If your hardware clock in the BIOS is set to UTC set UTC=1 in /etc/sysconfig/clock - otherwise leave it:
cat > /etc/sysconfig/clock << "EOF" # Begin /etc/sysconfig/clock UTC=1 # End /etc/sysconfig/clock EOF
It doesn't matter wether you set the hardware clock to UTC or localtime. If you also use your computer together with other operating systems then you must use whatever the other OSes are using as their clock settings. For example Windows uses localtime.
If unsure leave it as it is.
Note: Secure-SLinux runs by default once per day NTP which sets the time according to time servers on the internet. When you shutdown Secure-SLinux, the hardware clock will be updated to the current system time.
Configuring the Linux Console
Edit "/etc/sysconfig/console" to set the font and keyboard. The defaults are set for Germany.
Setting the locale
Secure-SLinux sets the locale to "en_US". This setting is guaranteed to work with all software.
Most distros tell you to set the locale to your language/country. However the locale system is nowadays used by just very few utilities to display help messages in your language and format the date or currencies correctly. Most modern applications such as databases, web-servers, editors or OpenOffice will handle locales in their own ways since they fullfill a much more complex task which cannot be handled with linux's locale system. For example databases have to be able to handle all languages at the same time. You might edit a XML file in UTF-8 in one window and a HTML file in ISO-8859-1 in another window. Your letter might be written in German and contains a quote in French!
If you are happy reading man pages in English, we recommend you leave the settings as is. It make sure that all applications run without problems. If you choose to set the locale to something different (possibly because your language needs something different than ISO-8859-1 character encoding), note:
Configuring the localnet Script
We assume here, that your server is called "myserver" and your domain is "my-company.com". The fully qualified name of your server will then be "myserver.my-company.com".
Set the hostname of your server by editing "/etc/sysconfig/network" (eg. myserver).
Configuring the /etc/hosts File
Edit "/etc/hosts" to setup some basic name resolution.
Add a line representing your server. If the ip is "192.168.1.27" add:
192.168.1.27 myserver.my-company.com myserver
Configuring the network Script
edit "/etc/sysconfig/network-devices/ifconfig.eth0/ipv4" to set the IP, Gateway and PREFIX of your first network card. You also need to set ONBOOT to "yes" (note: case sensitive).
Have a look at "HLFS/Chapter 07/Configuring the network Script". There are also other services available, such as "ipv4-static" and "ipv4-static-route". The latter allows you to setup routing tables.
If you want to setup more than one interface, create directories like "/etc/sysconfig/network-devices/ifconfig.eth1" etc. with corresponding contents.
If you want to setup more than one ip per interface, create directories like "/etc/sysconfig/network-devices/ifconfig.eth0", "/etc/.../ifconfig.eth0:0", "/etc/.../ifconfig.eth0:1", etc. with corresponding contents.
Configuring name resolution
Usually there is no need to edit "/etc/resolv.conf" since Secure-SLinux comes with its own name server (dnscache). If you have a localnet with several servers it is recommended that you install tinydns or some alternative on one of the servers and configure dnscache on each server to use the tinydns server as its source. See the documentation at djbs dnscache homepage.
The advantage of dnscache over other solutions is:
Configuring the /etc/fstab
Edit "/etc/fstab" to reflect your partitions.
Making the HLFS System Bootable
Edit "/boot/grub/menu.lst" to create the desired boot menu on startup.
Also read "HLFS/Chapter 07/Making the HLFS System Bootable".
Secure-SLinux comes with a variaty of precompiled kernels:
The kernel images in /boot will be prepended by "linux-", the corresponding System.map files with "System.map-" and the corresponding ".config" files with "config-".
A typical entry in menu.lst looks as follows:
title Secure-SLinux V0.3.0dev root (hd1,0) kernel /boot/linux-2.6.14.6-grsec-sslx-single root=/dev/ram0 ramdisk_size=50000 vga=0x31B sslx_root=/dev/md2 initrd /boot/initrd.gz
| 640x480 800x600 1024x768 1280x1024
----+-------------------------------------
256 | 0x301 0x303 0x305 0x307
32k | 0x310 0x313 0x316 0x319
64k | 0x311 0x314 0x317 0x31A
16M | 0x312 0x315 0x318 0x31B
Install the bootloader in the MBR:
Note: "root" in this context means the partition which contains /boot/grub/*
Note: there is no need to setup grub again when you change menu.lst (as you would for lilo).
Boot into Secure-SLinux installation
After booting into the new Secure-SLinux installation:
Recreate the sshd keys, recreate keys for samhain, set root password:
Enter: sslx-first_boot
Note:
Congratulations! You have successfully installed Secure-SLinux on your server!
Adding users and security:
If you were trying to login to Secure-SLinux from the outside right now, you would not be able to succeed - whatever you do! You need to understand how Secure-SLinux handles users before you can login via sshd.
Sshd and security
Sshd cannot drop privileges since it needs to be able become any user during the login process. To make the process as secure as possible, Secure-SLinux uses all available means of protecting you from unwanted intruders.
Please also read the documentation at www.openssh.com
OpenSSH handles connections as follows:
There is a single privileged sshd process which accepts all ssh connections. Basically its job is the same as that of xinetd. If you would run sshd from xinetd, sshd would have to generate the server key every time which would make logins rather slow - so using sshd for receiving connections for itself is a lot faster. The server key will be regenerated once every hour.
When you connect to Secure-SLinux, this first process spawns off a second privileged process which does all the handling of the connection and the login. Finally a third process is spawned which runs under the same user which you used for loging in.
When ever possible, processes are run chrooted within an empty directory (/var/empty). Since GRSecurity enforces chroots, it will be impossible to break out of this empty directory.
Since the third process runs under the user which you used for loging in, and since it is not possible to run this process inside a chroot environment, there is a security problem should there be a bug in OpenSSH. So its a lot safer to only login as an unprivileged user and change later using "su" to whatever else you want so that this unprotected process never runs as root. For this reason, root logins are disallowed by default.
Other reasons for disallowing root logins are:
Sshd and authentification
There are two recommended ways to authorize when you login.
Sshd and tcpwrapper
Tcpwrapper restricts connections from the outside according to the files "/etc/hosts.allow" and "/etc/hosts.deny".
By default Secure-SLinux is setup to allow all connections to ssh. This is not insecure since ssh is by its very nature very hard to break into. However for highest security, limit connections to specific IPs (eg. your company). If you do not have a static IP (such as when working from home) you can still limit connections to your provider. Eg. all connections from your provider have the domain name "[something].myprovider.net" (login und have a look at "who" to find out) then put into "/etc/hosts.allow": "sshd: 127.0.0.1,.myprovider.net". This increases security a lot since a hacker won't know why he is not allowed to make connections and hackers usually don't attack your servers from dynamic connections via some provider since those connections are too easily traced back to their origins.
Creating users
Basically to log into Secure-SLinux you have to create an unprivileged user.
Some mainstream linux distros have wrapped useradd with a script which automatically creates groups and directories. Secure-SLinux comes with the original useradd program. It is configured to automatically create users with the default shell "/sbin/nologin" - which disables logins for such users (you can configure this behaviour in "/etc/default/useradd"). The reason is that most users on most servers are used to allow the daemons to run in unprivileged mode. Also Secure-SLinux follows the policy: everything is disallowed until it is specifically allowed.
If you want to create a user (under the default group "users") which you can use for login enter:
The -m option creates a home directory "/home/[newuser]" and copies all files in "/etc/skel" to this new directory.
To set a password enter: passwd [newuser]
Allowing su
There are certain commands on linux which are installed suid root. This is potentially dangerous. For this reason all such commands have the suid permission removed apart from those commands contained in "/usr/suid-bin".
This means that some commands will only as root have all their functionallity available (eg. traceroute, nmap). All other commands belong to the group "admin" apart from "su" which belongs to "suers". Only "ping" and "passwd" are accessible by all users. This means that if you need to use those commands listed in "suid-bin", you will have to add the groups "admin" or "suers" to your user.
To create a user which allows you to change to root, enter:
This user can now change to root or any other user with "su - [user]"
To create a user which allows you to change to root and which can access all admin suid root commands, enter:
Cronjobs:
Secure-SLinux has fcron installed which replaces vixie cron and the at daemon. With fcron you can run programs delayed, once after boot, repeatedly, only when the load is low, etc. Have a look at fcron.free.fr. Basically fcron should be 100% compatible with vixie cron's syntax. Instead of using "crontab" simply use "fcrontab" to edit your configuration. You can also drop scripts into the directories "/etc/fcron.d/{hourly,daily,weekly,monthly}" to run them at the apropriate intervalls. By default Secure-SLinux has certain cronjobs installed under the fcron user "root" and "systab".
Firewall:
Secure-SLinux starts the iptables packet filter capability of the linux kernel during the boot process. By default you can open any connection from the inside to the outside but no connections are allowed from the outside to the inside except for established connections and sshd.
Due to the very powerfull capabilities of linux's packet filter, only a few rules are necessary to achieve this - even for such complex rules such as ftp connections. The default rules are pretty safe for most purposes, however if you want to use your linux box as a firewall between the internet and your intranet or as a gateway etc. you may want to use more limiting rules (such as disabling sshd totally and only allow login from the console).
When you start the firewall, the script "/etc/sysconfig/firewall.base" is called which sets up the firewall such that no connections are allowed from the outside and all connections are allowed from the inside. This script calls "/etc/sysconfig/firewall.conf" which can be used to open up the firewall. By default it only opens up the firewall for connections to sshd.
TCP_Wrapper:
Secure-SLinux has TCP_Wrapper support. Sshd is compiled with it. The advantage of TCP_Wrapper over iptables is that iptables can only handle rules based on ip while TCP_Wrapper also supports rules based on DNS names and more importantly partial names.
EMails:
If you need to setup a full email server, we recommend qmail by djb. QMail is used by some of the largest email providers. There is an excellent documentation at www.lifewithqmail.org.
QMail is fast and extremely robust. Its installation is a bit lengthy but simple. Once installed administration is much simpler than most other mta's. You will need a few patches to make qmail work with the newest email standards, overly long DNS answers and to be able to use anti virus checkers (all explained in the documentation).
Secure-SLinux comes with postfix. Its already setup for relaying emails via your provider. Please read the postfix documentation here.
To setup postfix as an email relay:
cat > /etc/postfix/sasl_passwd <<"EOF" mail.myprovider.com user:password EOF
groupadd postfix_nobody
useradd -g postfix_nobody postfix_nobody
When you boot the next time into Secure-SLinux, postfix will automatically be started.
You can ignore the error messages during startup of postfix about wrong owner of files.
If you want to configure postfix as a email system, see the postfix documentation.
Samhain:
Samhain is a file integrity checker and intrusion detection system. Please read the documentation here.
When you boot the next time into Secure-SLinux, samhain will automatically be started.
GRSecurity:
GRSecurity is one of the measurements used to harden Secure-SLinux. It will kill applications if they do something which they are not permitted to do. You can configure GRSecurity via options in the kernel (make menuconfig -> security) and there are some sysctl options (sysctl -a shows you a list of available options) which you can change.
Basically grsecurity should not normally kill a perfectly sane application. It greatly enhances security especially by strengthening the chroot restrictions. On normal linux systems, it is still possible to break out of a chroot jail (by using /proc or some device nodes or the chroot() function). GRSecurity will disallow anything dangerous within a chroot jail. So setting up chroot jails for problematic services (eg. web servers or email) is definitively a goot idea.
PAX:
Pax is now part of GRSecurity. Its homepage is pax.grsecurity.net.
Pax kills an application if it accesses the memory in a way which it is not allowed to (eg. if an application tries to execute code in memory allocated for data or the stack). If an application gets killed unexpectedly then it has probably been killed by pax (in rare circumstances by glibc - eg. memory management). You will see a message in /var/log/syslog which makes clear that pax killed that application and why.
By default all pax options are enabled. You can disable certain features on a per binary base with paxctl/chpax or in general with some sysctl options or in the kernel itself (make menuconfig -> security).
Use "paxctl -v [full path to binary]" to see the current settings. On binaries which have not been compiled with pax enabled kernels or on old systems, you will see no output of paxctl. In those cases use chpax with the same syntax - it operates on the older headers of those binaries. Note that if a binary uses libraries or calles other binaries you will always have to change the pax flags of the first binary started (unless the binaries started create completely new processes). So if the plugins in your firefox browser don't start, you will have to change the pax settings of the firefox binary and not those of the plugins (however not on the firefox script!).
In very rare circumstances, an application tries to execute code on the stack (eg. some browser plugins). To allow such applications to run, use "execstack" to change the binary's headers accordingly (if paxctl -m does not help - see its man page for details).
This error occurs since Secure-SLinux has "Disallow ELF text relocations" enabled in the kernel and you want to use binaries/libraries which contain text relocations. Secure-SLinux makes sure that all binaries/libraries are compiled PIC/PIE which means they are relocateable. However some software which you install may contain text relocations (often assembly). Try to compile from sources. Secure-SLinux will try to compile as PIC/PIE. If that does not help recompile with all assembly disabled. If thats not possible try "paxctl -m/chpax -m". If that does not help either you will have to disable that feature in the kernel. This does decrease security a lot since most attacks need to know where certain functions are located and pax cannot randomly move binaries/libraries in the address space.
SSP and PIC/PIE:
Secure-SLinux compiles every software with SSP and PIC/PIE enabled. SSP (see the introduction to HLFS) kills an application if the stack has been changed illegally by a function. This applies especially to pointers (return address) and variables stored on the stack. Basically the pointers are placed at the beginning and variables at the end. A random number is placed at the end of the stack. If there is a buffer overflow in a function, this random number will change and the application is killed. In this simple way, your computer is protected from one of the single most common ways of attack.
PIC/PIE (see the introduction to HLFS) compiles a program/library in such a way that its code can be moved to any location when it is executed. Pax will move the program to a random address when it is started so that a hacker does not know where a specific function is located. This is one of the most important informations a hacker needs when he wants to attack your computer by using eg. a buffer overflow to break into your machine.
Only if you compile software from source will those features be enabled (or use the binaries specifically compiled for Secure-SLinux). So compiling from source can improve security a lot compared to binary installs.
In very rare cases, your program might not work when compiled with SSP or PIC/PIE. You can turn of gcc's hardened specs by executing "sslx-gcc-hardenedspecs stop" before you compile your software. Don't forget to use "sslx-gcc-hardenedspecs start" when you are finished to make sure that future compilations will use the hardened specs again.
Compiling the kernel:
The directory /usr/src/kernel/sslx contains everything which has to do with compiling the kernel. It is recommended that you leave this directory as is since it contains the state of precompiled kernel images as provided by Secure-SLinux.
/usr/src/kernel/sslx/:
compiling the kernel
Note:
Creating the initrd.gz
Note:
Compiling in general:
By default, gcc uses the hardened specs. Use "sslx-gcc-hardened-specs start|stop" to turn this feature on or off. If enabled, gcc will compile everything with SSP and PIC.
Most software packages use "uname" to find out for which architecture they are supposed to compile the software for. Secure-SLinux allows you to configure uname by editing /etc/sslx-uname.conf. Basically this allows you to cross compile a package for another architecture. Note that you can only compile software for architectures which are compatible with your processor (eg. i686 can compile for i586 but i486 cannot compile for i686).
You can specify the architecture (i486/i586/i686) and the processor type. If the architecture is set to "*" then the real architecture/processor are used and uname behaves as normal. Other settings replace the real architecure/processor. If you set processor to "unknown" and architecture to "i586" your binaries will run on any current machine (this is the default for Secure-SLinux). Use "uname.orig -a" to find out your machines real architecure and processor.
Note: A few packages don't use uname to check the architecure (eg, perl and openssl).
Helper applications:
