[FreeBSD] Security, Process Credentials and Jail Virtualization

 

 

 

2.5 Security 

• The FreeBSD security model has been developed over 40 years of evolving application needs. The key insight is that security must be part of system design; it cannot be successfully added later.
• The model addresses many different goals:
  • Support authenticated local and remote access by multiple users, as well as integration with distributed authentication and directory services
  • Allow users to define permissions/access control lists to control use of their files by other users and groups
  • Support application authors in implementing compartmentalization for the purposes of intra-application policy and vulnerability mitigation
  • Implement efficient lightweight virtualization allowing administrators to delegate safe subsets of root access to guest operating-system instances
  • Allow the system administrator to control interactions between multiple users subject to various mandatory policies including information flow
  • Permit fine-grained logging of security events in the system such as filesystem operations or network accesses
  • Support and implement higher-level cryptographic services such as IPSec, ssh, transport-layer security (TLS), and full-disk encryption (GELI)

 

• Application developers and system administrators can build on these features in a broad variety of ways. Software authors can implement features such as application-level sandboxing, cryptographic protocols such as https and PGP, or intrusion detection and security monitoring tools. System administrators and integrators can build systems or appliances providing Virtual Private Networks (VPNs), multiuser file servers, or virtual hosting platforms.
• These concrete goals in turn imply several design principles and elements for the kernel and core operating-system components themselves:
  • A self-protecting Trusted Computing Base (TCB) guarantees enough system integrity to implement features such as multiple users and key storage
  • Strong process isolation using virtual memory ensures that the kernel is protected from user code, and that user processes are protected from one another
  • Identification and instrumentation of security-relevant operations throughout the kernel to implement access control, resource limits, and event auditing
  • A coherent privilege model, internal to the kernel, that allows exceptional operations (such as system administration, device-driver implementations) to occur in a structured way despite being outside the regular access-control mode
  • Design abstractions that facilitate future security models, as well as security localization in downstream products; for example, clean separation of policy and mechanism, object-oriented structure (subject to the limitations of C), and a userspace capability-system model providing protection, rather than policy, as the primitive for application compartmentalization
  • Cryptographic primitives, such as secure random number generation and a library of encryption and signature functions, that can support many different higher-level operating-system features and applications

 

 

 

Process Credentials

• The kernel associates a set of process credentials with each process, which contain its various UNIX user identifiers (UIDs), group identifiers (GIDs), resource limits, audit properties, mandatory access control labels, capability-mode state, etc. Security-relevant operations throughout the kernel check these credentials, known as the subject, along with object properties (such as file permissions and ownership), before allowing the operation to proceed. Credential contents are protected by virtue of being in the kernel address space: they can be modified only using system calls that impose rules preventing circumvention of security policies.
• FreeBSD implements the UNIX set-user-identity (setuid) and set-group-identity (setgid) permissions that allow programs executed by one user to operate with the privileges of another user or group. When the kernel detects an execution of such a binary, the process’s credentials are modified to have a user or group ID reflecting the file’s own IDs.
• When the file is owned by the root user, it allows elevated privileges to be acquired—but only for the purposes of running the program in question. The program can then implement specific functions, such as modifying the system password file to change the user’s password, but not the password of any other user. However, the technique is not limited to the root user: several users and groups serve to own common directories or devices, such as printers or terminals, which can be accessed by normal users only through specific binaries.

 

 

 

Jail Lightweight Virtualization

• While FreeBSD operates well under several full-machine virtualization technologies such as Xen and its own bhyve hypervisor, FreeBSD jails provide lighter-weight virtual machines at a much lower resource commitment. Each jail creates a group of processes with their own root-administered environment giving the illusion that it is running on its own dedicated hardware.
• Unlike a full virtual machine emulator that can run any operating system, a jail can only provide a FreeBSD kernel environment. However, it can provide that environment much more efficiently than a full virtual machine emulator: a single physical machine is typically limited to dozens or hundreds of concurrent full virtual machines, while it can support thousands of jails simultaneously.
• Three techniques underly the jail implementation:
  • access control, which prevents operations such as inter-jail process debugging;
  • resource subsetting, which limits jails to a specific subset of the hierarchical filesystem namespace (via chroot); 
  • true virtualization, in which jails are each presented a unique instance of global system namespaces.

 

 

 

도커가 떠오르지 뭡니까 🐳

 

 

 

• Access control and resource subsetting come at little cost, whereas full virtualization can incur substantial kernel-memory overhead. Virtualization is therefore configurable: jails may be granted access to a subset of system IP addresses within the global network-stack instance, or optional full network-stack virtualization can be configured.
• In a typical configuration, each jail has an independent FreeBSD userspace installation in a jail-specific filesystem tree—or for stronger resource isolation at greater resource commitment, its own filesystem instance.
• Each jail will be delegated its own subset of system IP addresses. Processes will operate as normal, but will be limited to those addresses; for example, an ISP might grant each virtual-domain customer its own virtual FreeBSD installation, with its own user account database, and each of which contains a webserver instance binding only the jail’s IP addresses. Most operations are permitted within a jail including:
  • running or signalling processes within the jail;
  • changing files within the jail;
  • binding low port numbers on the jail’s IP addresses; and
  • optionally managing ZFS data sets within a larger volume delegated to the jail.
• Processes running within a jail are not permitted to perform operations that would allow them to see or affect anything running outside their jail. This restriction is implemented in large part by masking the set of named system privileges available to root processes running within a jail.
  Constrained privileges include:
  • getting information on processes outside the jail;
  • changing kernel variables;
  • mounting or unmounting filesystems;
  • modifying physical network interfaces or configurations; and
  • rebooting the system.