[BACK]Return to security.7 CVS log [TXT][DIR] Up to [cvs.NetBSD.org] / src / share / man / man7

File: [cvs.NetBSD.org] / src / share / man / man7 / security.7 (download)

Revision 1.8, Wed Mar 30 11:41:48 2011 UTC (13 years ago) by jruoho
Branch: MAIN
CVS Tags: yamt-pagecache-tag8, yamt-pagecache-base8, yamt-pagecache-base7, yamt-pagecache-base6, yamt-pagecache-base5, yamt-pagecache-base4, yamt-pagecache-base3, yamt-pagecache-base2, yamt-pagecache-base, netbsd-6-base, netbsd-6-1-RELEASE, netbsd-6-1-RC4, netbsd-6-1-RC3, netbsd-6-1-RC2, netbsd-6-1-RC1, netbsd-6-1-5-RELEASE, netbsd-6-1-4-RELEASE, netbsd-6-1-3-RELEASE, netbsd-6-1-2-RELEASE, netbsd-6-1-1-RELEASE, netbsd-6-1, netbsd-6-0-RELEASE, netbsd-6-0-RC2, netbsd-6-0-RC1, netbsd-6-0-6-RELEASE, netbsd-6-0-5-RELEASE, netbsd-6-0-4-RELEASE, netbsd-6-0-3-RELEASE, netbsd-6-0-2-RELEASE, netbsd-6-0-1-RELEASE, netbsd-6-0, netbsd-6, matt-nb6-plus-nbase, matt-nb6-plus-base, matt-nb6-plus, cherry-xenmp-base, cherry-xenmp
Branch point for: yamt-pagecache, tls-maxphys
Changes since 1.7: +42 -3 lines

Add some random, but decent enough, reading material to SEE ALSO.

