About Redundancy

Redundancy is the existance of more than one means for accomplishing a given task.

  • If one fails, goes down for maintenance, …, another one takes over
  • When unexpected things happend different parts react differently

Redundancy and KISS (keep it simple, stupid) are the basis of all reliable engineering!

Redundancy can backfire:

  • Increases complexity
  • Makes people more careless
  • Can lead to higher production pressure (“the system is designed to handle more…”)

Aspects in Software Security

Code cannot reliably be made secure today in most situations.

  • Expect failure and have redundant security mechanisms
  • Fail secure (is not “fail functional”, sadly)
  • Adequate risk management

Test-Before-Use Principle

This is a fundamental (secure) coding principle!

  • Always test all assumptions about data
  • Afterwards code only has to work for tested properties (KISS)
  • Critical for reliability (and therefore availability)
  • Examples: length of strings or buffers, allowed characters or ranges, state of files, …

Input Validation

Establish properties when data is entered (-> according to test-before-use). This enables later processing steps to depend on the tested properties, which makes code simpler.

Special case: Pass-All Input Validation. Document that validation allows all inputs, or document challenges which led to this decision.

Input Normalization

Preprocessing step to decrease variability of input data, which simplifys further processing.

Input validation is a prerequisite for normalization! At least for all properties the normalization step depends on.

System Permissions

These are the basic permission mechanisms available via the OS kernel.

  • File permissions: read, write, modify, delete, execute
  • Metadata permissions: modify permissions, last access date, …
  • Device access: network, human-interface devices, usb
  • Process permissions: memory access, resource limits

Least Privilege Principle

Always run things with the least amount of privileges they need! This gives attackers only the least amount of privileges in case of successful attacks.

Software needs to be designed to work with as few privileges as possible. This also helps with misbehaving software as it can do less damage.

More information: https://en.wikipedia.org/wiki/Principle_of_least_privilege

UNIX Permission Model

  1. Everything is a file (really everything!)
  2. Every file has 3 permission groups: user, group and other
  3. Every file can be readable (r), writable (w), executable (x) in each permission group
    Note: x is required to open directories; x becomes s on executable files with SUID bit
  4. Each process jas a iser amd a group which determines its rights

root is special and can change all permissions! Processes running as root can drop privileges to regular users. Privilege drop can fail.

setuid and setgid set user and group for a running process respectively. setgid should be run before setuid.

chroot is a command to change the apparent root directory (top-most file system level). By default this is "/" (the system root directory). By changing the root directory, a process can be isolated by “locking” it into a subdirectory. The root user can always escape.

Privilege drop and chroot can be used to effectively sandbox and application.

  1. Prepare operation
  2. chroot to secure directory (no hardlinks,special files, …)
  3. Drop privileges

Limitations:

  • No operations that require root
  • No namespace isolation
  • No resource control
  • Needs to be done right, else breakout becomes possible
  • Good for code that only needs limited access
  • Available on all UNIX and UNIX-like systems

Mandatory Access Control

Fine-grained access control enforced by the kernel. This allows very specific permissions, even restricting root (usually requires reboot). It cannot be disabled during run-time. But, it is difficult to configure and may hinder normal system administration.

Examples:

Sandbox

A sandbox is an isolated environment where application run. Used for analysis, but attack code often does sandbox-detection and then plays nice.

Examples for sandbox environments:

  • chroot and privilege drop
  • Linux namespaces
  • Linux seccomp
  • Linux seccomp-bpf
  • Firejail
  • Containers
  • Virtual Machines

Defense in Depth

Idea: Have several security mechanisms so that it is still enough even if others have been circumvented by an attacker.