Documentation: secure-slinux-server-v0.2.0dev-i586-bin
AUTHOR: Sebastian Faulborn
DATE: 2006/03/22
UPDATE: 2006/04/26 - make clearer that "xargs -I abc" uses a capital "i"
LICENSE: GPL (the software packages contained each have their own GPLish license)
SYNOPSIS: Installation of binary archive of Secure-SLinux Server (SSLX-Server)
CONTENTS:
Requirements
Download
Documentation
Quick Installation
Installation
Creating partitions
Formating partitions
Mounting partitions
Copying the binary archive to /mnt/sslx
Installing Secure-SLinux
Configuration
Configuring the root password
Configuring the setclock Script
Configuring the Linux Console
Configuring the localnet Script
Configuring the /etc/hosts File
Configuring the network Script
Configuring name resolution
Configuring the /etc/fstab
Making the HLFS System Bootable
Boot into Secure-SLinux installation
Recreate the sshd keys
Requirements:
To run SSLX-Server out of the box:
For specific purposes such as embedded systems, you can tailor SSLX-Server so that it will consume only a few MB of RAM and persistant storage space.
Download:
Download the most recent SSLX-Server binary archive from here.
Documentation:
The core of Secure-SLinux is based on HLFS (the glibc branch). Some additional packages are installed according to the instructions in BLFS and further packages are installed according to the packages 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 also have a look there since this documentation will only cover differences to HLFS.
Places to look for documentation:
Quick Installation:
For those who know what they are doing
/etc/rc.d/init.d/mountkernfs start
/etc/rc.d/init.d/udev start
/etc/sysconfig/console
/etc/hosts
/etc/sysconfig/network-devices/ifconfig.eth0/ipv4
/etc/fstab
/boot/grub/menu.lst
possibly also /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".
This documentation assumes that you will install Secure-SLinux on a IDE harddisk (ie. /dev/hdX). If you want to install Secure-SLinux on a SCSI harddisk, the device's name will be /dev/sdX. Secure-SLinux should automatically have found your SCSI hardware. If it was not discovered, load the driver as a module from cd with insmod or modprobe. Note that Secure-Slinux has SCSI drivers compiled as modules. The reason is that some SCSI drivers hang when they started on the wrong hardware. So it is not a good idea to simply activate all SCSI drivers in the kernel. This means that Secure-SLinux won't boot from a SCSI harddisk since the root partition must lie an a harddisk which can be accessed with a driver which was compiled into the kernel. So you will have to recompile the kernel at the end of the installation and activate your SCSI drivers so that it gets build into the kernel. If your SCSI driver only exists as a kernel module you will have to create an initrd to boot linux successfully. There is a hint in the hints section of Linux From Scratch.
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.
root partition (/)
Secure-SLinux will be about 850MB 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 layout:
/data can be used to hold your projects including their software downloads and binaries.
Start fdisk or cdfisk to create the partitions. All partitions should be of type 83 (linux) except swap which has type 82 (linux swap). For software raids you may have to use different partition types.
Formating partitions
Secure-SLinux recommends two filesystems: ext3 and reiserfs.
ext3
Ext3 is based on ext2. It has been on the market for ages. Its 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/hdX
Create ext3: mkfs.ext3 /dev/hdX
Create reiserfs: mkfs.reiserfs /dev/hdX
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.
Configuration:
Please also read the documentation at HLFS/Chapter07
Remove all chroot restriction if you are using the SSLX-CD:
sysctl -N kernel.grsecurity. | grep chroot | xargs -I abc sysctl abc=0
(Note: "xargs -I abc" - the "I" is a capital "i")
Chroot now into your newly installed Secure-SLinux:
chroot /mnt/sslx
Create devices (we need random numbers for passwd and devices for grub):
/etc/rc.d/init.d/mountkernfs start
/etc/rc.d/init.d/udev start
Configuring the root password
Change the root password: passwd root
Configuring the setclock Script
The HLFS documentation claims that grsec enabled kernels do not support timezones. With Secure-SLinux timezones work.
So issue the following command if you have set your hardware clock to UTC otherwise leave it:
cat > /etc/sysconfig/clock << "EOF" # Begin /etc/sysconfig/clock UTC=1 # End /etc/sysconfig/clock EOF
It doesn't matter the least wether you set the hardware clock (in the BIOS) to UTC or localtime. If you multi boot into other OSes then you must use whatever the other OSes can cope with. For example Windows uses localtime.
If unsure leave it as it is.
Note: by default Secure-SLinux runs once a day NTP which sets the time according to time servers on the internet.
Configuring the Linux Console
Edit "/etc/sysconfig/console" to set the font and keyboard. The defaults are correctly 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 moch 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
Set the hostname of your server by editing "/etc/sysconfig/network".
Configuring the /etc/hosts File
Edit "/etc/hosts" to setup some basic name resolution. Its ok to just set the name and domain of the server.
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".
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.
Install the bootloader in the MBR:
Note: "root" in this context means the location of /boot/grub/*
cp --remove-destination -L /usr/lib/grub/i386-pc/{stage1,stage2,e2fs_stage1_5,reiserfs_stage1_5} /boot/grub
Boot into Secure-SLinux installation
After booting into the new Secure-SLinux installation:
Recreate the sshd keys
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
Congratulations! You have successfully installed Secure-SLinux on your server!
Adding users and security:
If you were trying to login into 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
Note: there is a bug in OpenSSH in Secure-SLinux V0.2.0dev. Basically you won't be able to login when using passwords. The reason is a function name conflict ("xcrypt()") between OpenSSH and libxcrypt (used for blowfish passwords). This bug will be fixed in Secure-SLinux V0.3.0dev which will come out at the beginning of may 2006. If you want to use SSLX-Server V0.2.0dev anyway, recompile OpenSSH according to instructions in HLFS or BLFS and rename the function "xcrypt()" and the places where it is called to something else (eg. "xcryptabc()") before you enter make.
Sshd is probably the only daemon connected to the internet which 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 everytime which would make logins rather slow - so using sshd for receiving connections for itself is a lot faster. The server key will in this case 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 have logged in to.
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 logged in to, 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. For this reason, root logins are by default disallowed.
Other reasons for disallowing root logins are:
Also:
causes a delay of about ten seconds. So brute force attacks would take for ever and are logged.
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 there 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 issue:
The -m option creates a home directory "/home/[newuser]" and copies all files in "/etc/skel" to this new directory.
To set a password issue: 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). Only "ping" and "passwd" are accessible by all users. All other commands belong to the group "admin" apart from "su" which belongs to "suers". 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, issue:
You can now change to root with "/usr/sbin/su - root"
Note: by default normal users do not have "/sbin:/usr/sbin" in their path, so you will have to use the full paths for those users to the binaries or change the configuration of bash (will be fixed in future releases)!
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.{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 within 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 you use more limiting rules (such as disabling sshd totally and only allow login from within 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.
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. 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.
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 (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 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 altered 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 by 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 issuing "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:
You will find the currently installed kernel in "/usr/src/kernel/sslx/linux-...". To compile the kernel after changing its parameters with "make menuconfig", issue "sslx-kernel-make" followed by "make modules_install". This will make sure that the kernel is not compiled with gcc's hardened specs (SSP/PIC/PIE) since the kernel has its own mechanism. You will find the compiled image at "arch/i386/boot/bzImage".
Secure-SLinux comes with loop-aes. If you need loop-aes, then copy "modules-compiled/lib/modules/*/block/*" to the corresponding directory in "/lib/modules" after every recompilation. "modules-compiled" is used as a cache of modules which are not recompiled when you make the kernel since the kernel will delete all contents of "/lib/modules/...". You can place your hardware drivers there if you use a proprietary driver which does not come with sources.
If you need normal loop, simply enable loop devices in the kernel.
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).
Otherwise you probably just want to forward emails to a relay server. Secure-SLinux has msmtp installed. To configure it, have a look at msmtp.sourceforge.net.
