Index three more chapters.
This commit is contained in:
Murray Stokely
parent
ed547c75df
commit
0c07041d1a
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=24446
3 changed files with 69 additions and 1 deletions
|
|
@ -20,6 +20,10 @@
|
|||
</chapterinfo>
|
||||
<title>The Jail Subsystem</title>
|
||||
|
||||
<indexterm><primary>security</primary></indexterm>
|
||||
<indexterm><primary>Jail</primary></indexterm>
|
||||
<indexterm><primary>root</primary></indexterm>
|
||||
|
||||
<para>On most UNIX systems, root has omnipotent power. This promotes
|
||||
insecurity. If an attacker were to gain root on a system, he would
|
||||
have every function at his fingertips. In FreeBSD there are
|
||||
|
|
@ -58,6 +62,9 @@
|
|||
<sect2>
|
||||
<title>Userland code</title>
|
||||
|
||||
<indexterm><primary>Jail</primary>
|
||||
<secondary>userland program</secondary></indexterm>
|
||||
|
||||
<para>The source for the user-land jail is located in
|
||||
<filename>/usr/src/usr.sbin/jail</filename>, consisting of
|
||||
one file, <filename>jail.c</filename>. The program takes these
|
||||
|
|
@ -144,6 +151,9 @@ i = execv(argv[4], argv + 4);</programlisting>
|
|||
<sect2>
|
||||
<title>Kernel Space</title>
|
||||
|
||||
<indexterm><primary>Jail</primary>
|
||||
<secondary>kernel architecture</secondary></indexterm>
|
||||
|
||||
<para>We will now be looking at the file
|
||||
<filename>/usr/src/sys/kern/kern_jail.c</filename>. This is
|
||||
the file where the jail system call, appropriate sysctls, and
|
||||
|
|
@ -152,6 +162,8 @@ i = execv(argv[4], argv + 4);</programlisting>
|
|||
<sect3>
|
||||
<title>sysctls</title>
|
||||
|
||||
<indexterm><primary>sysctl</primary></indexterm>
|
||||
|
||||
<para>In <filename>kern_jail.c</filename>, the following
|
||||
sysctls are defined:</para>
|
||||
|
||||
|
|
@ -243,6 +255,8 @@ struct prison {
|
|||
if (error)
|
||||
goto bail;</programlisting>
|
||||
|
||||
<indexterm><primary>chroot</primary></indexterm>
|
||||
|
||||
<para>Finally, the jail system call chroots the path
|
||||
specified. The chroot function is given two arguments. The
|
||||
first is p, which represents the calling process, the second
|
||||
|
|
@ -331,6 +345,8 @@ if (p2->p_prison) {
|
|||
<sect2>
|
||||
<title>SysV IPC</title>
|
||||
|
||||
<indexterm><primary>System V IPC</primary></indexterm>
|
||||
|
||||
<para>System V IPC is based on messages. Processes can send each
|
||||
other these messages which tell them how to act. The functions
|
||||
which deal with messages are: <literal>msgsys</literal>,
|
||||
|
|
@ -372,6 +388,7 @@ if (p2->p_prison) {
|
|||
if (!jail.sysvipc.allowed && p->p_prison != NULL)
|
||||
return (ENOSYS);</programlisting>
|
||||
|
||||
<indexterm><primary>semaphores</primary></indexterm>
|
||||
<para>Semaphore system calls allow processes to synchronize
|
||||
execution by doing a set of operations atomically on a set of
|
||||
semaphores. Basically semaphores provide another way for
|
||||
|
|
@ -404,6 +421,7 @@ if (!jail.sysvipc.allowed && p->p_prison != NULL)
|
|||
id.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<indexterm><primary>shared memory</primary></indexterm>
|
||||
<para>System V IPC allows for processes to share
|
||||
memory. Processes can communicate directly with each other by
|
||||
sharing parts of their virtual address space and then reading
|
||||
|
|
@ -437,6 +455,7 @@ if (!jail.sysvipc.allowed && p->p_prison != NULL)
|
|||
<sect2>
|
||||
<title>Sockets</title>
|
||||
|
||||
<indexterm><primary>sockets</primary></indexterm>
|
||||
<para>Jail treats the &man.socket.2; system call and related
|
||||
lower-level socket functions in a special manner. In order to
|
||||
determine whether a certain socket is allowed to be created,
|
||||
|
|
@ -466,6 +485,9 @@ register struct protosw *prp;
|
|||
<sect2>
|
||||
<title>Berkeley Packet Filter</title>
|
||||
|
||||
<indexterm><primary>Berkeley Packet Filter</primary></indexterm>
|
||||
<indexterm><primary>data link layer</primary></indexterm>
|
||||
|
||||
<para>The Berkeley Packet Filter provides a raw interface to
|
||||
data link layers in a protocol independent fashion. The
|
||||
function <literal>bpfopen()</literal> opens an Ethernet
|
||||
|
|
@ -486,6 +508,8 @@ static int bpfopen(dev, flags, fmt, p)
|
|||
<sect2>
|
||||
<title>Protocols</title>
|
||||
|
||||
<indexterm><primary>protocols</primary></indexterm>
|
||||
|
||||
<para>There are certain protocols which are very common, such as
|
||||
TCP, UDP, IP and ICMP. IP and ICMP are on the same level: the
|
||||
network layer 2. There are certain precautions which are
|
||||
|
|
@ -574,6 +598,7 @@ int prison_ip(struct proc *p, int flag, u_int32_t *ip) {
|
|||
<sect2>
|
||||
<title>Filesystem</title>
|
||||
|
||||
<indexterm><primary>filesystem</primary></indexterm>
|
||||
<para>Even root users within the jail are not allowed to set any
|
||||
file flags, such as immutable, append, and no unlink flags, if
|
||||
the securelevel is greater than 0.</para>
|
||||
|
|
|
|||
|
|
@ -7,6 +7,9 @@
|
|||
<chapter id="kernel-objects">
|
||||
<title>Kernel Objects</title>
|
||||
|
||||
<indexterm><primary>Kernel Objects</primary></indexterm>
|
||||
<indexterm><primary>Object-Oriented</primary></indexterm>
|
||||
<indexterm><primary>binary compatibility</primary></indexterm>
|
||||
<para>Kernel Objects, or <firstterm>Kobj</firstterm> provides an
|
||||
object-oriented C programming system for the kernel. As such the
|
||||
data being operated on carries the description of how to operate
|
||||
|
|
@ -17,6 +20,11 @@
|
|||
<sect1 id="kernel-objects-term">
|
||||
<title>Terminology</title>
|
||||
|
||||
<indexterm><primary>object</primary></indexterm>
|
||||
<indexterm><primary>method</primary></indexterm>
|
||||
<indexterm><primary>class</primary></indexterm>
|
||||
<indexterm><primary>interface</primary></indexterm>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Object</term>
|
||||
|
|
@ -116,6 +124,9 @@ KOBJMETHOD(NAME, FUNC)</programlisting>
|
|||
<sect2>
|
||||
<title>Creating an interface template</title>
|
||||
|
||||
<indexterm><primary>Kernel Objects</primary>
|
||||
<secondary>interface</secondary></indexterm>
|
||||
|
||||
<para>The first step in using Kobj is to create an
|
||||
Interface. Creating the interface involves creating a template
|
||||
that the script
|
||||
|
|
@ -204,6 +215,9 @@ src/sys/kern/device_if.m</programlisting>
|
|||
<sect2>
|
||||
<title>Creating a Class</title>
|
||||
|
||||
<indexterm><primary>Kernel Objects</primary>
|
||||
<secondary>class</secondary></indexterm>
|
||||
|
||||
<para>The second step in using Kobj is to create a class. A
|
||||
class consists of a name, a table of methods, and the size of
|
||||
objects if Kobj's object handling facilities are used. To
|
||||
|
|
@ -235,6 +249,9 @@ kobj_method_t foomethods[] = {
|
|||
<sect2>
|
||||
<title>Creating an Object</title>
|
||||
|
||||
<indexterm><primary>Kernel Objects</primary>
|
||||
<secondary>object</secondary></indexterm>
|
||||
|
||||
<para>The third step in using Kobj involves how to define the
|
||||
object. Kobj object creation routines assume that Kobj data is
|
||||
at the head of an object. If this in not appropriate you will
|
||||
|
|
|
|||
|
|
@ -8,11 +8,17 @@
|
|||
<chapter id="locking">
|
||||
<title>Locking Notes</title>
|
||||
|
||||
<indexterm><primary>SMP Next Generation Project</primary></indexterm>
|
||||
<para><emphasis>This chapter is maintained by the FreeBSD SMP Next
|
||||
Generation Project. Please direct any comments or suggestions
|
||||
to its &a.smp;.</emphasis></para>
|
||||
|
||||
|
||||
<indexterm><primary>locking</primary></indexterm>
|
||||
<indexterm><primary>multi-processing</primary></indexterm>
|
||||
<indexterm><primary>mutexes</primary></indexterm>
|
||||
<indexterm><primary>lockmgr</primary></indexterm>
|
||||
<indexterm><primary>atomic operations</primary></indexterm>
|
||||
<para>This document outlines the locking used in the FreeBSD kernel
|
||||
to permit effective multi-processing within the kernel. Locking
|
||||
can be achieved via several means. Data structures can be
|
||||
|
|
@ -109,7 +115,19 @@
|
|||
|
||||
<table frame="all" colsep="1" rowsep="1" pgwide="1">
|
||||
<title>Mutex List</title>
|
||||
|
||||
|
||||
<indexterm><primary>locks</primary>
|
||||
<secondary>sched_lock</secondary></indexterm>
|
||||
|
||||
<indexterm><primary>locks</primary>
|
||||
<secondary>vm86pcb_lock</secondary></indexterm>
|
||||
|
||||
<indexterm><primary>locks</primary>
|
||||
<secondary>Giant</secondary></indexterm>
|
||||
|
||||
<indexterm><primary>locks</primary>
|
||||
<secondary>callout_lock</secondary></indexterm>
|
||||
|
||||
<tgroup cols="5">
|
||||
<thead>
|
||||
<row>
|
||||
|
|
@ -260,9 +278,15 @@
|
|||
<para>These locks provide basic reader-writer type functionality
|
||||
and may be held by a sleeping process. Currently they are
|
||||
backed by &man.lockmgr.9;.</para>
|
||||
<indexterm><primary>locks</primary>
|
||||
<secondary>shared exclusive</secondary></indexterm>
|
||||
|
||||
<table>
|
||||
<title>Shared Exclusive Lock List</title>
|
||||
<indexterm><primary>locks</primary>
|
||||
<secondary>allproc_lock</secondary></indexterm>
|
||||
<indexterm><primary>locks</primary>
|
||||
<secondary>proctree_lock</secondary></indexterm>
|
||||
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
|
|
@ -298,6 +322,8 @@
|
|||
<sect1 id="locking-atomic">
|
||||
<title>Atomically Protected Variables</title>
|
||||
|
||||
<indexterm><primary>atomically protected variables</primary></indexterm>
|
||||
|
||||
<para>An atomically protected variable is a special variable that
|
||||
is not protected by an explicit lock. Instead, all data
|
||||
accesses to the variables use special atomic operations as
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue