File:  [NetBSD Developer Wiki] / wikisrc / pkgsrc / hardening.mdwn
Revision 1.7: download - view: text, annotated - select for diffs
Thu Mar 17 13:27:17 2016 UTC (5 years, 10 months ago) by khorben
Branches: MAIN
CVS tags: HEAD
Mention the differences in performance for RELRO

[[!meta title="Hardening pkgsrc"]]

[pkgsrc](http://www.pkgsrc.org/) supports a number of mechanisms that are meant
to improve the security of compiled binaries. They can be individually enabled
in `mk.conf`, and consist of:

* `PKGSRC_MKPIE`: forces the creation of PIE (Position Independent
  Executables) when supported on the current platform. This option is necessary
  to fully leverage ASLR as a mitigation for security vulnerabilities.
* `PKGSRC_USE_FORTIFY`: allows substitute wrappers to be used for commonly used
  functions that do not bounds checking regularly - but could in some cases.
* `PKGSRC_USE_RELRO`: this also makes the exploitation of some security
  vulnerabilities more difficult in some cases.
* `PKGSRC_USE_SSP`: enables stack-smashing protection (again, on supported
  platforms)

# Caveats

## Problems with `PKGSRC_MKPIE`

### No support for cwrappers

As of the time of this article `PKGSRC_MKPIE` is not supported by
`pkgtools/cwrappers` (`USE_CWRAPPERS` in `mk.conf`).

### Packages failing to build

A number of packages may fail to build with this option enabled. The failures
are often related to the absence of the "-fPIC" compilation flag when building
libraries or executables (or ideally "-fPIE" in the latter case). This flag is
added to the `CFLAGS` already, but requires the package to actually support it.

#### How to fix

These instructions are meant as a reference only; they likely need to be adapted
for many packages individually.

For packages using `Makefiles`:

    MAKE_FLAGS+=	CFLAGS=${CFLAGS:Q}
    MAKE_FLAGS+=	LDFLAGS=${LDFLAGS:Q}

For packages using `Imakefiles`:

    MAKE_FLAGS+=	CCOPTIONS=${CFLAGS:Q}
    MAKE_FLAGS+=	LOCAL_LDFLAGS=${LDFLAGS:Q}

### Run-time crashes

Some programs may fail to run, or crash at random times once built as PIE. Two
scenarios are essentially possible:

* actual bug in the program crashing, exposed thanks to ASLR/mprotect;
* bug in the implementation of ASLR/mprotect in the Operating System.

## Problems with `PKGSRC_USE_FORTIFY`

### Packages failing to build

This feature makes use of pre-processing directives to look for hardened,
alternative implementations of essential library calls. Some programs may fail
to build as a result; this usually happens for those trying too hard to be
portable, or otherwise abusing definitions in the standard library.

This will require a modification to the program, or disabling this feature for
part or all of the build.

### Run-time crashes

Just like with `PKGSRC_MKPIE` above, this feature may cause some programs to
crash, usually indicating an actual bug in the program. The fix will typically
involve patching the original program.

## Problems with `PKGSRC_USE_RELRO`

### Performance impact

For better protection, full RELRO requires every symbol to be resolved when the
program starts, rather than lazily at run-time. This will have more impact on
programs using a lot of symbols, or linked to libraries exposing a lot of
symbols. Therefore, daemons or programs otherwise running in background are
affected only when started. Programs loading plug-ins at run-time are affected
when loading the plug-ins.

The impact is not expected to be noticeable on modern hardware, except in some
cases for big programs.

## Problems with `PKGSRC_USE_SSP`

### Packages failing to build

The stack-smashing protection provided by this option does not work for some
programs. The two most common situations in which this happens are:

* the program makes use of the `alloca(3)` library call (memory allocator on the
  stack)
* the program allocates variables on the stack, with the size determined at
  run-time.

Both cases will require a modification to the program, or disabling this feature
for part or all of the build.

### Run-time crashes

Again, this feature may cause some programs to crash, usually indicating an
actual bug in the program. Patching the original program is then required.

# Auditing the system

The illusion of security is worse than having no security at all. This section
lists a number of ways to ensure the security features requested are actually
effective.

_These instructions were obtained and tested on a system derived from NetBSD 7
(amd64). YMMV._

## Checking for PIE

The ELF executable type in use changes for binaries built as PIE; without:

    $ file /path/to/bin/ary
    /path/to/bin/ary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped

as opposed to the following binary, built as PIE:

    $ file /path/to/pie/bin/ary
    /path/to/pie/bin/ary: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped

The latter result is then what is expected.

## Checking for RELRO

The following command should list a section called `RELRO`:

    $ objdump -p /path/to/bin/ary

    /path/to/bin/ary:     file format elf64-x86-64

    Program Header:
    [...]
       RELRO off    0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0

## Checking for SSP

Building objects, binaries and libraries with SSP will affect the presence of
additional symbols in the resulting file:

    $ nm /path/to/bin/ary
    [...]
                     U __stack_chk_fail
    0000000000600ea0 B __stack_chk_guard

This is an indicator that the program was indeed built with support for SSP.


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb