2005-01-06 23:35:40 +00:00
|
|
|
/*-
|
1999-04-30 06:51:51 +00:00
|
|
|
* ----------------------------------------------------------------------------
|
|
|
|
|
* "THE BEER-WARE LICENSE" (Revision 42):
|
|
|
|
|
* <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
|
|
|
|
|
* can do whatever you want with this stuff. If we meet some day, and you think
|
|
|
|
|
* this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
|
|
|
|
|
* ----------------------------------------------------------------------------
|
|
|
|
|
*/
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
|
2003-06-11 00:56:59 +00:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
|
2004-06-27 09:03:22 +00:00
|
|
|
#include "opt_mac.h"
|
|
|
|
|
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
|
#include <sys/systm.h>
|
|
|
|
|
#include <sys/errno.h>
|
|
|
|
|
#include <sys/sysproto.h>
|
|
|
|
|
#include <sys/malloc.h>
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
#include <sys/priv.h>
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
#include <sys/proc.h>
|
2004-01-23 20:44:26 +00:00
|
|
|
#include <sys/taskqueue.h>
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
#include <sys/jail.h>
|
o Introduce pr_mtx into struct prison, providing protection for the
mutable contents of struct prison (hostname, securelevel, refcount,
pr_linux, ...)
o Generally introduce mtx_lock()/mtx_unlock() calls throughout kern/
so as to enforce these protections, in particular, in kern_mib.c
protection sysctl access to the hostname and securelevel, as well as
kern_prot.c access to the securelevel for access control purposes.
o Rewrite linux emulator abstractions for accessing per-jail linux
mib entries (osname, osrelease, osversion) so that they don't return
a pointer to the text in the struct linux_prison, rather, a copy
to an array passed into the calls. Likewise, update linprocfs to
use these primitives.
o Update in_pcb.c to always use prison_getip() rather than directly
accessing struct prison.
Reviewed by: jhb
2001-12-03 16:12:27 +00:00
|
|
|
#include <sys/lock.h>
|
|
|
|
|
#include <sys/mutex.h>
|
2007-04-05 23:19:13 +00:00
|
|
|
#include <sys/sx.h>
|
2003-04-09 02:55:18 +00:00
|
|
|
#include <sys/namei.h>
|
2005-06-09 18:49:19 +00:00
|
|
|
#include <sys/mount.h>
|
2003-04-09 02:55:18 +00:00
|
|
|
#include <sys/queue.h>
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
#include <sys/socket.h>
|
2003-04-09 02:55:18 +00:00
|
|
|
#include <sys/syscallsubr.h>
|
2000-02-12 13:41:56 +00:00
|
|
|
#include <sys/sysctl.h>
|
2003-04-09 02:55:18 +00:00
|
|
|
#include <sys/vnode.h>
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
#include <net/if.h>
|
|
|
|
|
#include <netinet/in.h>
|
|
|
|
|
|
2006-10-22 11:52:19 +00:00
|
|
|
#include <security/mac/mac_framework.h>
|
|
|
|
|
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
MALLOC_DEFINE(M_PRISON, "prison", "Prison structures");
|
|
|
|
|
|
2002-01-16 06:55:30 +00:00
|
|
|
SYSCTL_NODE(_security, OID_AUTO, jail, CTLFLAG_RW, 0,
|
2000-02-12 13:41:56 +00:00
|
|
|
"Jail rules");
|
|
|
|
|
|
|
|
|
|
int jail_set_hostname_allowed = 1;
|
2002-01-16 06:55:30 +00:00
|
|
|
SYSCTL_INT(_security_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW,
|
2000-02-12 13:41:56 +00:00
|
|
|
&jail_set_hostname_allowed, 0,
|
|
|
|
|
"Processes in jail can set their hostnames");
|
|
|
|
|
|
2000-06-04 04:28:31 +00:00
|
|
|
int jail_socket_unixiproute_only = 1;
|
2002-01-16 06:55:30 +00:00
|
|
|
SYSCTL_INT(_security_jail, OID_AUTO, socket_unixiproute_only, CTLFLAG_RW,
|
2000-06-04 04:28:31 +00:00
|
|
|
&jail_socket_unixiproute_only, 0,
|
|
|
|
|
"Processes in jail are limited to creating UNIX/IPv4/route sockets only");
|
|
|
|
|
|
2000-10-31 01:34:00 +00:00
|
|
|
int jail_sysvipc_allowed = 0;
|
2002-01-16 06:55:30 +00:00
|
|
|
SYSCTL_INT(_security_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW,
|
2000-10-31 01:34:00 +00:00
|
|
|
&jail_sysvipc_allowed, 0,
|
|
|
|
|
"Processes in jail can use System V IPC primitives");
|
|
|
|
|
|
2005-06-09 18:49:19 +00:00
|
|
|
static int jail_enforce_statfs = 2;
|
|
|
|
|
SYSCTL_INT(_security_jail, OID_AUTO, enforce_statfs, CTLFLAG_RW,
|
|
|
|
|
&jail_enforce_statfs, 0,
|
|
|
|
|
"Processes in jail cannot see all mounted file systems");
|
2004-02-14 18:31:11 +00:00
|
|
|
|
2004-04-26 19:46:52 +00:00
|
|
|
int jail_allow_raw_sockets = 0;
|
|
|
|
|
SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW,
|
|
|
|
|
&jail_allow_raw_sockets, 0,
|
|
|
|
|
"Prison root can create raw sockets");
|
|
|
|
|
|
2005-02-08 21:31:11 +00:00
|
|
|
int jail_chflags_allowed = 0;
|
|
|
|
|
SYSCTL_INT(_security_jail, OID_AUTO, chflags_allowed, CTLFLAG_RW,
|
|
|
|
|
&jail_chflags_allowed, 0,
|
|
|
|
|
"Processes in jail can alter system file flags");
|
|
|
|
|
|
2007-04-05 21:03:05 +00:00
|
|
|
int jail_mount_allowed = 0;
|
|
|
|
|
SYSCTL_INT(_security_jail, OID_AUTO, mount_allowed, CTLFLAG_RW,
|
|
|
|
|
&jail_mount_allowed, 0,
|
|
|
|
|
"Processes in jail can mount/unmount jail-friendly file systems");
|
|
|
|
|
|
2007-04-05 23:19:13 +00:00
|
|
|
/* allprison, lastprid, and prisoncount are protected by allprison_lock. */
|
2003-04-09 02:55:18 +00:00
|
|
|
struct prisonlist allprison;
|
2007-04-05 23:19:13 +00:00
|
|
|
struct sx allprison_lock;
|
2003-04-09 02:55:18 +00:00
|
|
|
int lastprid = 0;
|
|
|
|
|
int prisoncount = 0;
|
|
|
|
|
|
2007-04-05 23:19:13 +00:00
|
|
|
/*
|
|
|
|
|
* List of jail services. Protected by allprison_lock.
|
|
|
|
|
*/
|
|
|
|
|
TAILQ_HEAD(prison_services_head, prison_service);
|
|
|
|
|
static struct prison_services_head prison_services =
|
|
|
|
|
TAILQ_HEAD_INITIALIZER(prison_services);
|
|
|
|
|
static int prison_service_slots = 0;
|
|
|
|
|
|
|
|
|
|
struct prison_service {
|
|
|
|
|
prison_create_t ps_create;
|
|
|
|
|
prison_destroy_t ps_destroy;
|
|
|
|
|
int ps_slotno;
|
|
|
|
|
TAILQ_ENTRY(prison_service) ps_next;
|
|
|
|
|
char ps_name[0];
|
|
|
|
|
};
|
|
|
|
|
|
2003-04-09 02:55:18 +00:00
|
|
|
static void init_prison(void *);
|
2004-01-23 20:44:26 +00:00
|
|
|
static void prison_complete(void *context, int pending);
|
2003-04-09 02:55:18 +00:00
|
|
|
static int sysctl_jail_list(SYSCTL_HANDLER_ARGS);
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
init_prison(void *data __unused)
|
|
|
|
|
{
|
|
|
|
|
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_init(&allprison_lock, "allprison");
|
2003-04-09 02:55:18 +00:00
|
|
|
LIST_INIT(&allprison);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SYSINIT(prison, SI_SUB_INTRINSIC, SI_ORDER_ANY, init_prison, NULL);
|
|
|
|
|
|
2001-09-01 03:04:31 +00:00
|
|
|
/*
|
2003-04-28 18:32:19 +00:00
|
|
|
* struct jail_args {
|
|
|
|
|
* struct jail *jail;
|
|
|
|
|
* };
|
2001-09-01 03:04:31 +00:00
|
|
|
*/
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
int
|
2003-04-28 18:32:19 +00:00
|
|
|
jail(struct thread *td, struct jail_args *uap)
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
{
|
2003-04-09 02:55:18 +00:00
|
|
|
struct nameidata nd;
|
|
|
|
|
struct prison *pr, *tpr;
|
2007-04-05 23:19:13 +00:00
|
|
|
struct prison_service *psrv;
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
struct jail j;
|
2003-04-09 02:55:18 +00:00
|
|
|
struct jail_attach_args jaa;
|
2005-09-28 00:30:56 +00:00
|
|
|
int vfslocked, error, tryprid;
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
|
2003-04-28 18:32:19 +00:00
|
|
|
error = copyin(uap->jail, &j, sizeof(j));
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
if (error)
|
2001-10-11 23:39:43 +00:00
|
|
|
return (error);
|
|
|
|
|
if (j.version != 0)
|
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
2003-04-28 18:32:19 +00:00
|
|
|
MALLOC(pr, struct prison *, sizeof(*pr), M_PRISON, M_WAITOK | M_ZERO);
|
2002-04-04 21:03:38 +00:00
|
|
|
mtx_init(&pr->pr_mtx, "jail mutex", NULL, MTX_DEF);
|
2003-04-09 02:55:18 +00:00
|
|
|
pr->pr_ref = 1;
|
2003-04-28 18:32:19 +00:00
|
|
|
error = copyinstr(j.path, &pr->pr_path, sizeof(pr->pr_path), 0);
|
2003-04-09 02:55:18 +00:00
|
|
|
if (error)
|
|
|
|
|
goto e_killmtx;
|
2005-09-28 00:30:56 +00:00
|
|
|
NDINIT(&nd, LOOKUP, MPSAFE | FOLLOW | LOCKLEAF, UIO_SYSSPACE,
|
|
|
|
|
pr->pr_path, td);
|
2003-04-09 02:55:18 +00:00
|
|
|
error = namei(&nd);
|
2005-09-28 00:30:56 +00:00
|
|
|
if (error)
|
2003-04-09 02:55:18 +00:00
|
|
|
goto e_killmtx;
|
2005-09-28 00:30:56 +00:00
|
|
|
vfslocked = NDHASGIANT(&nd);
|
2003-04-09 02:55:18 +00:00
|
|
|
pr->pr_root = nd.ni_vp;
|
2008-01-13 14:44:15 +00:00
|
|
|
VOP_UNLOCK(nd.ni_vp, 0);
|
2003-04-09 02:55:18 +00:00
|
|
|
NDFREE(&nd, NDF_ONLY_PNBUF);
|
2005-09-28 00:30:56 +00:00
|
|
|
VFS_UNLOCK_GIANT(vfslocked);
|
2003-04-28 18:32:19 +00:00
|
|
|
error = copyinstr(j.hostname, &pr->pr_host, sizeof(pr->pr_host), 0);
|
2001-10-11 23:39:43 +00:00
|
|
|
if (error)
|
2003-04-09 02:55:18 +00:00
|
|
|
goto e_dropvnref;
|
|
|
|
|
pr->pr_ip = j.ip_number;
|
|
|
|
|
pr->pr_linux = NULL;
|
|
|
|
|
pr->pr_securelevel = securelevel;
|
2007-04-05 23:19:13 +00:00
|
|
|
if (prison_service_slots == 0)
|
|
|
|
|
pr->pr_slots = NULL;
|
|
|
|
|
else {
|
|
|
|
|
pr->pr_slots = malloc(sizeof(*pr->pr_slots) * prison_service_slots,
|
|
|
|
|
M_PRISON, M_ZERO | M_WAITOK);
|
|
|
|
|
}
|
2003-04-09 02:55:18 +00:00
|
|
|
|
|
|
|
|
/* Determine next pr_id and add prison to allprison list. */
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_xlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
tryprid = lastprid + 1;
|
|
|
|
|
if (tryprid == JAIL_MAX)
|
|
|
|
|
tryprid = 1;
|
|
|
|
|
next:
|
|
|
|
|
LIST_FOREACH(tpr, &allprison, pr_list) {
|
|
|
|
|
if (tpr->pr_id == tryprid) {
|
|
|
|
|
tryprid++;
|
|
|
|
|
if (tryprid == JAIL_MAX) {
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_xunlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
error = EAGAIN;
|
|
|
|
|
goto e_dropvnref;
|
|
|
|
|
}
|
|
|
|
|
goto next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
pr->pr_id = jaa.jid = lastprid = tryprid;
|
|
|
|
|
LIST_INSERT_HEAD(&allprison, pr, pr_list);
|
|
|
|
|
prisoncount++;
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_downgrade(&allprison_lock);
|
|
|
|
|
TAILQ_FOREACH(psrv, &prison_services, ps_next) {
|
|
|
|
|
psrv->ps_create(psrv, pr);
|
|
|
|
|
}
|
|
|
|
|
sx_sunlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
|
|
|
|
|
error = jail_attach(td, &jaa);
|
|
|
|
|
if (error)
|
|
|
|
|
goto e_dropprref;
|
|
|
|
|
mtx_lock(&pr->pr_mtx);
|
|
|
|
|
pr->pr_ref--;
|
|
|
|
|
mtx_unlock(&pr->pr_mtx);
|
|
|
|
|
td->td_retval[0] = jaa.jid;
|
|
|
|
|
return (0);
|
|
|
|
|
e_dropprref:
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_xlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
LIST_REMOVE(pr, pr_list);
|
|
|
|
|
prisoncount--;
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_downgrade(&allprison_lock);
|
|
|
|
|
TAILQ_FOREACH(psrv, &prison_services, ps_next) {
|
|
|
|
|
psrv->ps_destroy(psrv, pr);
|
|
|
|
|
}
|
|
|
|
|
sx_sunlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
e_dropvnref:
|
2005-09-28 00:30:56 +00:00
|
|
|
vfslocked = VFS_LOCK_GIANT(pr->pr_root->v_mount);
|
2003-04-09 02:55:18 +00:00
|
|
|
vrele(pr->pr_root);
|
2005-09-28 00:30:56 +00:00
|
|
|
VFS_UNLOCK_GIANT(vfslocked);
|
2003-04-09 02:55:18 +00:00
|
|
|
e_killmtx:
|
|
|
|
|
mtx_destroy(&pr->pr_mtx);
|
|
|
|
|
FREE(pr, M_PRISON);
|
|
|
|
|
return (error);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2003-04-28 18:32:19 +00:00
|
|
|
* struct jail_attach_args {
|
|
|
|
|
* int jid;
|
|
|
|
|
* };
|
2003-04-09 02:55:18 +00:00
|
|
|
*/
|
|
|
|
|
int
|
2003-04-28 18:32:19 +00:00
|
|
|
jail_attach(struct thread *td, struct jail_attach_args *uap)
|
2003-04-09 02:55:18 +00:00
|
|
|
{
|
|
|
|
|
struct proc *p;
|
|
|
|
|
struct ucred *newcred, *oldcred;
|
|
|
|
|
struct prison *pr;
|
2005-09-28 00:30:56 +00:00
|
|
|
int vfslocked, error;
|
2007-03-07 21:24:51 +00:00
|
|
|
|
2004-02-19 21:03:20 +00:00
|
|
|
/*
|
|
|
|
|
* XXX: Note that there is a slight race here if two threads
|
|
|
|
|
* in the same privileged process attempt to attach to two
|
|
|
|
|
* different jails at the same time. It is important for
|
|
|
|
|
* user processes not to do this, or they might end up with
|
|
|
|
|
* a process root from one prison, but attached to the jail
|
|
|
|
|
* of another.
|
|
|
|
|
*/
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
error = priv_check(td, PRIV_JAIL_ATTACH);
|
2004-02-19 21:03:20 +00:00
|
|
|
if (error)
|
|
|
|
|
return (error);
|
2003-04-09 02:55:18 +00:00
|
|
|
|
2004-02-19 21:03:20 +00:00
|
|
|
p = td->td_proc;
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_slock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
pr = prison_find(uap->jid);
|
|
|
|
|
if (pr == NULL) {
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_sunlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
return (EINVAL);
|
|
|
|
|
}
|
|
|
|
|
pr->pr_ref++;
|
|
|
|
|
mtx_unlock(&pr->pr_mtx);
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_sunlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
|
2005-09-28 00:30:56 +00:00
|
|
|
vfslocked = VFS_LOCK_GIANT(pr->pr_root->v_mount);
|
2008-01-10 01:10:58 +00:00
|
|
|
vn_lock(pr->pr_root, LK_EXCLUSIVE | LK_RETRY);
|
2003-04-09 02:55:18 +00:00
|
|
|
if ((error = change_dir(pr->pr_root, td)) != 0)
|
|
|
|
|
goto e_unlock;
|
|
|
|
|
#ifdef MAC
|
2007-10-24 19:04:04 +00:00
|
|
|
if ((error = mac_vnode_check_chroot(td->td_ucred, pr->pr_root)))
|
2003-04-09 02:55:18 +00:00
|
|
|
goto e_unlock;
|
|
|
|
|
#endif
|
2008-01-13 14:44:15 +00:00
|
|
|
VOP_UNLOCK(pr->pr_root, 0);
|
2003-04-09 02:55:18 +00:00
|
|
|
change_root(pr->pr_root, td);
|
2005-09-28 00:30:56 +00:00
|
|
|
VFS_UNLOCK_GIANT(vfslocked);
|
2003-04-09 02:55:18 +00:00
|
|
|
|
2001-10-11 23:39:43 +00:00
|
|
|
newcred = crget();
|
|
|
|
|
PROC_LOCK(p);
|
|
|
|
|
oldcred = p->p_ucred;
|
2003-04-09 02:55:18 +00:00
|
|
|
setsugid(p);
|
2001-10-11 23:39:43 +00:00
|
|
|
crcopy(newcred, oldcred);
|
2003-04-17 22:26:53 +00:00
|
|
|
newcred->cr_prison = pr;
|
2001-10-11 23:39:43 +00:00
|
|
|
p->p_ucred = newcred;
|
|
|
|
|
PROC_UNLOCK(p);
|
|
|
|
|
crfree(oldcred);
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
return (0);
|
2003-04-09 02:55:18 +00:00
|
|
|
e_unlock:
|
2008-01-13 14:44:15 +00:00
|
|
|
VOP_UNLOCK(pr->pr_root, 0);
|
2005-09-28 00:30:56 +00:00
|
|
|
VFS_UNLOCK_GIANT(vfslocked);
|
2003-04-09 02:55:18 +00:00
|
|
|
mtx_lock(&pr->pr_mtx);
|
|
|
|
|
pr->pr_ref--;
|
|
|
|
|
mtx_unlock(&pr->pr_mtx);
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
return (error);
|
|
|
|
|
}
|
|
|
|
|
|
2003-04-09 02:55:18 +00:00
|
|
|
/*
|
|
|
|
|
* Returns a locked prison instance, or NULL on failure.
|
|
|
|
|
*/
|
2007-04-05 21:34:54 +00:00
|
|
|
struct prison *
|
2003-04-09 02:55:18 +00:00
|
|
|
prison_find(int prid)
|
|
|
|
|
{
|
|
|
|
|
struct prison *pr;
|
|
|
|
|
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_assert(&allprison_lock, SX_LOCKED);
|
2003-04-09 02:55:18 +00:00
|
|
|
LIST_FOREACH(pr, &allprison, pr_list) {
|
|
|
|
|
if (pr->pr_id == prid) {
|
|
|
|
|
mtx_lock(&pr->pr_mtx);
|
2007-04-08 10:46:23 +00:00
|
|
|
if (pr->pr_ref == 0) {
|
|
|
|
|
mtx_unlock(&pr->pr_mtx);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2003-04-09 02:55:18 +00:00
|
|
|
return (pr);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return (NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2001-02-21 06:39:57 +00:00
|
|
|
void
|
|
|
|
|
prison_free(struct prison *pr)
|
|
|
|
|
{
|
|
|
|
|
|
o Introduce pr_mtx into struct prison, providing protection for the
mutable contents of struct prison (hostname, securelevel, refcount,
pr_linux, ...)
o Generally introduce mtx_lock()/mtx_unlock() calls throughout kern/
so as to enforce these protections, in particular, in kern_mib.c
protection sysctl access to the hostname and securelevel, as well as
kern_prot.c access to the securelevel for access control purposes.
o Rewrite linux emulator abstractions for accessing per-jail linux
mib entries (osname, osrelease, osversion) so that they don't return
a pointer to the text in the struct linux_prison, rather, a copy
to an array passed into the calls. Likewise, update linprocfs to
use these primitives.
o Update in_pcb.c to always use prison_getip() rather than directly
accessing struct prison.
Reviewed by: jhb
2001-12-03 16:12:27 +00:00
|
|
|
mtx_lock(&pr->pr_mtx);
|
2001-02-21 06:39:57 +00:00
|
|
|
pr->pr_ref--;
|
|
|
|
|
if (pr->pr_ref == 0) {
|
o Introduce pr_mtx into struct prison, providing protection for the
mutable contents of struct prison (hostname, securelevel, refcount,
pr_linux, ...)
o Generally introduce mtx_lock()/mtx_unlock() calls throughout kern/
so as to enforce these protections, in particular, in kern_mib.c
protection sysctl access to the hostname and securelevel, as well as
kern_prot.c access to the securelevel for access control purposes.
o Rewrite linux emulator abstractions for accessing per-jail linux
mib entries (osname, osrelease, osversion) so that they don't return
a pointer to the text in the struct linux_prison, rather, a copy
to an array passed into the calls. Likewise, update linprocfs to
use these primitives.
o Update in_pcb.c to always use prison_getip() rather than directly
accessing struct prison.
Reviewed by: jhb
2001-12-03 16:12:27 +00:00
|
|
|
mtx_unlock(&pr->pr_mtx);
|
2004-01-23 20:44:26 +00:00
|
|
|
TASK_INIT(&pr->pr_task, 0, prison_complete, pr);
|
2005-04-05 08:51:45 +00:00
|
|
|
taskqueue_enqueue(taskqueue_thread, &pr->pr_task);
|
o Introduce pr_mtx into struct prison, providing protection for the
mutable contents of struct prison (hostname, securelevel, refcount,
pr_linux, ...)
o Generally introduce mtx_lock()/mtx_unlock() calls throughout kern/
so as to enforce these protections, in particular, in kern_mib.c
protection sysctl access to the hostname and securelevel, as well as
kern_prot.c access to the securelevel for access control purposes.
o Rewrite linux emulator abstractions for accessing per-jail linux
mib entries (osname, osrelease, osversion) so that they don't return
a pointer to the text in the struct linux_prison, rather, a copy
to an array passed into the calls. Likewise, update linprocfs to
use these primitives.
o Update in_pcb.c to always use prison_getip() rather than directly
accessing struct prison.
Reviewed by: jhb
2001-12-03 16:12:27 +00:00
|
|
|
return;
|
2001-02-21 06:39:57 +00:00
|
|
|
}
|
o Introduce pr_mtx into struct prison, providing protection for the
mutable contents of struct prison (hostname, securelevel, refcount,
pr_linux, ...)
o Generally introduce mtx_lock()/mtx_unlock() calls throughout kern/
so as to enforce these protections, in particular, in kern_mib.c
protection sysctl access to the hostname and securelevel, as well as
kern_prot.c access to the securelevel for access control purposes.
o Rewrite linux emulator abstractions for accessing per-jail linux
mib entries (osname, osrelease, osversion) so that they don't return
a pointer to the text in the struct linux_prison, rather, a copy
to an array passed into the calls. Likewise, update linprocfs to
use these primitives.
o Update in_pcb.c to always use prison_getip() rather than directly
accessing struct prison.
Reviewed by: jhb
2001-12-03 16:12:27 +00:00
|
|
|
mtx_unlock(&pr->pr_mtx);
|
2001-02-21 06:39:57 +00:00
|
|
|
}
|
|
|
|
|
|
2004-01-23 20:44:26 +00:00
|
|
|
static void
|
|
|
|
|
prison_complete(void *context, int pending)
|
|
|
|
|
{
|
2007-04-08 10:46:23 +00:00
|
|
|
struct prison_service *psrv;
|
2004-01-23 20:44:26 +00:00
|
|
|
struct prison *pr;
|
2005-09-28 00:30:56 +00:00
|
|
|
int vfslocked;
|
2004-01-23 20:44:26 +00:00
|
|
|
|
|
|
|
|
pr = (struct prison *)context;
|
|
|
|
|
|
2007-04-08 10:46:23 +00:00
|
|
|
sx_xlock(&allprison_lock);
|
|
|
|
|
LIST_REMOVE(pr, pr_list);
|
|
|
|
|
prisoncount--;
|
|
|
|
|
sx_downgrade(&allprison_lock);
|
|
|
|
|
TAILQ_FOREACH(psrv, &prison_services, ps_next) {
|
|
|
|
|
psrv->ps_destroy(psrv, pr);
|
|
|
|
|
}
|
|
|
|
|
sx_sunlock(&allprison_lock);
|
|
|
|
|
|
2005-09-28 00:30:56 +00:00
|
|
|
vfslocked = VFS_LOCK_GIANT(pr->pr_root->v_mount);
|
2004-01-23 20:44:26 +00:00
|
|
|
vrele(pr->pr_root);
|
2005-09-28 00:30:56 +00:00
|
|
|
VFS_UNLOCK_GIANT(vfslocked);
|
2004-01-23 20:44:26 +00:00
|
|
|
|
|
|
|
|
mtx_destroy(&pr->pr_mtx);
|
|
|
|
|
if (pr->pr_linux != NULL)
|
|
|
|
|
FREE(pr->pr_linux, M_PRISON);
|
|
|
|
|
FREE(pr, M_PRISON);
|
|
|
|
|
}
|
|
|
|
|
|
2001-02-21 06:39:57 +00:00
|
|
|
void
|
|
|
|
|
prison_hold(struct prison *pr)
|
|
|
|
|
{
|
|
|
|
|
|
o Introduce pr_mtx into struct prison, providing protection for the
mutable contents of struct prison (hostname, securelevel, refcount,
pr_linux, ...)
o Generally introduce mtx_lock()/mtx_unlock() calls throughout kern/
so as to enforce these protections, in particular, in kern_mib.c
protection sysctl access to the hostname and securelevel, as well as
kern_prot.c access to the securelevel for access control purposes.
o Rewrite linux emulator abstractions for accessing per-jail linux
mib entries (osname, osrelease, osversion) so that they don't return
a pointer to the text in the struct linux_prison, rather, a copy
to an array passed into the calls. Likewise, update linprocfs to
use these primitives.
o Update in_pcb.c to always use prison_getip() rather than directly
accessing struct prison.
Reviewed by: jhb
2001-12-03 16:12:27 +00:00
|
|
|
mtx_lock(&pr->pr_mtx);
|
2007-04-08 10:46:23 +00:00
|
|
|
KASSERT(pr->pr_ref > 0,
|
|
|
|
|
("Trying to hold dead prison (id=%d).", pr->pr_id));
|
2001-02-21 06:39:57 +00:00
|
|
|
pr->pr_ref++;
|
o Introduce pr_mtx into struct prison, providing protection for the
mutable contents of struct prison (hostname, securelevel, refcount,
pr_linux, ...)
o Generally introduce mtx_lock()/mtx_unlock() calls throughout kern/
so as to enforce these protections, in particular, in kern_mib.c
protection sysctl access to the hostname and securelevel, as well as
kern_prot.c access to the securelevel for access control purposes.
o Rewrite linux emulator abstractions for accessing per-jail linux
mib entries (osname, osrelease, osversion) so that they don't return
a pointer to the text in the struct linux_prison, rather, a copy
to an array passed into the calls. Likewise, update linprocfs to
use these primitives.
o Update in_pcb.c to always use prison_getip() rather than directly
accessing struct prison.
Reviewed by: jhb
2001-12-03 16:12:27 +00:00
|
|
|
mtx_unlock(&pr->pr_mtx);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
u_int32_t
|
|
|
|
|
prison_getip(struct ucred *cred)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
return (cred->cr_prison->pr_ip);
|
2001-02-21 06:39:57 +00:00
|
|
|
}
|
|
|
|
|
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
int
|
2001-02-21 06:39:57 +00:00
|
|
|
prison_ip(struct ucred *cred, int flag, u_int32_t *ip)
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
{
|
|
|
|
|
u_int32_t tmp;
|
|
|
|
|
|
2001-02-21 06:39:57 +00:00
|
|
|
if (!jailed(cred))
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
return (0);
|
2007-03-07 21:24:51 +00:00
|
|
|
if (flag)
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
tmp = *ip;
|
|
|
|
|
else
|
|
|
|
|
tmp = ntohl(*ip);
|
|
|
|
|
if (tmp == INADDR_ANY) {
|
2007-03-07 21:24:51 +00:00
|
|
|
if (flag)
|
2001-02-21 06:39:57 +00:00
|
|
|
*ip = cred->cr_prison->pr_ip;
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
else
|
2001-02-21 06:39:57 +00:00
|
|
|
*ip = htonl(cred->cr_prison->pr_ip);
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
return (0);
|
|
|
|
|
}
|
2001-08-03 18:21:06 +00:00
|
|
|
if (tmp == INADDR_LOOPBACK) {
|
|
|
|
|
if (flag)
|
|
|
|
|
*ip = cred->cr_prison->pr_ip;
|
|
|
|
|
else
|
|
|
|
|
*ip = htonl(cred->cr_prison->pr_ip);
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
2001-02-21 06:39:57 +00:00
|
|
|
if (cred->cr_prison->pr_ip != tmp)
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
return (1);
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2001-02-21 06:39:57 +00:00
|
|
|
prison_remote_ip(struct ucred *cred, int flag, u_int32_t *ip)
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
{
|
|
|
|
|
u_int32_t tmp;
|
|
|
|
|
|
2001-02-21 06:39:57 +00:00
|
|
|
if (!jailed(cred))
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
return;
|
|
|
|
|
if (flag)
|
|
|
|
|
tmp = *ip;
|
|
|
|
|
else
|
|
|
|
|
tmp = ntohl(*ip);
|
2001-08-03 18:21:06 +00:00
|
|
|
if (tmp == INADDR_LOOPBACK) {
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
if (flag)
|
2001-02-21 06:39:57 +00:00
|
|
|
*ip = cred->cr_prison->pr_ip;
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
else
|
2001-02-21 06:39:57 +00:00
|
|
|
*ip = htonl(cred->cr_prison->pr_ip);
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int
|
2001-02-21 06:39:57 +00:00
|
|
|
prison_if(struct ucred *cred, struct sockaddr *sa)
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
{
|
2003-04-28 18:32:19 +00:00
|
|
|
struct sockaddr_in *sai;
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
int ok;
|
|
|
|
|
|
2003-04-28 18:32:19 +00:00
|
|
|
sai = (struct sockaddr_in *)sa;
|
2000-06-04 04:28:31 +00:00
|
|
|
if ((sai->sin_family != AF_INET) && jail_socket_unixiproute_only)
|
|
|
|
|
ok = 1;
|
|
|
|
|
else if (sai->sin_family != AF_INET)
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
ok = 0;
|
2001-02-21 06:39:57 +00:00
|
|
|
else if (cred->cr_prison->pr_ip != ntohl(sai->sin_addr.s_addr))
|
This Implements the mumbled about "Jail" feature.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
1999-04-28 11:38:52 +00:00
|
|
|
ok = 1;
|
|
|
|
|
else
|
|
|
|
|
ok = 0;
|
|
|
|
|
return (ok);
|
|
|
|
|
}
|
2001-02-21 06:39:57 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Return 0 if jails permit p1 to frob p2, otherwise ESRCH.
|
|
|
|
|
*/
|
|
|
|
|
int
|
2003-04-28 18:32:19 +00:00
|
|
|
prison_check(struct ucred *cred1, struct ucred *cred2)
|
2001-02-21 06:39:57 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
|
|
if (jailed(cred1)) {
|
|
|
|
|
if (!jailed(cred2))
|
|
|
|
|
return (ESRCH);
|
|
|
|
|
if (cred2->cr_prison != cred1->cr_prison)
|
|
|
|
|
return (ESRCH);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Return 1 if the passed credential is in a jail, otherwise 0.
|
|
|
|
|
*/
|
|
|
|
|
int
|
2003-04-28 18:32:19 +00:00
|
|
|
jailed(struct ucred *cred)
|
2001-02-21 06:39:57 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
|
|
return (cred->cr_prison != NULL);
|
|
|
|
|
}
|
2002-02-27 14:58:32 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Return the correct hostname for the passed credential.
|
|
|
|
|
*/
|
2002-02-27 16:43:20 +00:00
|
|
|
void
|
2003-04-28 18:32:19 +00:00
|
|
|
getcredhostname(struct ucred *cred, char *buf, size_t size)
|
2002-02-27 14:58:32 +00:00
|
|
|
{
|
|
|
|
|
|
2002-02-27 16:43:20 +00:00
|
|
|
if (jailed(cred)) {
|
|
|
|
|
mtx_lock(&cred->cr_prison->pr_mtx);
|
2002-10-17 20:03:38 +00:00
|
|
|
strlcpy(buf, cred->cr_prison->pr_host, size);
|
2002-02-27 16:43:20 +00:00
|
|
|
mtx_unlock(&cred->cr_prison->pr_mtx);
|
2003-04-28 18:32:19 +00:00
|
|
|
} else
|
2002-10-17 20:03:38 +00:00
|
|
|
strlcpy(buf, hostname, size);
|
2002-02-27 14:58:32 +00:00
|
|
|
}
|
2003-04-09 02:55:18 +00:00
|
|
|
|
2004-02-14 18:31:11 +00:00
|
|
|
/*
|
2005-06-09 18:49:19 +00:00
|
|
|
* Determine whether the subject represented by cred can "see"
|
|
|
|
|
* status of a mount point.
|
|
|
|
|
* Returns: 0 for permitted, ENOENT otherwise.
|
|
|
|
|
* XXX: This function should be called cr_canseemount() and should be
|
|
|
|
|
* placed in kern_prot.c.
|
2004-02-14 18:31:11 +00:00
|
|
|
*/
|
|
|
|
|
int
|
2005-06-09 18:49:19 +00:00
|
|
|
prison_canseemount(struct ucred *cred, struct mount *mp)
|
2004-02-14 18:31:11 +00:00
|
|
|
{
|
2005-06-09 18:49:19 +00:00
|
|
|
struct prison *pr;
|
|
|
|
|
struct statfs *sp;
|
|
|
|
|
size_t len;
|
2004-02-14 18:31:11 +00:00
|
|
|
|
2005-06-09 18:49:19 +00:00
|
|
|
if (!jailed(cred) || jail_enforce_statfs == 0)
|
|
|
|
|
return (0);
|
|
|
|
|
pr = cred->cr_prison;
|
|
|
|
|
if (pr->pr_root->v_mount == mp)
|
|
|
|
|
return (0);
|
|
|
|
|
if (jail_enforce_statfs == 2)
|
|
|
|
|
return (ENOENT);
|
|
|
|
|
/*
|
|
|
|
|
* If jail's chroot directory is set to "/" we should be able to see
|
|
|
|
|
* all mount-points from inside a jail.
|
|
|
|
|
* This is ugly check, but this is the only situation when jail's
|
|
|
|
|
* directory ends with '/'.
|
|
|
|
|
*/
|
|
|
|
|
if (strcmp(pr->pr_path, "/") == 0)
|
|
|
|
|
return (0);
|
|
|
|
|
len = strlen(pr->pr_path);
|
|
|
|
|
sp = &mp->mnt_stat;
|
|
|
|
|
if (strncmp(pr->pr_path, sp->f_mntonname, len) != 0)
|
|
|
|
|
return (ENOENT);
|
|
|
|
|
/*
|
|
|
|
|
* Be sure that we don't have situation where jail's root directory
|
|
|
|
|
* is "/some/path" and mount point is "/some/pathpath".
|
|
|
|
|
*/
|
|
|
|
|
if (sp->f_mntonname[len] != '\0' && sp->f_mntonname[len] != '/')
|
|
|
|
|
return (ENOENT);
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
prison_enforce_statfs(struct ucred *cred, struct mount *mp, struct statfs *sp)
|
|
|
|
|
{
|
|
|
|
|
char jpath[MAXPATHLEN];
|
|
|
|
|
struct prison *pr;
|
|
|
|
|
size_t len;
|
|
|
|
|
|
|
|
|
|
if (!jailed(cred) || jail_enforce_statfs == 0)
|
|
|
|
|
return;
|
|
|
|
|
pr = cred->cr_prison;
|
|
|
|
|
if (prison_canseemount(cred, mp) != 0) {
|
|
|
|
|
bzero(sp->f_mntonname, sizeof(sp->f_mntonname));
|
|
|
|
|
strlcpy(sp->f_mntonname, "[restricted]",
|
|
|
|
|
sizeof(sp->f_mntonname));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (pr->pr_root->v_mount == mp) {
|
|
|
|
|
/*
|
|
|
|
|
* Clear current buffer data, so we are sure nothing from
|
|
|
|
|
* the valid path left there.
|
|
|
|
|
*/
|
|
|
|
|
bzero(sp->f_mntonname, sizeof(sp->f_mntonname));
|
|
|
|
|
*sp->f_mntonname = '/';
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* If jail's chroot directory is set to "/" we should be able to see
|
|
|
|
|
* all mount-points from inside a jail.
|
|
|
|
|
*/
|
|
|
|
|
if (strcmp(pr->pr_path, "/") == 0)
|
|
|
|
|
return;
|
|
|
|
|
len = strlen(pr->pr_path);
|
|
|
|
|
strlcpy(jpath, sp->f_mntonname + len, sizeof(jpath));
|
|
|
|
|
/*
|
|
|
|
|
* Clear current buffer data, so we are sure nothing from
|
|
|
|
|
* the valid path left there.
|
|
|
|
|
*/
|
|
|
|
|
bzero(sp->f_mntonname, sizeof(sp->f_mntonname));
|
|
|
|
|
if (*jpath == '\0') {
|
|
|
|
|
/* Should never happen. */
|
|
|
|
|
*sp->f_mntonname = '/';
|
|
|
|
|
} else {
|
|
|
|
|
strlcpy(sp->f_mntonname, jpath, sizeof(sp->f_mntonname));
|
2004-02-14 18:31:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
/*
|
|
|
|
|
* Check with permission for a specific privilege is granted within jail. We
|
|
|
|
|
* have a specific list of accepted privileges; the rest are denied.
|
|
|
|
|
*/
|
|
|
|
|
int
|
|
|
|
|
prison_priv_check(struct ucred *cred, int priv)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
if (!jailed(cred))
|
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
|
|
switch (priv) {
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allow ktrace privileges for root in jail.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_KTRACE:
|
|
|
|
|
|
2007-02-19 13:10:29 +00:00
|
|
|
#if 0
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
/*
|
|
|
|
|
* Allow jailed processes to configure audit identity and
|
|
|
|
|
* submit audit records (login, etc). In the future we may
|
|
|
|
|
* want to further refine the relationship between audit and
|
|
|
|
|
* jail.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_AUDIT_GETAUDIT:
|
|
|
|
|
case PRIV_AUDIT_SETAUDIT:
|
|
|
|
|
case PRIV_AUDIT_SUBMIT:
|
2007-02-19 13:10:29 +00:00
|
|
|
#endif
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allow jailed processes to manipulate process UNIX
|
|
|
|
|
* credentials in any way they see fit.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_CRED_SETUID:
|
|
|
|
|
case PRIV_CRED_SETEUID:
|
|
|
|
|
case PRIV_CRED_SETGID:
|
|
|
|
|
case PRIV_CRED_SETEGID:
|
|
|
|
|
case PRIV_CRED_SETGROUPS:
|
|
|
|
|
case PRIV_CRED_SETREUID:
|
|
|
|
|
case PRIV_CRED_SETREGID:
|
|
|
|
|
case PRIV_CRED_SETRESUID:
|
|
|
|
|
case PRIV_CRED_SETRESGID:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Jail implements visibility constraints already, so allow
|
|
|
|
|
* jailed root to override uid/gid-based constraints.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_SEEOTHERGIDS:
|
|
|
|
|
case PRIV_SEEOTHERUIDS:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Jail implements inter-process debugging limits already, so
|
|
|
|
|
* allow jailed root various debugging privileges.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_DEBUG_DIFFCRED:
|
|
|
|
|
case PRIV_DEBUG_SUGID:
|
|
|
|
|
case PRIV_DEBUG_UNPRIV:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allow jail to set various resource limits and login
|
|
|
|
|
* properties, and for now, exceed process resource limits.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_PROC_LIMIT:
|
|
|
|
|
case PRIV_PROC_SETLOGIN:
|
|
|
|
|
case PRIV_PROC_SETRLIMIT:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* System V and POSIX IPC privileges are granted in jail.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_IPC_READ:
|
|
|
|
|
case PRIV_IPC_WRITE:
|
|
|
|
|
case PRIV_IPC_ADMIN:
|
|
|
|
|
case PRIV_IPC_MSGSIZE:
|
|
|
|
|
case PRIV_MQ_ADMIN:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Jail implements its own inter-process limits, so allow
|
|
|
|
|
* root processes in jail to change scheduling on other
|
|
|
|
|
* processes in the same jail. Likewise for signalling.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_SCHED_DIFFCRED:
|
|
|
|
|
case PRIV_SIGNAL_DIFFCRED:
|
|
|
|
|
case PRIV_SIGNAL_SUGID:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allow jailed processes to write to sysctls marked as jail
|
|
|
|
|
* writable.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_SYSCTL_WRITEJAIL:
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allow root in jail to manage a variety of quota
|
2007-02-19 13:26:39 +00:00
|
|
|
* properties. These should likely be conditional on a
|
|
|
|
|
* configuration option.
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
*/
|
2007-02-19 13:33:10 +00:00
|
|
|
case PRIV_VFS_GETQUOTA:
|
|
|
|
|
case PRIV_VFS_SETQUOTA:
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Since Jail relies on chroot() to implement file system
|
|
|
|
|
* protections, grant many VFS privileges to root in jail.
|
|
|
|
|
* Be careful to exclude mount-related and NFS-related
|
|
|
|
|
* privileges.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_VFS_READ:
|
|
|
|
|
case PRIV_VFS_WRITE:
|
|
|
|
|
case PRIV_VFS_ADMIN:
|
|
|
|
|
case PRIV_VFS_EXEC:
|
|
|
|
|
case PRIV_VFS_LOOKUP:
|
|
|
|
|
case PRIV_VFS_BLOCKRESERVE: /* XXXRW: Slightly surprising. */
|
|
|
|
|
case PRIV_VFS_CHFLAGS_DEV:
|
|
|
|
|
case PRIV_VFS_CHOWN:
|
|
|
|
|
case PRIV_VFS_CHROOT:
|
2007-03-01 20:47:42 +00:00
|
|
|
case PRIV_VFS_RETAINSUGID:
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
case PRIV_VFS_FCHROOT:
|
|
|
|
|
case PRIV_VFS_LINK:
|
|
|
|
|
case PRIV_VFS_SETGID:
|
2007-10-21 22:50:11 +00:00
|
|
|
case PRIV_VFS_STAT:
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
case PRIV_VFS_STICKYFILE:
|
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Depending on the global setting, allow privilege of
|
|
|
|
|
* setting system flags.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_VFS_SYSFLAGS:
|
|
|
|
|
if (jail_chflags_allowed)
|
2007-04-05 21:03:05 +00:00
|
|
|
return (0);
|
|
|
|
|
else
|
|
|
|
|
return (EPERM);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Depending on the global setting, allow privilege of
|
|
|
|
|
* mounting/unmounting file systems.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_VFS_MOUNT:
|
|
|
|
|
case PRIV_VFS_UNMOUNT:
|
|
|
|
|
case PRIV_VFS_MOUNT_NONUSER:
|
2007-04-13 23:54:22 +00:00
|
|
|
case PRIV_VFS_MOUNT_OWNER:
|
2007-04-05 21:03:05 +00:00
|
|
|
if (jail_mount_allowed)
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
return (0);
|
|
|
|
|
else
|
|
|
|
|
return (EPERM);
|
|
|
|
|
|
|
|
|
|
/*
|
2007-04-10 15:59:49 +00:00
|
|
|
* Allow jailed root to bind reserved ports and reuse in-use
|
|
|
|
|
* ports.
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
*/
|
|
|
|
|
case PRIV_NETINET_RESERVEDPORT:
|
2007-04-10 15:59:49 +00:00
|
|
|
case PRIV_NETINET_REUSEPORT:
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
return (0);
|
|
|
|
|
|
2008-01-24 08:25:59 +00:00
|
|
|
/*
|
|
|
|
|
* Allow jailed root to set certian IPv4/6 (option) headers.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_NETINET_SETHDROPTS:
|
|
|
|
|
return (0);
|
|
|
|
|
|
Add a new priv(9) kernel interface for checking the availability of
privilege for threads and credentials. Unlike the existing suser(9)
interface, priv(9) exposes a named privilege identifier to the privilege
checking code, allowing more complex policies regarding the granting of
privilege to be expressed. Two interfaces are provided, replacing the
existing suser(9) interface:
suser(td) -> priv_check(td, priv)
suser_cred(cred, flags) -> priv_check_cred(cred, priv, flags)
A comprehensive list of currently available kernel privileges may be
found in priv.h. New privileges are easily added as required, but the
comments on adding privileges found in priv.h and priv(9) should be read
before doing so.
The new privilege interface exposed sufficient information to the
privilege checking routine that it will now be possible for jail to
determine whether a particular privilege is granted in the check routine,
rather than relying on hints from the calling context via the
SUSER_ALLOWJAIL flag. For now, the flag is maintained, but a new jail
check function, prison_priv_check(), is exposed from kern_jail.c and used
by the privilege check routine to determine if the privilege is permitted
in jail. As a result, a centralized list of privileges permitted in jail
is now present in kern_jail.c.
The MAC Framework is now also able to instrument privilege checks, both
to deny privileges otherwise granted (mac_priv_check()), and to grant
privileges otherwise denied (mac_priv_grant()), permitting MAC Policy
modules to implement privilege models, as well as control a much broader
range of system behavior in order to constrain processes running with
root privilege.
The suser() and suser_cred() functions remain implemented, now in terms
of priv_check() and the PRIV_ROOT privilege, for use during the transition
and possibly continuing use by third party kernel modules that have not
been updated. The PRIV_DRIVER privilege exists to allow device drivers to
check privilege without adopting a more specific privilege identifier.
This change does not modify the actual security policy, rather, it
modifies the interface for privilege checks so changes to the security
policy become more feasible.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
2006-11-06 13:37:19 +00:00
|
|
|
/*
|
|
|
|
|
* Conditionally allow creating raw sockets in jail.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_NETINET_RAW:
|
|
|
|
|
if (jail_allow_raw_sockets)
|
|
|
|
|
return (0);
|
|
|
|
|
else
|
|
|
|
|
return (EPERM);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Since jail implements its own visibility limits on netstat
|
|
|
|
|
* sysctls, allow getcred. This allows identd to work in
|
|
|
|
|
* jail.
|
|
|
|
|
*/
|
|
|
|
|
case PRIV_NETINET_GETCRED:
|
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
/*
|
|
|
|
|
* In all remaining cases, deny the privilege request. This
|
|
|
|
|
* includes almost all network privileges, many system
|
|
|
|
|
* configuration privileges.
|
|
|
|
|
*/
|
|
|
|
|
return (EPERM);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-04-05 23:19:13 +00:00
|
|
|
/*
|
|
|
|
|
* Register jail service. Provides 'create' and 'destroy' methods.
|
|
|
|
|
* 'create' method will be called for every existing jail and all
|
|
|
|
|
* jails in the future as they beeing created.
|
|
|
|
|
* 'destroy' method will be called for every jail going away and
|
|
|
|
|
* for all existing jails at the time of service deregistration.
|
|
|
|
|
*/
|
|
|
|
|
struct prison_service *
|
|
|
|
|
prison_service_register(const char *name, prison_create_t create,
|
|
|
|
|
prison_destroy_t destroy)
|
|
|
|
|
{
|
|
|
|
|
struct prison_service *psrv, *psrv2;
|
|
|
|
|
struct prison *pr;
|
|
|
|
|
int reallocate = 1, slotno = 0;
|
|
|
|
|
void **slots, **oldslots;
|
|
|
|
|
|
|
|
|
|
psrv = malloc(sizeof(*psrv) + strlen(name) + 1, M_PRISON,
|
|
|
|
|
M_WAITOK | M_ZERO);
|
|
|
|
|
psrv->ps_create = create;
|
|
|
|
|
psrv->ps_destroy = destroy;
|
|
|
|
|
strcpy(psrv->ps_name, name);
|
|
|
|
|
/*
|
|
|
|
|
* Grab the allprison_lock here, so we won't miss any jail
|
|
|
|
|
* creation/destruction.
|
|
|
|
|
*/
|
|
|
|
|
sx_xlock(&allprison_lock);
|
|
|
|
|
#ifdef INVARIANTS
|
|
|
|
|
/*
|
|
|
|
|
* Verify if service is not already registered.
|
|
|
|
|
*/
|
|
|
|
|
TAILQ_FOREACH(psrv2, &prison_services, ps_next) {
|
|
|
|
|
KASSERT(strcmp(psrv2->ps_name, name) != 0,
|
|
|
|
|
("jail service %s already registered", name));
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
/*
|
|
|
|
|
* Find free slot. When there is no existing free slot available,
|
|
|
|
|
* allocate one at the end.
|
|
|
|
|
*/
|
|
|
|
|
TAILQ_FOREACH(psrv2, &prison_services, ps_next) {
|
|
|
|
|
if (psrv2->ps_slotno != slotno) {
|
|
|
|
|
KASSERT(slotno < psrv2->ps_slotno,
|
|
|
|
|
("Invalid slotno (slotno=%d >= ps_slotno=%d",
|
|
|
|
|
slotno, psrv2->ps_slotno));
|
|
|
|
|
/* We found free slot. */
|
|
|
|
|
reallocate = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
slotno++;
|
|
|
|
|
}
|
|
|
|
|
psrv->ps_slotno = slotno;
|
|
|
|
|
/*
|
|
|
|
|
* Keep the list sorted by slot number.
|
|
|
|
|
*/
|
|
|
|
|
if (psrv2 != NULL) {
|
|
|
|
|
KASSERT(reallocate == 0, ("psrv2 != NULL && reallocate != 0"));
|
|
|
|
|
TAILQ_INSERT_BEFORE(psrv2, psrv, ps_next);
|
|
|
|
|
} else {
|
|
|
|
|
KASSERT(reallocate == 1, ("psrv2 == NULL && reallocate == 0"));
|
|
|
|
|
TAILQ_INSERT_TAIL(&prison_services, psrv, ps_next);
|
|
|
|
|
}
|
|
|
|
|
prison_service_slots++;
|
|
|
|
|
sx_downgrade(&allprison_lock);
|
|
|
|
|
/*
|
|
|
|
|
* Allocate memory for new slot if we didn't found empty one.
|
|
|
|
|
* Do not use realloc(9), because pr_slots is protected with a mutex,
|
|
|
|
|
* so we can't sleep.
|
|
|
|
|
*/
|
|
|
|
|
LIST_FOREACH(pr, &allprison, pr_list) {
|
|
|
|
|
if (reallocate) {
|
|
|
|
|
/* First allocate memory with M_WAITOK. */
|
|
|
|
|
slots = malloc(sizeof(*slots) * prison_service_slots,
|
|
|
|
|
M_PRISON, M_WAITOK);
|
|
|
|
|
/* Now grab the mutex and replace pr_slots. */
|
|
|
|
|
mtx_lock(&pr->pr_mtx);
|
|
|
|
|
oldslots = pr->pr_slots;
|
|
|
|
|
if (psrv->ps_slotno > 0) {
|
|
|
|
|
bcopy(oldslots, slots,
|
|
|
|
|
sizeof(*slots) * (prison_service_slots - 1));
|
|
|
|
|
}
|
|
|
|
|
slots[psrv->ps_slotno] = NULL;
|
|
|
|
|
pr->pr_slots = slots;
|
|
|
|
|
mtx_unlock(&pr->pr_mtx);
|
|
|
|
|
if (oldslots != NULL)
|
|
|
|
|
free(oldslots, M_PRISON);
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* Call 'create' method for each existing jail.
|
|
|
|
|
*/
|
|
|
|
|
psrv->ps_create(psrv, pr);
|
|
|
|
|
}
|
|
|
|
|
sx_sunlock(&allprison_lock);
|
|
|
|
|
|
|
|
|
|
return (psrv);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
prison_service_deregister(struct prison_service *psrv)
|
|
|
|
|
{
|
|
|
|
|
struct prison *pr;
|
|
|
|
|
void **slots, **oldslots;
|
|
|
|
|
int last = 0;
|
|
|
|
|
|
|
|
|
|
sx_xlock(&allprison_lock);
|
|
|
|
|
if (TAILQ_LAST(&prison_services, prison_services_head) == psrv)
|
|
|
|
|
last = 1;
|
|
|
|
|
TAILQ_REMOVE(&prison_services, psrv, ps_next);
|
|
|
|
|
prison_service_slots--;
|
|
|
|
|
sx_downgrade(&allprison_lock);
|
|
|
|
|
LIST_FOREACH(pr, &allprison, pr_list) {
|
|
|
|
|
/*
|
|
|
|
|
* Call 'destroy' method for every currently existing jail.
|
|
|
|
|
*/
|
|
|
|
|
psrv->ps_destroy(psrv, pr);
|
|
|
|
|
/*
|
|
|
|
|
* If this is the last slot, free the memory allocated for it.
|
|
|
|
|
*/
|
|
|
|
|
if (last) {
|
|
|
|
|
if (prison_service_slots == 0)
|
|
|
|
|
slots = NULL;
|
|
|
|
|
else {
|
|
|
|
|
slots = malloc(sizeof(*slots) * prison_service_slots,
|
|
|
|
|
M_PRISON, M_WAITOK);
|
|
|
|
|
}
|
|
|
|
|
mtx_lock(&pr->pr_mtx);
|
|
|
|
|
oldslots = pr->pr_slots;
|
|
|
|
|
/*
|
|
|
|
|
* We require setting slot to NULL after freeing it,
|
|
|
|
|
* this way we can check for memory leaks here.
|
|
|
|
|
*/
|
|
|
|
|
KASSERT(oldslots[psrv->ps_slotno] == NULL,
|
|
|
|
|
("Slot %d (service %s, jailid=%d) still contains data?",
|
|
|
|
|
psrv->ps_slotno, psrv->ps_name, pr->pr_id));
|
|
|
|
|
if (psrv->ps_slotno > 0) {
|
|
|
|
|
bcopy(oldslots, slots,
|
|
|
|
|
sizeof(*slots) * prison_service_slots);
|
|
|
|
|
}
|
|
|
|
|
pr->pr_slots = slots;
|
|
|
|
|
mtx_unlock(&pr->pr_mtx);
|
|
|
|
|
KASSERT(oldslots != NULL, ("oldslots == NULL"));
|
|
|
|
|
free(oldslots, M_PRISON);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
sx_sunlock(&allprison_lock);
|
|
|
|
|
free(psrv, M_PRISON);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Function sets data for the given jail in slot assigned for the given
|
|
|
|
|
* jail service.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
prison_service_data_set(struct prison_service *psrv, struct prison *pr,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
mtx_assert(&pr->pr_mtx, MA_OWNED);
|
|
|
|
|
pr->pr_slots[psrv->ps_slotno] = data;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Function clears slots assigned for the given jail service in the given
|
|
|
|
|
* prison structure and returns current slot data.
|
|
|
|
|
*/
|
|
|
|
|
void *
|
|
|
|
|
prison_service_data_del(struct prison_service *psrv, struct prison *pr)
|
|
|
|
|
{
|
|
|
|
|
void *data;
|
|
|
|
|
|
|
|
|
|
mtx_assert(&pr->pr_mtx, MA_OWNED);
|
|
|
|
|
data = pr->pr_slots[psrv->ps_slotno];
|
|
|
|
|
pr->pr_slots[psrv->ps_slotno] = NULL;
|
|
|
|
|
return (data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Function returns current data from the slot assigned to the given jail
|
|
|
|
|
* service for the given jail.
|
|
|
|
|
*/
|
|
|
|
|
void *
|
|
|
|
|
prison_service_data_get(struct prison_service *psrv, struct prison *pr)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
mtx_assert(&pr->pr_mtx, MA_OWNED);
|
|
|
|
|
return (pr->pr_slots[psrv->ps_slotno]);
|
|
|
|
|
}
|
|
|
|
|
|
2003-04-09 02:55:18 +00:00
|
|
|
static int
|
|
|
|
|
sysctl_jail_list(SYSCTL_HANDLER_ARGS)
|
|
|
|
|
{
|
|
|
|
|
struct xprison *xp, *sxp;
|
|
|
|
|
struct prison *pr;
|
|
|
|
|
int count, error;
|
|
|
|
|
|
2004-03-15 12:10:34 +00:00
|
|
|
if (jailed(req->td->td_ucred))
|
2004-02-14 19:19:47 +00:00
|
|
|
return (0);
|
2003-04-09 02:55:18 +00:00
|
|
|
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_slock(&allprison_lock);
|
|
|
|
|
if ((count = prisoncount) == 0) {
|
|
|
|
|
sx_sunlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
return (0);
|
2007-04-05 23:19:13 +00:00
|
|
|
}
|
2003-04-09 02:55:18 +00:00
|
|
|
|
|
|
|
|
sxp = xp = malloc(sizeof(*xp) * count, M_TEMP, M_WAITOK | M_ZERO);
|
2007-03-07 21:24:51 +00:00
|
|
|
|
2003-04-09 02:55:18 +00:00
|
|
|
LIST_FOREACH(pr, &allprison, pr_list) {
|
|
|
|
|
xp->pr_version = XPRISON_VERSION;
|
|
|
|
|
xp->pr_id = pr->pr_id;
|
2007-04-08 10:21:38 +00:00
|
|
|
xp->pr_ip = pr->pr_ip;
|
2003-04-09 02:55:18 +00:00
|
|
|
strlcpy(xp->pr_path, pr->pr_path, sizeof(xp->pr_path));
|
2007-04-08 10:21:38 +00:00
|
|
|
mtx_lock(&pr->pr_mtx);
|
2003-04-09 02:55:18 +00:00
|
|
|
strlcpy(xp->pr_host, pr->pr_host, sizeof(xp->pr_host));
|
|
|
|
|
mtx_unlock(&pr->pr_mtx);
|
|
|
|
|
xp++;
|
|
|
|
|
}
|
2007-04-05 23:19:13 +00:00
|
|
|
sx_sunlock(&allprison_lock);
|
2003-04-09 02:55:18 +00:00
|
|
|
|
|
|
|
|
error = SYSCTL_OUT(req, sxp, sizeof(*sxp) * count);
|
|
|
|
|
free(sxp, M_TEMP);
|
2007-03-09 05:22:10 +00:00
|
|
|
return (error);
|
2003-04-09 02:55:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SYSCTL_OID(_security_jail, OID_AUTO, list, CTLTYPE_STRUCT | CTLFLAG_RD,
|
|
|
|
|
NULL, 0, sysctl_jail_list, "S", "List of active jails");
|
2004-02-19 14:29:14 +00:00
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
sysctl_jail_jailed(SYSCTL_HANDLER_ARGS)
|
|
|
|
|
{
|
|
|
|
|
int error, injail;
|
|
|
|
|
|
|
|
|
|
injail = jailed(req->td->td_ucred);
|
|
|
|
|
error = SYSCTL_OUT(req, &injail, sizeof(injail));
|
|
|
|
|
|
|
|
|
|
return (error);
|
|
|
|
|
}
|
|
|
|
|
SYSCTL_PROC(_security_jail, OID_AUTO, jailed, CTLTYPE_INT | CTLFLAG_RD,
|
|
|
|
|
NULL, 0, sysctl_jail_jailed, "I", "Process in jail?");
|
