Difference between pages "Hardening Concepts" and "System Administration Practice"

From Funtoo
(Difference between pages)
Jump to: navigation, search
(I wrote about reducing surface area.)
 
m
 
Line 1: Line 1:
There are several concepts that can go into hardening. There are compile-time changes such as stack protection as well as more invasive runtime changes such as mandatory access control. Hardening itself is not a correction to any particular issue. It's not a 'bug fix'. Hardening looks at a threat and provides a means for mitigating an exploit that successfully used the vulnerability. Hardening is best used in a layered fashion without relying on any one technique since there can be flaws in any technique.
+
== Keep Portage Tree Up-To-Date ==
 +
Even if you're not doing a full update every day, you should sync the portage tree and overlays regularly. It will reduce the time that you need to sync tree before a system upgrade. Also, if you just want to install something, it will be installed with latest deps so you will not waste time on upgrading it later. Here is an example script to upgrade portage and overlay every day:
 +
<console>
 +
###i## nano /etc/cron.daily/autosync.sh
 +
#!/bin/bash
 +
log="/var/log/autosync.log"
 +
if [ ! -f $log ]; then
 +
touch $log
 +
chmod 600 $log
 +
chown root:root $log
 +
fi
  
= Stack protections =
+
echo >> $log
 +
echo "*** autosync started! ($(date +'%d-%m-%Y %H:%M:%S'))" >> $log
 +
echo "*** running emerge --sync" >> $log
 +
emerge -q --sync >> $log 2>&1
 +
if [ -f /usr/bin/layman ]; then
 +
echo >> $log
 +
echo "*** running layman -S" >> $log
 +
/usr/bin/layman -S --nocolor >> $log 2>&1
 +
fi
 +
</console>
  
A stack protection scheme protects against a [[wikipedia:Stack buffer overflow|stack buffer overflow]]. The basic premise is that there is a buffer on the stack. That buffer is probably a local variable in a programming language like C. That buffer gets overwritten by unchecked data from an external source without verifying the length. This results in writing past the end of the buffer and potentially overwriting the function's return address. This address is where the code goes when the function is finished. If an attacker can get data written there, they can take over control. That is how such issues as the Morris worm worked that exploited a buffer overflow in the fingerd program. If stack protection of some sort were there, when the exploit was attempted, the finger server would have died instead of getting exploited. Stack protection consequently converts a possible root exploit into a denial of service instead.
+
== Purge unused distfiles ==
 +
Distfiles may take up a lot of space on disk, and if you do not clean them from time to time it may become an issue. There are many ways to clean them.  
  
gcc has the <code>-fstack-protector</code> flag and related flags available. The basics of what stack protection does is to put a so-called canary value on the stack and make sure that value is the same when the stack frame is popped. If the canary value changes, that indicates that the stack was overwritten by some sort of buffer overflow. When this happens, it indicates that the return address could have been overwritten which allows an attacker to control where the next instruction is. There are two components to how <code>-fstack-protector</code> works. The compiler inserts code to check the values. The C library provides the functions. Consequently you can run into issues where there is code compiling without a libc that implements the helper functions that will technically succeed at compiling but fail to link. This results in needing to turn off stack protection for at least parts of glibc and gcc as well as not using that feature in programs linking against things like klibc.
+
* Remove distfiles which wasn't accessed in last 90 days. ('''WARNING''': It will not work if distfiles are on filesystem with '''noatime''' option. You may want think about '''relatime''').
  
= Memory Scrambling =
+
{{Code|/etc/cron.daily/distfiles-auto-purge.sh|<source lang="bash">#!/bin/bash
 +
find /usr/portage/distfiles -maxdepth 1 -type f -atime +90 -exec rm {} \;</source>}}
  
The typical memory allocation leaves the memory as is when it is freed. The problem with this is that later that memory can be allocated elsewhere, given that memory, and read. This allows a password to be used in one part of software and be read elsewhere. A similar concern occurs when there is a core dump due to a crash or memory gets swapped to disk.
+
[[Category:HOWTO]]
 
+
This sort of issue can be addressed mostly through intelligent choices by software developers. However, app-shells/bash provides a <code>mem-scramble</code> USE flag to change its memory allocation strategy to one that will randomize the memory when freed helping to mitigate issues with leaving the memory as-is when freed. Sqlite provides a <code>secure-delete</code> USE flag that triggers similar functionality in it.
+
 
+
= Reduced Privileges =
+
 
+
Some programs such as portage run as root. This is a problem when root privileges are not necessary. It provides a window of opportunity to exploit a program and gain root privileges.
+
 
+
In the case of Portage, this can be addressed through the <code>userpriv</code>, <code>usersandbox</code>, <code>userfetch</code>, and <code>usersync</code> features. For daemon sorts of programs, there is usually a configuration mechanism that allows the program to be started as root but drop privileges to run as nobody or apache or some similar user minimizing the window of opportunity to gain root access through an exploit.
+
 
+
= Reduce Surface Area =
+
 
+
Minimizing installed packages and open network ports is an obvious hardening strategy. The premise here is that even if there's a vulnerability in a package, unless that package is actually used for something, it's not a problem for you because it won't even be installed and even if it is installed and running, it's not visible to the network.
+
 
+
Intelligent choices for what to include in the base stage as well as firewall rules are ways to address this hardening strategy.
+

Revision as of 16:55, 13 January 2014

Keep Portage Tree Up-To-Date

Even if you're not doing a full update every day, you should sync the portage tree and overlays regularly. It will reduce the time that you need to sync tree before a system upgrade. Also, if you just want to install something, it will be installed with latest deps so you will not waste time on upgrading it later. Here is an example script to upgrade portage and overlay every day:

# nano /etc/cron.daily/autosync.sh
#!/bin/bash
log="/var/log/autosync.log"
if [ ! -f $log ]; then
	touch $log
	chmod 600 $log
	chown root:root $log
fi

echo >> $log
echo "*** autosync started! ($(date +'%d-%m-%Y %H:%M:%S'))" >> $log
echo "*** running emerge --sync" >> $log
emerge -q --sync >> $log 2>&1
if [ -f /usr/bin/layman ]; then
	echo >> $log
	echo "*** running layman -S" >> $log
	/usr/bin/layman -S --nocolor >> $log 2>&1
fi

Purge unused distfiles

Distfiles may take up a lot of space on disk, and if you do not clean them from time to time it may become an issue. There are many ways to clean them.

  • Remove distfiles which wasn't accessed in last 90 days. (WARNING: It will not work if distfiles are on filesystem with noatime option. You may want think about relatime).
Code: /etc/cron.daily/distfiles-auto-purge.sh
#!/bin/bash
find /usr/portage/distfiles -maxdepth 1 -type f -atime +90 -exec rm {} \;