NetBSD Veriexec subsystem

1.  NetBSD Veriexec subsystem • Veriexec is NetBSD's file integrity subsystem. It's kernel based, hence can provide some protection even in the case of a root compromise. • Veriexec works by loading a specification file, also called the signatures file, to the kernel. This file contains information about files Veriexec should monitor, as well as their digital fingerprint (along with the hashing algorithm used to produce this fingerprint), and various flags.

2.  NetBSD Veriexec subsystem • At the moment, the following hashing algorithms are supported by Veriexec: MD5, SHA1, SHA256, SHA384, SHA512, and RMD160. • Signatures file An entry in the Veriexec signatures file looks like this: /path/to/file algorithm fingerprint flags Where the first element, the path, must always be an absolute path. The algorithm is one of the algorithms listed above, and fingerprint is the ASCII fingerprint.

3.  NetBSD Veriexec subsystem • Generating fingerprints • You can generate ASCII fingerprints for each algorithm using the following tools: • MD5 /usr/bin/cksum -a md5 • SHA1 /usr/bin/cksum -a sha1 • SHA256 /usr/bin/cksum –a sha256 • SHA384 /usr/bin/cksum –a sha384 • SHA512 /usr/bin/cksum -a sha512 • RMD160 /usr/bin/cksum -a rmd160 • For example, to generate a MD5 fingerprint for /bin/ls: % cksum -a md5 < /bin/ls a8b525da46e758778564308ed9b1e493 % cksum -a sha512 < /bin/ps 381d4ad64fd47800897446a2026eca42151e03adeae158db5a34d12c529559113d928a9fef9a7c4615d257688d1da4645db004081030d7f080bb7198067eb890

4.  NetBSD Veriexec subsystem • Each entry may be associated with zero or more flags. Currently, these flags indicate how the file the entry is describing should be accessed. Note that this access type is enforced only in strict level 2 (IPS mode) and above. • The access types you can use are “DIRECT”, “INDIRECT”, and “FILE”. • DIRECT access means that the file is executed directly, and not invoked as an interpreter for some script, or opened with an editor. Usually, most programs you use will be accessed using this mode: % ls /tmp % cp ~/foo /tmp/bar % rm ~/foo • INDIRECT access means that the file is executed indirectly, and is invoked to interpret a script. This happens usually when scripts have a #! magic as their first line. For example, if you have a script with the following as its first line: #!/bin/sh And you run it as: % ./script.sh Then /bin/sh will be executed indirectly -- it will be invoked to interpret the script.

5.  NetBSD Veriexec subsystem • FILE entries refer to everything which is not (or should not) be an executable. This includes shared libraries, configuration files, etc. Some examples for Veriexec signature file entries: /bin/ls MD5 dc2e14dc84bdefff4bf9777958c1b20b DIRECT /usr/bin/perl MD5 914aa8aa47ebd79ccd7909a09ed61f81 INDIRECT /etc/pf.conf MD5 950e1dd6fcb3f27df1bf6accf7029f7d FILE

6.  NetBSD Veriexec subsystem • Veriexec allows you to specify more than one way to access a file in an entry. For example, even though /usr/bin/perl is mostly used as an interpreter, it may be desried to be able to execute it directly, too: /usr/bin/perl MD5 914aa8aa47ebd79ccd7909a09ed61f81 DIRECT, INDIRECT • Shell scripts using #! magic to be “executable” also require two access types: We need them to be “DIRECT” so we can execute them, and we need them to be “FILE” so that the kernel can feed their contents to the interpreter they define: /usr/src/build.sh MD5 e80dbb4c047ecc1d84053174c1e9264a DIRECT, FILE

7.  NetBSD Veriexec subsystem • Veriexec access type aliases Alias = Expansion PROGRAM=DIRECT INTERPRETER=INDIRECT SCRIPT=DIRECT, FILE LIBRARY=FILE • After you've generated a signatures file, you should save it as /etc/signatures, and enable Veriexec in rc.conf: veriexec=YES

8.  NetBSD Veriexec subsystem • Strict levels • Since different people might want to use Veriexec for different purposes, we also define four strict levels, ranging 0-3, and named “learning”, “IDS”, “IPS”, and “lockdown” modes. • In strict level 0, learning mode, Veriexec will act passively and simply warn about any anomalies. Combined with verbose level 1, running the system in this mode can help you fine-tune the signatures file. This is also the only strict level in which you can load new entries to the kernel. • Strict level 1, or IDS mode, will deny access to files with a fingerprint mismatch. This mode suits mostly to users who simply want to prevent access to files which might've been maliciously modified by an attacker. • Strict level 2, IPS mode, takes a step towards trying to protect the integrity of monitored files. In addition to preventing access to files with a fingerprint mismatch, it will also deny write access and prevent the removal of monitored files, and enforce the way monitored files are accessed. (as the signatures file specifies).

