A number of mechanisms are available in pkgsrc to improve the security of the resulting system. They can be enabled individually in mk.conf, and consist of:

Caveats

Problems with PKGSRC_MKPIE

Recent support for cwrappers

PKGSRC_MKPIE is only supported by pkgtools/cwrappers from the 2017Q3 release on (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:

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 simply when required 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.

Run-time crashes

Some programs handle plug-ins and dependencies in a way that conflicts with RELRO: for instance, with an initialization routine listing any other plug-in required. With full RELRO, the missing symbols are resolved before the initialization routine can run, and the dynamic loader will not be able to find them directly and abort as a result. Unfortunately, this is how Xorg loads its drivers. Partial RELRO can be applied instead in this case.

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:

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.

Performance impact

The compiler emits extra code when using this feature: a check for buffer overflows is performed when entering and exiting functions, requiring an extra variable on the stack. The level of protection can otherwise be adjusted to affect only those functions considered more sensitive by the compiler (with -fstack-protector instead of -fstack-protector-all).

The impact is not expected to be noticeable on modern hardware. However, programs with a hard requirement to run at the fastest possible speed should avoid using this feature, or using libraries built with this feature.

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 partial 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

This check is now performed automatically if PKG_DEVELOPER is set and RELRO is enabled.

Checking for full RELRO

The dynamic loader will apply RELRO immediately when detecting the presence of the BIND_NOW flag:

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

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

Dynamic Section:
[...]
  BIND_NOW             0x0000000000000000

This has to be combined with partial RELRO (see above) to be fully efficient.

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.

References

Add a comment
Contact | Disclaimer | Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
NetBSD® is a registered trademark of The NetBSD Foundation, Inc.