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.
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.
NetBSD Veriexec subsystem
• Generating fingerprints
• You can generate ASCII fingerprints for each algorithm using the
following tools:
–
–
–
–
–
–
MD5
SHA1
SHA256
SHA384
SHA512
RMD160
/usr/bin/cksum -a md5
/usr/bin/cksum -a sha1
/usr/bin/cksum –a sha256
/usr/bin/cksum –a sha384
/usr/bin/cksum -a sha512
/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
381d4ad64fd47800897446a2026eca42151e03adeae158db5a34d12c52
9559113d928a9fef9a7c4615d257688d1da4645db004081030d7f080bb7
198067eb890
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.
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
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
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
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).
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.
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.
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
Ubiquitous Computing
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.
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.
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.
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.
FreeBSD Jail
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.
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.
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.
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.
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.
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;
};
FreeBSD Jail
struct ucred {
…
struct prison *cr_prison;
…
};
/* jail(2) */
struct proc {
…
struct ucred
identity. */
…
}
/* (c) Process owner's
*p_ucred;
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
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.
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
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
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
Systrace – interactive policy
generation for system calls
• Policy being specified iteratively
– Result of every notification is a refined policy
– Converges quickly
Systrace – interactive policy
generation for system calls
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-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
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
Systrace – interactive policy
generation for system calls
• Very simple policy language; easy to edit
by hand
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
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
Systrace – interactive policy
generation for system calls
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.
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
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
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
Systrace – interactive policy
generation for system calls
Resources:
1. Michael W. Lucas - Creating Systrace Policies
(OnLamp.com BSD column)
2. http://www.citi.umich.edu/u/provos/systrace/ - Systrace
- Interactive Policy Generation for System Calls
3. Niels Provos - Improving Host Security with System
Call Policies (Center for Information Technology
Integration University of Michigan)
4. Michael W. Lucas - Systrace Policies (OnLamp.com
BSD column)
5. Brandon Palmer, Jose Nazario - systrace in OpenBSD
(InformIT)