9.  NetBSD Veriexec subsystem • Lockdown mode (strict level 3) can be used in highly critical situations such as custom made special-purpose machines, or as a last line of defense after an attacker compromised the system and we want to prevent traces from being removed, so we can perform post-mortem analysis. It will prevent the creation of new files, and deny access to files not monitored by Veriexec. • You can use /etc/sysctl.conf to auto raise the strict level to the desired level after a reboot: kern.veriexec.strict=1 • Veriexec and layered file systems • Veriexec can be used on NFS file systems on the client side and on layered file systems such as the union file system. The files residing on these file systems need only be specified in the /etc/signatures file and that the file systems be mounted prior to the fingerprints being loaded.

10.  NetBSD Veriexec subsystem • Kernel configuration To use Veriexec, aside from creating a signatures file, you should enable (uncomment) it in your kernel's config file: (e.g. /usr/src/sys/arch/i386/conf/GENERIC): options VERIFIED_EXEC Then, you need to enable the hashing algorithms you wish to support: options VERIFIED_EXEC_FP_MD5 options VERIFIED_EXEC_FP_SHA1 options VERIFIED_EXEC_FP_RMD160 options VERIFIED_EXEC_FP_SHA512 options VERIFIED_EXEC_FP_SHA384 options VERIFIED_EXEC_FP_SHA256 And finally, enable the Veriexec pseudo device: pseudo-device veriexec 1 Once done, rebuild and reinstall your kernel.

11.  NetBSD Veriexec subsystem Resources: • http://www.netbsd.org/guide/en/index.html - Part III. System configuration, administration and tuning Chapter 18. NetBSD Veriexec subsystem • Brett Lymn - Preventing the Unauthorised Binary • Verified Executables for NetBSD • Alf Zugenmaier MSR Cambridge - Privacy in UbiquitousComputing

12. FreeBSD Jail • The FreeBSD ‘‘Jail’’ facility provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX ‘‘root’’ model. • In Jail, users with privilege find that the scope of their requests is limited to the jail, allowing system administrators to delegate management capabilities for each virtual machine environment.

13. FreeBSD Jail • Mechanisms such as chroot(2) provide a modest level compartmentalisation,it is well known that these mechanisms have serious shortcomings,both in terms of the scope of their functionality, and effectiveness at what they provide • In the case of the chroot(2) call, a process’s visibility of the file system name-space is limited to a single subtree. However, the compartmentalisation does not extend to the process or networking spaces and therefore both observation of and interference with processes outside their compartment is possible.

14. FreeBSD Jail • The BSD family of operating systems have implemented the ‘‘securelevel’’ mechanism which allows the administrator to block certain configuration and management functions from being performed by root, until the system is restarted and brought up into single-user mode. While this does provide some amount of protection in the case of a root compromise of the machine, it does nothing to address the need for delegation of certain root abilities.

15. FreeBSD Jail • The Jail Partitioning Solution • partition a FreeBSD environment (processes, file system, network resources) into a management environment, and optionally subset Jail environments. • allowing multiple users in each jail • privileged root user in each jail • Consequently the administrator of a FreeBSD machine can partition the machine into separate jails, and.provide access to the super-user account in each of these without losing control of the over-all environment.

16. FreeBSD Jail

17. FreeBSD Jail • When a process is placed in a jail, it, and any descendents of the process created after the jail creation, will be in that jail. • A process may be in only one jail, and after creation, it can not leave the jail. • The only way for a new process to enter the jail is by inheriting access to the jail from another process already in that jail. • Processes may never leave the jail they created, or were created in.

18. FreeBSD Jail • Membership in a jail involves a number of restrictions: • access to the file name-space is restricted in the style of chroot(2), • the ability to bind network resources is limited to a specific IP address, • the ability to manipulate system resources • perform privileged operations is sharply curtailed, • ability to interact with other processes is limited to only processes inside the same jail.

19. FreeBSD Jail • Jail Implementation • Processes running with root privileges in the jail find that there are serious restrictions on what it is capable of doing — in particular,activities that would extend outside of the jail: • Modifying the running kernel by direct access and loading kernel modules is prohibited. • Modifying any of the network configuration, interfaces, addresses, and routing table is prohibited. • Mounting and unmounting file systems is prohibited. • Creating device nodes is prohibited. • Accessing raw, divert, or routing sockets is prohibited. • Modifying kernel runtime parameters, such as most sysctl settings, is prohibited. • Changing securelevel-related file flags is prohibited. • Accessing network resources not associated with the jail is prohibited.