.\" $NetBSD: security.7,v 1.8 2011/03/30 11:41:48 jruoho Exp $
.\"
.\" Copyright (c) 2006, 2011 Elad Efrat <elad@NetBSD.org>
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. The name of the author may not be used to endorse or promote products
.\"    derived from this software without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd March 30, 2011
.Dt SECURITY 7
.Os
.Sh NAME
.Nm security
.Nd
.Nx
security features
.Sh DESCRIPTION
.Nx
supports a variety of security features.
Below is a brief description of them with some quick usage examples
that will help you get started.
.Pp
Contents:
.Pp
.Bl -hyphen -compact -offset indent
.It
Veriexec
.Pq file integrity
.It
Exploit mitigation
.It
Per-user
.Pa /tmp
directory
.It
Information filtering
.It
Administrative security
.El
.Ss Veriexec
.Em Veriexec
is a file integrity subsystem.
.Pp
For more information about it, and a quick guide on how to use it, please see
.Xr veriexec 8 .
.Pp
In a nutshell, once enabled,
.Em Veriexec
can be started as follows:
.Bd -literal -offset indent
# veriexecgen \*[Am]\*[Am] veriexecctl load
.Ed
.Ss Exploit mitigation
.Nx
incorporates some exploit mitigation features.
The purpose of exploit mitigation features is to interfere
with the way exploits work, in order to prevent them from succeeding.
Due to that, some features may have other impacts on the system, so be sure to
fully understand the implications of each feature.
.Pp
.Nx
provides the following exploit mitigation features:
.Pp
.Bl -hyphen -compact -offset indent
.It
.Tn PaX ASLR
.Pq Address Space Layout Randomization .
.It
.Tn PaX MPROTECT
.Xr ( mprotect 2
restrictions)
.It
.Tn PaX SegvGuard
.It
.Xr gcc 1
stack-smashing protection
.Pq Tn SSP
.It
bounds checked libc functions
.Pq Tn FORTIFY_SOURCE
.It
Protections against
.Dv NULL
pointer dereferences
.El
.Ss PaX ASLR
.Em PaX ASLR
implements Address Space Layout Randomization
.Pq Tn ASLR ,
meant to complement non-executable mappings.
Its purpose is to harden prediction of the address space layout, namely
location of library and application functions that can be used by an attacker
to circumvent non-executable mappings by using a technique called
.Dq return to library
to bypass the need to write new code to (potentially executable) regions of
memory.
.Pp
When
.Em PaX ASLR
is used, it is more likely the attacker will fail to predict the addresses of
such functions, causing the application to segfault.
To detect cases where an attacker might try and brute-force the return address
of respawning services,
.Em PaX Segvguard
can be used (see below).
.Pp
For non-PIE
.Pq Position Independent Executable
executables, the
.Nx
.Em PaX ASLR
implementation introduces randomization to the following memory regions:
.Pp
.Bl -enum -compact -offset indent
.It
The data segment
.It
The stack
.El
.Pp
For
.Tn PIE
executables:
.Pp
.Bl -enum -compact -offset indent
.It
The program itself (exec base)
.It
All shared libraries
.It
The data segment
.It
The stack
.El
.Pp
While it can be enabled globally,
.Nx
provides a tool,
.Xr paxctl 8 ,
to enable
.Em PaX ASLR
on a per-program basis.
.Pp
Example usage:
.Bd -literal -offset indent
# paxctl +A /usr/sbin/sshd
.Ed
.Pp
Enabling
.Em PaX ASLR
globally:
.Bd -literal -offset indent
# sysctl -w security.pax.aslr.global=1
.Ed
.Ss PaX MPROTECT
.Em PaX MPROTECT
implements memory protection restrictions,
meant to complement non-executable mappings.
The purpose is to prevent situations where malicious code attempts to mark
writable memory regions as executable, often by trashing arguments to an
.Xr mprotect 2
call.
.Pp
While it can be enabled globally,
.Nx
provides a tool,
.Xr paxctl 8 ,
to enable
.Em PaX MPROTECT
on a per-program basis.
.Pp
Example usage:
.Bd -literal -offset indent
# paxctl +M /usr/sbin/sshd
.Ed
.Pp
Enabling
.Em PaX MPROTECT
globally:
.Bd -literal -offset indent
# sysctl -w security.pax.mprotect.global=1
.Ed
.Ss PaX Segvguard
.Em PaX Segvguard
monitors the number of segmentation faults in a program on a per-user basis,
in an attempt to detect on-going exploitation attempts and possibly prevent
them.
For instance,
.Em PaX Segvguard
can help detect when an attacker tries to brute-force a function
return address, when attempting to perform a return-to-lib attack.
.Pp
.Em PaX Segvguard
consumes kernel memory, so use it wisely.
While it provides rate-limiting protections, records are tracked for all
users on a per-program basis, meaning that irresponsible use may result in
tracking all segmentation faults in the system, possibly consuming all kernel
memory.
.Pp
For this reason, it is highly recommended to have
.Em PaX Segvguard
enabled explicitly only for network services or
other processes deemed as critical to system security.
Enabling
.Em PaX Segvguard
explicitly works like this:
.Bd -literal -offset indent
# paxctl +G /usr/sbin/sshd
.Ed
.Pp
However, a global knob is still provided, for use in strict environments
with no local users (for example, some network appliances, embedded devices,
and firewalls)
.Bd -literal -offset indent
# sysctl -w security.pax.segvguard.global=1
.Ed
.Pp
Explicitly disabling
.Em PaX Segvguard
is also possible:
.Bd -literal -offset indent
# paxctl +g /bin/ls
.Ed
.Pp
In addition,
.Em PaX Segvguard
provides several tunable options.
For example, to limit a program to 5 segmentation faults from the same user in
a 60 second timeframe:
.Bd -literal -offset indent
# sysctl -w security.pax.segvguard.max_crashes=5
# sysctl -w security.pax.segvguard.expiry_timeout=60
.Ed
.Pp
The number of seconds a user will be suspended from running the culprit
program is also configurable.
For example, 10 minutes seem like a sane setting:
.Bd -literal -offset indent
# sysctl -w security.pax.segvguard.suspend_timeout=600
.Ed
.Ss GCC Stack Smashing Protection ( SSP )
As of
.Nx 4.0 ,
.Xr gcc 1
includes
.Em SSP ,
a set of compiler extensions to raise the bar on exploitation attempts by
detecting corruption of variables and buffer overruns, which may be used to
affect program control flow.
.Pp
Upon detection of a buffer overrun,
.Em SSP
will immediately abort execution of the program and send a log message
to
.Xr syslog 3 .
.Pp
The system (userland and kernel) can be built with
.Em SSP
by using the
.Dq USE_SSP
flag in
.Pa /etc/mk.conf :
.Bd -literal -offset indent
USE_SSP=yes
.Ed
.Pp
You are encouraged to use
.Em SSP
for software you build, by providing one of the
.Fl fstack-protector
or
.Fl fstack-protector-all
flags to
.Xr gcc 1 .
Keep in mind, however, that
.Em SSP
will not work for functions that make use of
.Xr alloca 3 ,
as the latter modifies the stack size during run-time, while
.Em SSP
relies on it being a compile-time static.
.Pp
Use of
.Em SSP
is especially encouraged on platforms without per-page execute bit granularity
such as i386.
As of
.Nx 6.0 ,
.Em SSP
is used by default on i386 and amd64 architectures.
.Ss FORTIFY_SOURCE
The so-called
.Em FORTIFY_SOURCE
is a relatively simple technique to detect a subset of buffer overflows
before these can do damage.
It is integrated to
.Xr gcc 1
together with some common memory and string functions in the standard
C library of
.Nx .
.Pp
The underlying idea builds on the observation that there are cases where
the compiler knows the size of a buffer.
If a buffer overflow is suspected in a function that does little or no
bounds checking, either a compile time warning can be issued or a
safer substitute function can be used at runtime.
Refer to
.Xr ssp 3
for additional details.
.Pp
The
.Em FORTIFY_SOURCE
is enabled by default in some parts of the
.Nx
source tree.
It is also possible to explicitly enable it by defining
the following in
.Xr mk.conf 5 :
.Bd -literal -offset indent
USE_FORT=yes
.Ed
.Ss Protections against NULL pointer dereferences
A certain class of attacks rely on kernel bugs that dereference
.Dv NULL
pointers.
If user processes are allowed to map the virtual address 0 with
.Xr mmap 2
or by other means, there is a risk that code or data
can be injected into the kernel address space.
.Pp
In
.Nx
it is possible to restrict whether user processes are
allowed to make mappings at the zero address.
By default, address 0 mappings are restricted
on the i386 and amd64 architectures.
It is however known that some third-party programs
may not function properly with the restriction.
Such mappings can be allowed either by using the
.Dv USER_VA0_DISABLE_DEFAULT
kernel configuration option or by changing the following variable at runtime:
.Bd -literal -offset indent
# sysctl -w vm.user_va0_disable=0
.Ed
.Pp
Note that if
.Em securelevel
(see
.Xr secmodel_securelevel 9 )
is greater than zero, it is not possible to change the
.Xr sysctl 8
variable.
.Ss Per-user temporary storage
It is possible to configure per-user temporary storage to avoid potential
security issues (race conditions, etc.) in programs that do not make secure
usage of
.Pa /tmp .
.Pp
To enable per-user temporary storage, add the following line to
.Xr rc.conf 5 :
.Bd -literal -offset indent
per_user_tmp=YES
.Ed
.Pp
If
.Pa /tmp
is a mount point, you will also need to update its
.Xr fstab 5
entry to use
.Dq /private/tmp
(or whatever directory you want, if you override the default using the
.Dq per_user_tmp_dir
.Xr rc.conf 5
keyword) instead of
.Dq /tmp .
.Pp
Following that, run:
.Bd -literal -offset indent
# /etc/rc.d/perusertmp start
.Ed
.Pp
The per-user temporary storage is implemented by using
.Dq magic symlinks .
These are further described in
.Xr symlink 7 .
.Ss Information filtering
.Nx
provides administrators the ability to restrict information passed from
the kernel to userland so that users can only view information they
.Dq own .
.Pp
The hooks that manage this restriction are located in various parts of the
system and affect programs such as
.Xr ps 1 ,
.Xr fstat 1 ,
and
.Xr netstat 1 .
Information filtering is enabled as follows:
.Bd -literal -offset indent
# sysctl -w security.curtain=1
.Ed
.Ss Administrative security
Also certain administrative tasks are related to security.
For instance, the daily maintenance script includes some basic
consistency checks; see
.Xr security.conf 5
for more details.
In particular, it is possible to configure
.Nx
to automatically audit all third-party packages installed via
.Xr pkgsrc 7 .
To audit for any known vulnerabilities on daily basis, set the following in
.Fa /etc/daily.conf :
.Bd -literal -offset indent
fetch_pkg_vulnerabilities=YES
.Ed
.Sh SEE ALSO
.Xr ssp 3 ,
.Xr options 4 ,
.Xr paxctl 8 ,
.Xr sysctl 8 ,
.Xr veriexec 8 ,
.Xr kauth 9
.\"
.Rs
.%A Joseph Kong
.%B "Designing BSD Rootkits: An Introduction to Kernel Hacking"
.%D 2007
.%I "No Starch Press"
.Re
.\"
.Rs
.%A Enrico Perla
.%A Massimiliano Oldani
.%B "A Guide to Kernel Exploitation: Attacking the Core"
.%D 2010
.%I "Elsevier"
.Re
.\"
.Rs
.%A Erik Buchanan
.%A Ryan Roemer
.%A Hovav Shacham
.%A Stefan Savage
.%T "When Good Instructions Go Bad: \
Generalizing Return-Oriented Programming to RISC"
.%P 27-38
.%O CCS '08: Proceedings of the 15th ACM Conference \
on Computer and Communications Security
.%I ACM Press
.%D October 27-31, 2008
.%U http://cseweb.ucsd.edu/~hovav/dist/sparc.pdf
.Re
.\"
.Rs
.%A Sebastian Krahmer
.%T "x86-64 Buffer Overflow Exploits and \
the Borrowed Code Chunks Exploitation Technique"
.%D September 28, 2005
.%U http://www.suse.de/~krahmer/no-nx.pdf
.Re
.Sh AUTHORS
Many of the security features were pioneered by
.An Elad Efrat Aq elad@NetBSD.org .