From owner-svn-doc-all@freebsd.org Sun Aug 26 15:56:46 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 421CC1079F0F; Sun, 26 Aug 2018 15:56:46 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE88A8503D; Sun, 26 Aug 2018 15:56:45 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BC45A110F0; Sun, 26 Aug 2018 15:56:45 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7QFuj3v027787; Sun, 26 Aug 2018 15:56:45 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7QFujta027786; Sun, 26 Aug 2018 15:56:45 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201808261556.w7QFujta027786@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Sun, 26 Aug 2018 15:56:45 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52176 - head/en_US.ISO8859-1/books/arch-handbook/jail X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/arch-handbook/jail X-SVN-Commit-Revision: 52176 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 15:56:46 -0000 Author: bcr Date: Sun Aug 26 15:56:45 2018 New Revision: 52176 URL: https://svnweb.freebsd.org/changeset/doc/52176 Log: Clean up some errors that were reported by textproc/igor: - Bad tag indents - Wrap long lines - Two spaces at sentence start Modified: head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml Modified: head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml Sun Aug 26 14:08:19 2018 (r52175) +++ head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml Sun Aug 26 15:56:45 2018 (r52176) @@ -4,53 +4,68 @@ $FreeBSD$ --> - - The Jail Subsystem - EvanSarmiento -
evms@cs.bu.edu
- + + + The Jail Subsystem + + + + Evan + Sarmiento + + +
+ evms@cs.bu.edu +
+ + 2001 Evan Sarmiento - security Jail root - On most &unix; systems, root has omnipotent power. - This promotes insecurity. If an attacker gained root - on a system, he would have every function at his fingertips. In FreeBSD - there are sysctls which dilute the power of root, in - order to minimize the damage caused by an attacker. Specifically, one of - these functions is called secure levels. Similarly, - another function which is present from FreeBSD 4.0 and onward, is a utility - called &man.jail.8;. Jail chroots an environment - and sets certain restrictions on processes which are forked within - the jail. For example, a jailed process - cannot affect processes outside the jail, - utilize certain system calls, or inflict any damage on the host - environment. + On most &unix; systems, root has omnipotent + power. This promotes insecurity. If an attacker gained + root on a system, he would have every function + at his fingertips. In FreeBSD there are sysctls which dilute the + power of root, in order to minimize the damage + caused by an attacker. Specifically, one of these functions is + called secure levels. Similarly, another + function which is present from FreeBSD 4.0 and onward, is a + utility called &man.jail.8;. Jail + chroots an environment and sets certain restrictions on processes + which are forked within the jail. For + example, a jailed process cannot affect processes outside the + jail, utilize certain system calls, or + inflict any damage on the host environment. Jail is becoming the new security - model. People are running potentially vulnerable servers such as - Apache, BIND, and - sendmail within jails, so that if an attacker - gains root within the jail, - it is only an annoyance, and not a devastation. This article mainly - focuses on the internals (source code) of jail. - For information on how to set up a jail see the handbook entry on jails. + model. People are running potentially vulnerable servers such as + Apache, + BIND, and + sendmail within jails, so that if an + attacker gains root within the + jail, it is only an annoyance, and not + a devastation. This article mainly focuses on the internals + (source code) of jail. For information + on how to set up a jail see the handbook entry on + jails. Architecture - - Jail consists of two realms: the + Jail consists of two realms: the userland program, &man.jail.8;, and the code implemented within the kernel: the &man.jail.2; system call and associated - restrictions. I will be discussing the userland program and + restrictions. I will be discussing the userland program and then how jail is implemented within the kernel. @@ -60,24 +75,25 @@ Jail Userland Program - The source for the userland jail - is located in /usr/src/usr.sbin/jail, - consisting of one file, jail.c. The program - takes these arguments: the path of the jail, - hostname, IP address, and the command to be executed. + The source for the userland + jail is located in + /usr/src/usr.sbin/jail, consisting of one + file, jail.c. The program takes these + arguments: the path of the jail, + hostname, IP address, and the command to be executed. - Data Structures + Data Structures - In jail.c, the first thing I would - note is the declaration of an important structure - struct jail j; which was included from - /usr/include/sys/jail.h. + In jail.c, the first thing I would + note is the declaration of an important structure + struct jail j; which was included from + /usr/include/sys/jail.h. - The definition of the jail structure is: - + The definition of the jail structure + is: -/usr/include/sys/jail.h: + /usr/include/sys/jail.h: struct jail { u_int32_t version; @@ -86,11 +102,11 @@ struct jail { u_int32_t ip_number; }; - As you can see, there is an entry for each of the - arguments passed to the &man.jail.8; program, and indeed, - they are set during its execution. + As you can see, there is an entry for each of the + arguments passed to the &man.jail.8; program, and indeed, + they are set during its execution. - /usr/src/usr.sbin/jail/jail.c + /usr/src/usr.sbin/jail/jail.c char path[PATH_MAX]; ... if (realpath(argv[0], path) == NULL) @@ -101,54 +117,55 @@ memset(&j, 0, sizeof(j)); j.version = 0; j.path = path; j.hostname = argv[1]; - - Networking + Networking - One of the arguments passed to the &man.jail.8; program is - an IP address with which the jail - can be accessed over the network. &man.jail.8; translates the - IP address given into host byte order and then stores it in - j (the jail structure). + One of the arguments passed to the &man.jail.8; program + is an IP address with which the + jail can be accessed over the + network. &man.jail.8; translates the IP address given into + host byte order and then stores it in j + (the jail structure). - /usr/src/usr.sbin/jail/jail.c: + /usr/src/usr.sbin/jail/jail.c: struct in_addr in; ... if (inet_aton(argv[2], &in) == 0) errx(1, "Could not make sense of ip-number: %s", argv[2]); j.ip_number = ntohl(in.s_addr); - The &man.inet.aton.3; function "interprets the specified - character string as an Internet address, placing the address - into the structure provided." The ip_number - member in the jail structure is set only - when the IP address placed onto the in - structure by &man.inet.aton.3; is translated into host byte - order by &man.ntohl.3;. - + The &man.inet.aton.3; function "interprets the specified + character string as an Internet address, placing the address + into the structure provided." The + ip_number member in the + jail structure is set only when the IP + address placed onto the in structure by + &man.inet.aton.3; is translated into host byte order by + &man.ntohl.3;. - Jailing the Process + Jailing the Process - Finally, the userland program jails the process. - Jail now becomes an imprisoned - process itself and then executes the command given using - &man.execv.3;. - /usr/src/usr.sbin/jail/jail.c + Finally, the userland program jails the process. + Jail now becomes an imprisoned + process itself and then executes the command given using + &man.execv.3;. + + /usr/src/usr.sbin/jail/jail.c i = jail(&j); ... if (execv(argv[3], argv + 3) != 0) err(1, "execv: %s", argv[3]); - As you can see, the jail() function is - called, and its argument is the jail structure - which has been filled with the arguments given to the program. - Finally, the program you specify is executed. I will now discuss - how jail is implemented within the - kernel. + As you can see, the jail() function + is called, and its argument is the jail + structure which has been filled with the arguments given to + the program. Finally, the program you specify is executed. + I will now discuss how jail is + implemented within the kernel. @@ -159,20 +176,19 @@ if (execv(argv[3], argv + 3) != 0) Kernel Architecture We will now be looking at the file - /usr/src/sys/kern/kern_jail.c. This is - the file where the &man.jail.2; system call, appropriate sysctls, - and networking functions are defined. + /usr/src/sys/kern/kern_jail.c. This is + the file where the &man.jail.2; system call, appropriate + sysctls, and networking functions are defined. - sysctls + Sysctls - sysctl + sysctl - In kern_jail.c, the following - sysctls are defined: + In kern_jail.c, the following + sysctls are defined: - /usr/src/sys/kern/kern_jail.c: - + /usr/src/sys/kern/kern_jail.c: int jail_set_hostname_allowed = 1; SYSCTL_INT(_security_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW, &jail_set_hostname_allowed, 0, @@ -208,29 +224,30 @@ SYSCTL_INT(_security_jail, OID_AUTO, mount_allowed, CT &jail_mount_allowed, 0, "Processes in jail can mount/unmount jail-friendly file systems"); - Each of these sysctls can be accessed by the user - through the &man.sysctl.8; program. Throughout the kernel, these - specific sysctls are recognized by their name. For example, - the name of the first sysctl is - security.jail.set_hostname_allowed. + Each of these sysctls can be accessed by the user + through the &man.sysctl.8; program. Throughout the kernel, + these specific sysctls are recognized by their name. For + example, the name of the first sysctl is + security.jail.set_hostname_allowed. - &man.jail.2; System Call + &man.jail.2; System Call - Like all system calls, the &man.jail.2; system call takes - two arguments, struct thread *td and - struct jail_args *uap. - td is a pointer to the thread - structure which describes the calling thread. In this - context, uap is a pointer to the structure - in which a pointer to the jail structure - passed by the userland jail.c is contained. - When I described the userland program before, you saw that the - &man.jail.2; system call was given a jail - structure as its own argument. + Like all system calls, the &man.jail.2; system call + takes two arguments, struct thread *td + and struct jail_args *uap. + td is a pointer to the + thread structure which describes the + calling thread. In this context, uap is + a pointer to the structure in which a pointer to the + jail structure passed by the userland + jail.c is contained. When I described + the userland program before, you saw that the &man.jail.2; + system call was given a jail structure as + its own argument. - /usr/src/sys/kern/kern_jail.c: + /usr/src/sys/kern/kern_jail.c: /* * struct jail_args { * struct jail *jail; @@ -239,29 +256,30 @@ SYSCTL_INT(_security_jail, OID_AUTO, mount_allowed, CT int jail(struct thread *td, struct jail_args *uap) - Therefore, uap->jail can be used to - access the jail structure which was passed - to the system call. Next, the system call copies the - jail structure into kernel space using - the &man.copyin.9; function. &man.copyin.9; takes three arguments: - the address of the data which is to be copied into kernel space, - uap->jail, where to store it, - j and the size of the storage. The - jail structure pointed by - uap->jail is copied into kernel space and - is stored in another jail structure, - j. + Therefore, uap->jail can be used + to access the jail structure which was + passed to the system call. Next, the system call copies the + jail structure into kernel space using + the &man.copyin.9; function. &man.copyin.9; takes three + arguments: the address of the data which is to be copied + into kernel space, uap->jail, where to + store it, j and the size of the storage. + The jail structure pointed by + uap->jail is copied into kernel space + and is stored in another jail structure, + j. - /usr/src/sys/kern/kern_jail.c: + /usr/src/sys/kern/kern_jail.c: error = copyin(uap->jail, &j, sizeof(j)); - There is another important structure defined in - jail.h. It is the prison - structure. The prison structure is used - exclusively within kernel space. Here is the definition of the - prison structure. + There is another important structure defined in + jail.h. It is the + prison structure. The + prison structure is used exclusively + within kernel space. Here is the definition of the + prison structure. - /usr/include/sys/jail.h: + /usr/include/sys/jail.h: struct prison { LIST_ENTRY(prison) pr_list; /* (a) all prisons */ int pr_id; /* (c) prison id */ @@ -277,12 +295,12 @@ struct prison { void **pr_slots; /* (p) additional data */ }; - The &man.jail.2; system call then allocates memory for - a prison structure and copies data between - the jail and prison - structure. + The &man.jail.2; system call then allocates memory for a + prison structure and copies data between + the jail and prison + structure. - /usr/src/sys/kern/kern_jail.c: + /usr/src/sys/kern/kern_jail.c: MALLOC(pr, struct prison *, sizeof(*pr), M_PRISON, M_WAITOK | M_ZERO); ... error = copyinstr(j.path, &pr->pr_path, sizeof(pr->pr_path), 0); @@ -293,10 +311,12 @@ error = copyinstr(j.hostname, &pr->pr_host, siz if (error) goto e_dropvnref; pr->pr_ip = j.ip_number; - Next, we will discuss another important system call - &man.jail.attach.2;, which implements the function to put - a process into the jail. - /usr/src/sys/kern/kern_jail.c: + + Next, we will discuss another important system call + &man.jail.attach.2;, which implements the function to put a + process into the jail. + + /usr/src/sys/kern/kern_jail.c: /* * struct jail_attach_args { * int jid; @@ -304,34 +324,37 @@ pr->pr_ip = j.ip_number; */ int jail_attach(struct thread *td, struct jail_attach_args *uap) - This system call makes the changes that can distinguish - a jailed process from those unjailed ones. - To understand what &man.jail.attach.2; does for us, certain - background information is needed. - - On FreeBSD, each kernel visible thread is identified by its - thread structure, while the processes are - described by their proc structures. You can - find the definitions of the thread and - proc structure in - /usr/include/sys/proc.h. - For example, the td argument in any system - call is actually a pointer to the calling thread's - thread structure, as stated before. - The td_proc member in the - thread structure pointed by td - is a pointer to the proc structure which - represents the process that contains the thread represented by - td. The proc structure - contains members which can describe the owner's - identity(p_ucred), the process resource - limits(p_limit), and so on. In the - ucred structure pointed by - p_ucred member in the proc - structure, there is a pointer to the prison - structure(cr_prison). - /usr/include/sys/proc.h: + This system call makes the changes that can distinguish + a jailed process from those unjailed ones. To understand + what &man.jail.attach.2; does for us, certain background + information is needed. + + On FreeBSD, each kernel visible thread is identified by + its thread structure, while the processes + are described by their proc structures. + You can find the definitions of the + thread and proc + structure in /usr/include/sys/proc.h. + For example, the td argument in any + system call is actually a pointer to the calling thread's + thread structure, as stated before. The + td_proc member in the + thread structure pointed by + td is a pointer to the + proc structure which represents the + process that contains the thread represented by + td. The proc + structure contains members which can describe the owner's + identity(p_ucred), the process resource + limits(p_limit), and so on. In the + ucred structure pointed by + p_ucred member in the + proc structure, there is a pointer to the + prison + structure(cr_prison). + + /usr/include/sys/proc.h: struct thread { ... struct proc *td_proc; @@ -349,29 +372,33 @@ struct ucred { ... }; - In kern_jail.c, the function - jail() then calls function - jail_attach() with a given jid. - And jail_attach() calls function - change_root() to change the root directory of the - calling process. The jail_attach() then creates - a new ucred structure, and attaches the newly - created ucred structure to the calling process - after it has successfully attached the prison - structure to the ucred structure. From then on, - the calling process is recognized as jailed. When the kernel routine - jailed() is called in the kernel with the newly - created ucred structure as its argument, it - returns 1 to tell that the credential is connected - with a jail. The public ancestor process - of all the process forked within the jail, - is the process which runs &man.jail.8;, as it calls the - &man.jail.2; system call. When a program is executed through - &man.execve.2;, it inherits the jailed property of its parent's - ucred structure, therefore it has a jailed - ucred structure. + In kern_jail.c, the function + jail() then calls function + jail_attach() with a given + jid. And + jail_attach() calls function + change_root() to change the root + directory of the calling process. The + jail_attach() then creates a new + ucred structure, and attaches the newly + created ucred structure to the calling + process after it has successfully attached the + prison structure to the + ucred structure. From then on, the + calling process is recognized as jailed. When the kernel + routine jailed() is called in the kernel + with the newly created ucred structure as + its argument, it returns 1 to tell that the credential is + connected with a jail. The + public ancestor process of all the process forked within the + jail, is the process which runs + &man.jail.8;, as it calls the &man.jail.2; system call. + When a program is executed through &man.execve.2;, it + inherits the jailed property of its parent's + ucred structure, therefore it has a + jailed ucred structure. - /usr/src/sys/kern/kern_jail.c + /usr/src/sys/kern/kern_jail.c int jail(struct thread *td, struct jail_args *uap) { @@ -401,17 +428,18 @@ jail_attach(struct thread *td, struct jail_attach_args p->p_ucred = newcred; ... } - When a process is forked from its parent process, the - &man.fork.2; system call uses crhold() to - maintain the credential for the newly forked process. It inherently - keep the newly forked child's credential consistent with its parent, - so the child process is also jailed. - /usr/src/sys/kern/kern_fork.c: + When a process is forked from its parent process, the + &man.fork.2; system call uses crhold() to + maintain the credential for the newly forked process. It + inherently keep the newly forked child's credential + consistent with its parent, so the child process is also + jailed. + + /usr/src/sys/kern/kern_fork.c: p2->p_ucred = crhold(td->td_ucred); ... td2->td_ucred = crhold(p2->p_ucred); - @@ -420,12 +448,11 @@ td2->td_ucred = crhold(p2->p_ucred);Restrictions Throughout the kernel there are access restrictions relating - to jailed processes. Usually, these restrictions only check whether - the process is jailed, and if so, returns an error. For + to jailed processes. Usually, these restrictions only check + whether the process is jailed, and if so, returns an error. For example: - -if (jailed(td->td_ucred)) + if (jailed(td->td_ucred)) return (EPERM); @@ -433,112 +460,128 @@ if (jailed(td->td_ucred)) System V IPC - 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: - &man.msgctl.3;, &man.msgget.3;, &man.msgsnd.3; and &man.msgrcv.3;. - Earlier, I mentioned that there were certain sysctls you could - turn on or off in order to affect the behavior of - jail. One of these sysctls was - security.jail.sysvipc_allowed. By default, - this sysctl is set to 0. If it were set to 1, it would defeat the - whole purpose of having a jail; privileged - users from the jail would be able to - affect processes outside the jailed environment. The difference - between a message and a signal is that the message only consists - of the signal number. + 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: &man.msgctl.3;, + &man.msgget.3;, &man.msgsnd.3; and &man.msgrcv.3;. Earlier, I + mentioned that there were certain sysctls you could turn on or + off in order to affect the behavior of + jail. One of these sysctls was + security.jail.sysvipc_allowed. By default, + this sysctl is set to 0. If it were set to 1, it would defeat + the whole purpose of having a jail; + privileged users from the jail + would be able to affect processes outside the jailed + environment. The difference between a message and a signal is + that the message only consists of the signal number. /usr/src/sys/kern/sysv_msg.c: - msgget(key, msgflg): - msgget returns (and possibly creates) a message - descriptor that designates a message queue for use in other - functions. + + msgget(key, msgflg): + msgget returns (and possibly creates) a + message descriptor that designates a message queue for use + in other functions. + - msgctl(msgid, cmd, buf): - Using this function, a process can query the status of a message - descriptor. + + msgctl(msgid, cmd, buf): Using this + function, a process can query the status of a message + descriptor. + - msgsnd(msgid, msgp, msgsz, msgflg): - msgsnd sends a message to a - process. + + msgsnd(msgid, msgp, msgsz, msgflg): + msgsnd sends a message to a + process. + - msgrcv(msgid, msgp, msgsz, msgtyp, - msgflg): a process receives messages using - this function - + + msgrcv(msgid, msgp, msgsz, msgtyp, + msgflg): a process receives messages using + this function + - In each of the system calls corresponding to these functions, - there is this conditional: + In each of the system calls corresponding to these + functions, there is this conditional: /usr/src/sys/kern/sysv_msg.c: if (!jail_sysvipc_allowed && jailed(td->td_ucred)) return (ENOSYS); semaphores + 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 - processes lock resources. However, process waiting on a - semaphore, that is being used, will sleep until the resources - are relinquished. The following semaphore system calls are - blocked inside a jail: &man.semget.2;, - &man.semctl.2; and &man.semop.2;. + execution by doing a set of operations atomically on a set of + semaphores. Basically semaphores provide another way for + processes lock resources. However, process waiting on a + semaphore, that is being used, will sleep until the resources + are relinquished. The following semaphore system calls are + blocked inside a jail: + &man.semget.2;, &man.semctl.2; and &man.semop.2;. /usr/src/sys/kern/sysv_sem.c: - - semctl(semid, semnum, cmd, ...): - semctl does the specified cmd - on the semaphore queue indicated by - semid. + + semctl(semid, semnum, cmd, ...): + semctl does the specified + cmd on the semaphore queue indicated by + semid. - - semget(key, nsems, flag): - semget creates an array of semaphores, - corresponding to key. + + semget(key, nsems, flag): + semget creates an array of semaphores, + corresponding to key. - key and flag take on the same meaning as they - do in msgget. + key and flag take on the same meaning as they + do in msgget. + - semop(semid, array, nops): - semop performs a group of operations indicated - by array, to the set of semaphores identified by - semid. + semop(semid, array, nops): + semop performs a group of operations + indicated by array, to the set of + semaphores identified by + semid. shared memory - 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 - and writing data stored in the shared memory. These system - calls are blocked within a jailed environment: &man.shmdt.2;, - &man.shmat.2;, &man.shmctl.2; and &man.shmget.2;. + 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 and + writing data stored in the shared memory. These system calls + are blocked within a jailed environment: &man.shmdt.2;, + &man.shmat.2;, &man.shmctl.2; and &man.shmget.2;. + /usr/src/sys/kern/sysv_shm.c: - shmctl(shmid, cmd, buf): - shmctl does various control operations on the - shared memory region identified by - shmid. + shmctl(shmid, cmd, buf): + shmctl does various control operations + on the shared memory region identified by + shmid. + - shmget(key, size, flag): - shmget accesses or creates a shared memory - region of size bytes. + shmget(key, size, flag): + shmget accesses or creates a shared + memory region of size + bytes. + - shmat(shmid, addr, flag): - shmat attaches a shared memory region identified - by shmid to the address space of a - process. + shmat(shmid, addr, flag): + shmat attaches a shared memory region + identified by shmid to the address + space of a process. + - shmdt(addr): - shmdt detaches the shared memory region - previously attached at addr. - + shmdt(addr): + shmdt detaches the shared memory region + previously attached at + addr. + @@ -546,17 +589,18 @@ if (!jail_sysvipc_allowed && jailed(td->td_ Sockets sockets - 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, it first checks to see if the sysctl - security.jail.socket_unixiproute_only is set. If - set, sockets are only allowed to be created if the family - specified is either PF_LOCAL, - PF_INET or - PF_ROUTE. Otherwise, it returns an - error. + 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, it first checks to see if the + sysctl + security.jail.socket_unixiproute_only is + set. If set, sockets are only allowed to be created if the + family specified is either PF_LOCAL, + PF_INET or PF_ROUTE. + Otherwise, it returns an error. + /usr/src/sys/kern/uipc_socket.c: int socreate(int dom, struct socket **aso, int type, int proto, @@ -572,7 +616,6 @@ socreate(int dom, struct socket **aso, int type, int p } ... } - @@ -581,10 +624,11 @@ socreate(int dom, struct socket **aso, int type, int p Berkeley Packet Filter data link layer - The Berkeley Packet Filter provides - a raw interface to data link layers in a protocol independent - fashion. BPF is now controlled by the - &man.devfs.8; whether it can be used in a jailed environment. + The Berkeley Packet Filter + provides a raw interface to data link layers in a protocol + independent fashion. BPF is now + controlled by the &man.devfs.8; whether it can be used in a + jailed environment. @@ -594,23 +638,25 @@ socreate(int dom, struct socket **aso, int type, int p protocols 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 - taken in order to prevent a jailed process from binding a - protocol to a certain address only if the nam - parameter is set. nam is a pointer to a - sockaddr structure, - which describes the address on which to bind the service. A - more exact definition is that sockaddr "may be - used as a template for referring to the identifying tag and length of - each address". In the function - in_pcbbind_setup(), sin is a - pointer to a sockaddr_in structure, which - contains the port, address, length and domain family of the socket - which is to be bound. Basically, this disallows any processes from - jail to be able to specify the address - that does not belong to the jail in which - the calling process exists. + TCP, UDP, IP and ICMP. IP and ICMP are on the same level: the + network layer 2. There are certain precautions which are + taken in order to prevent a jailed process from binding a + protocol to a certain address only if the + nam parameter is set. + nam is a pointer to a + sockaddr structure, which describes the + address on which to bind the service. A more exact definition + is that sockaddr "may be used as a template + for referring to the identifying tag and length of each + address". In the function + in_pcbbind_setup(), sin + is a pointer to a sockaddr_in structure, + which contains the port, address, length and domain family of + the socket which is to be bound. Basically, this disallows + any processes from jail to be able + to specify the address that does not belong to the + jail in which the calling process + exists. /usr/src/sys/netinet/in_pcb.c: int @@ -648,14 +694,15 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *n } You might be wondering what function - prison_ip() does. prison_ip() - is given three arguments, a pointer to the credential(represented by - cred), any flags, and an IP address. It - returns 1 if the IP address does NOT belong to the - jail or 0 otherwise. As you can see - from the code, if it is indeed an IP address not belonging to the - jail, the protocol is not allowed to bind - to that address. + prison_ip() does. + prison_ip() is given three arguments, a + pointer to the credential(represented by + cred), any flags, and an IP address. It + returns 1 if the IP address does NOT belong to the + jail or 0 otherwise. As you can + see from the code, if it is indeed an IP address not belonging + to the jail, the protocol is not + allowed to bind to that address. /usr/src/sys/kern/kern_jail.c: int @@ -693,10 +740,12 @@ prison_ip(struct ucred *cred, int flag, u_int32_t *ip) Filesystem filesystem + Even root users within the - jail are not allowed to unset or modify - any file flags, such as immutable, append-only, and undeleteable - flags, if the securelevel is greater than 0. + jail are not allowed to unset or + modify any file flags, such as immutable, append-only, and + undeleteable flags, if the securelevel is greater than + 0. /usr/src/sys/ufs/ufs/ufs_vnops.c: static int @@ -741,7 +790,5 @@ prison_priv_check(struct ucred *cred, int priv) ... } - -