20. FreeBSD Jail • Other privileged activities are permitted as long as they are limited to the scope of the jail: • Signalling any process within the jail is permitted. • Changing the ownership and mode of any file within the jail is permitted, as long as the file flags permit this. • Deleting any file within the jail is permitted, as long as the file flags permit this. • Binding reserved TCP and UDP port numbers on the jails IP address is permit-ted. (Attempts to bind TCP and UDP ports using IN_ADDRANY will be redi-rected to the jails IP address.) • Functions which operate on the uid/gid space are all permitted since they act as labels for filesystem objects of proceses which are partitioned off by other mechanisms.

21. FreeBSD Jail • Implementation jail in the FreeBSD kernel. • The jail(2) system call, allocation, refcounting and deallocation of struct prison. • Fortification of the chroot(2) facility for filesystem name scoping. • Restriction of process visibility and interaction. • Restriction to one IP number. • Adding jail awareness to selected device drivers. • General restriction of super-users powers for jailed super-users.

22. FreeBSD Jail /* * This structure describes a prison. It is pointed to by all struct * ucreds's of the inmates. pr_ref keeps track of them and is used to * delete the struture when the last inmate is dead. * * Lock key: * (a) allprison_mtx * (p) locked by pr_mtx * (c) set only during creation before the structure is shared, no mutex * required to read * (d) set only during destruction of jail, no mutex needed */ #if defined(_KERNEL) || defined(_WANT_PRISON) struct prison { LIST_ENTRY(prison) pr_list; /* (a) all prisons */ int pr_id; /* (c) prison id */ int pr_ref; /* (p) refcount */ char pr_path[MAXPATHLEN]; /* (c) chroot path */ struct vnode *pr_root; /* (c) vnode to rdir */ char pr_host[MAXHOSTNAMELEN]; /* (p) jail hostname */ u_int32_t pr_ip; /* (c) ip addr host */ void *pr_linux; /* (p) linux abi */ int pr_securelevel; /* (p) securelevel */ struct task pr_task; /* (d) destroy task */ struct mtx pr_mtx; };

23. FreeBSD Jail struct ucred { … struct prison *cr_prison; /* jail(2) */ … }; struct proc { … struct ucred *p_ucred; /* (c) Process owner's identity. */ … }

24. FreeBSD Jail • Creating a Jail Environment • While the jail(2) call could be used in a number of ways, the expected configuration creates a complete FreeBSD installation for each jail. • On a box making use of the jail facility,we refer to two types of environment: the host environment, and the jail environment. • Typically,this includes: • Create empty /etc/fstab • Disable portmapper • Run newaliases.•Disabling interface configuration • Configure the resolver • Set root password • Set timezone • Add any local accounts • Install any packets

25. FreeBSD Jail • Starting Jails • Jails are typically started by executing their /etc/rc script in much the same manner a shell was started in the previous section. • Before starting the jail, any relevant network-ing configuration should also be performed. • There is no init process, no kernel daemons, and a J flag is present beside all processes indicating the pres-ence of a jail.

26. Systrace – interactive policy generation for system calls • In Unix, system calls are the gateway to privileged operations • A successful system compromise possible only via system call

27. Systrace – interactive policy generation for system calls • Systrace offers fine-grained confinement for multiple applications with multiple system policies • Systrace intercept system call • Allow or denies their execution • Rewrites system call arguments • Policy determines which system calls are allowed • Specified correct policy is difficult • Different policies for different binaries • Policy requirements may change for single application depending on it’s use

28. Systrace – interactive policy generation for system calls • Interactive policy generation. • Quick and easy generation of policy during program execution • Notification for every system call not covered by current policy

29. Systrace – interactive policy generation for system calls • Policy being specified iteratively • Result of every notification is a refined policy • Converges quickly

30. Systrace – interactive policy generation for system calls native-fsread: filename match "/usr/lib/*" then permit native-fsread: filename match "/usr/share/*" then permit native-fsread: filename match "/var/www/*" then permit native-fstat: permit native-fstatfs: permit native-fswrite: filename eq "/dev/null" then permit native-fswrite: filename eq "/dev/tty" then permit native-fswrite: filename match "/logs/*" then permit native-fswrite: filename match "/var/www/logs/*" then permit native-getdirentries: permit native-geteuid: permit native-getpid: permit native-getrlimit: permit native-getsockname: permit native-gettimeofday: permit native-getuid: permit native-ioctl: permit native-issetugid: permit native-kill: permit native-listen: permit native-lseek: permit native-mmap: permit native-mprotect: permit native-munmap: permit native-pread: permit native-pwrite: permit native-read: permit native-recvfrom: permit native-select: permit native-semget: permit native-semop: permit native-sendto: true then permit Sample policy for httpd Policy: /usr/sbin/httpd, Emulation: native native-__semctl: permit native-__sysctl: permit native-accept: permit native-bind: sockaddr eq "inet-[0.0.0.0]:443" then permit native-bind: sockaddr eq "inet-[0.0.0.0]:80" then permit native-break: permit native-chdir: filename eq "/" then permit native-chown: filename match "/var/www/logs/*" then permit native-chroot: permit native-close: permit native-connect: sockaddr sub ":53" then permit native-dup2: permit native-exit: permit native-fcntl: permit native-flock: permit native-fork: permit native-fsread: filename eq "/dev/arandom" then permit native-fsread: filename eq "/dev/null" then permit native-fsread: filename eq "/dev/tty" then permit native-fsread: filename eq "/etc" then permit native-fsread: filename eq "/etc/group" then permit native-fsread: filename eq "/etc/hosts" then permit native-fsread: filename eq "/etc/malloc.conf" then permit native-fsread: filename eq "/etc/resolv.conf" then permit native-fsread: filename eq "/etc/spwd.db" then permit native-fsread: filename eq "/etc/ssl" then permit native-fsread: filename eq "/htdocs" then permit native-fsread: filename eq "/usr/libexec/ld.so" then permit native-fsread: filename eq "/usr/sbin/suexec" then permit native-fsread: filename eq "/var/run/ld.so.hints" then permit native-fsread: filename eq "/var/www" then permit native-fsread: filename eq "<non-existent filename>" then deny[enoent] native-fsread: filename match "/etc/ssl/*" then permit native-fsread: filename match "/htdocs/*" then permit native-setegid: permit native-seteuid: permit native-setgid: permit native-setgroups: permit native-setrlimit: permit native-setsid: permit native-setsockopt: permit native-setuid: permit native-shutdown: permit native-sigaction: permit native-sigprocmask: permit native-sigreturn: permit native-socket: permit native-umask: permit native-wait4: permit native-write: permit native-writev: permit

31. Systrace – interactive policy generation for system calls • Very simple policy language; easy to edit by hand

32. Systrace – interactive policy generation for system calls • Intrusion detection • Once policy have been generated, any operations not covered by policy indicates a security problem • Automatic policy generation • Records all system calls an application executes and generates policy to cover them • Automatic policy enforcement • Enforces the configured policy • Denies and logs policy violates to syslog

33. Systrace – interactive policy generation for system calls • Implementation • Policies for system call are deny permit or ask • Information exported via /dev/systrace • Deny and allow are handled in the kernel. No need to ask userland • Several requests supported via ioctl • Attach to a process • Detach from process • Answer a policy question deny or allow • Do memory IO from userland process • Request a new policy or change an existing policy • Report information about monitored process • Replace system call arguments

34. Systrace – interactive policy generation for system calls

35. Systrace – interactive policy generation for system calls • Kernel answer with messages that can be read from /dev/systrace file descriptor: • SYSTR_MSG_ASK: Kernel request userland decision about a system call • SYSTR_MSG_RES: Reports the return values and error codes after system call execution • SYSTR_MSG_EMUL: Reports a change of emulation. The inkernel policy has been reset • SYSTR_MSG_CHILD: Reports that a new child was created or ahs terminated.

36. Systrace – interactive policy generation for system calls • If systrace process dies all monitored process receive a SIGKILL from kernel. • Userland handles more complicated policies and notifications • Systrace consist of two parts: • Intercept abstraction to /dev/systrace • Systrace application

37. Systrace – interactive policy generation for system calls • Systrace: • Manages policies for different applications • Policy is installed after successful call to execve • User configured policy in $HOME/.systrace • Global policies in /etc/systrace • Directory structure is flat: bin_ls bin_rm usr_local_bin_mplayer

38. Systrace – interactive policy generation for system calls • Policy file contain binary name and emulation: • No collision possible Policy: /bin/ls, Emulation:native • Policy file get rewritten during interactive generation of policy • Policy is applied to translated system call arguments • A matching policy issue a decision: • Deny – including error number • Permit – action is allowed • If no policy entry matches systrace ask the user • In automatic enforcement mode, asking results in automatic deniel of system call • In automatic policy generation mode, new policy is generated matching arguments precisely

39. Systrace – interactive policy generation for system calls Resources: • Michael W. Lucas - Creating Systrace Policies (OnLamp.com BSD column) • http://www.citi.umich.edu/u/provos/systrace/ - Systrace - Interactive Policy Generation for System Calls • Niels Provos - Improving Host Security with System Call Policies (Center for Information Technology Integration University of Michigan) • Michael W. Lucas - Systrace Policies (OnLamp.com BSD column) • Brandon Palmer, Jose Nazario - systrace in OpenBSD (InformIT)