History log of /freebsd/sys/kern/kern_jail.c (Results 76 – 100 of 583)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 2a4b2251 10-Jan-2021 Jamie Gritton <jamie@FreeBSD.org>

jail: Simplify handling of prison_deref()

Track the the current lock/reference state in a single variable,
rather than deducing the proper prison_deref() flags from a
combination of equations and ha

jail: Simplify handling of prison_deref()

Track the the current lock/reference state in a single variable,
rather than deducing the proper prison_deref() flags from a
combination of equations and hard-coded values.

show more ...


# b58a4634 01-Jan-2021 Jamie Gritton <jamie@FreeBSD.org>

jail: revert the attachment part of b4e87a632955

The change to kern_jail_set that was supposed to "also properly clean
up when attachment fails" didn't fix a memory leak but actually caused
a double

jail: revert the attachment part of b4e87a632955

The change to kern_jail_set that was supposed to "also properly clean
up when attachment fails" didn't fix a memory leak but actually caused
a double free. Back that part out, and leave the part that manages
allprison_lock state.

show more ...


# b4e87a63 01-Jan-2021 Jamie Gritton <jamie@FreeBSD.org>

jail: Clean up allprison_lock handing in kern_jail_set

Keep explicit track of the allprison_lock state during the final part
of kern_jail_set, instead of deducing it from the JAIL_ATTACH flag.

Also

jail: Clean up allprison_lock handing in kern_jail_set

Keep explicit track of the allprison_lock state during the final part
of kern_jail_set, instead of deducing it from the JAIL_ATTACH flag.

Also properly clean up when the attachment fails, fixing a long-
standing (though minor) memory leak.

show more ...


# 7f4e7248 27-Dec-2020 Jamie Gritton <jamie@FreeBSD.org>

jail: add a missing lock around an osd_jail_call().

allprison_lock should be at least held shared when jail OSD methods
are called. Add a shared lock around one such call where that wasn't
the case

jail: add a missing lock around an osd_jail_call().

allprison_lock should be at least held shared when jail OSD methods
are called. Add a shared lock around one such call where that wasn't
the case.

In another such call, change an exclusive lock grab to be shared in
what is likely the more common case.

show more ...


# 0fe74ae6 27-Dec-2020 Jamie Gritton <jamie@FreeBSD.org>

jail: Consistently handle the pr_allow bitmask

Return a boolean (i.e. 0 or 1) from prison_allow, instead of the flag
value itself, which is what sysctl expects.

Add prison_set_allow(), which can se

jail: Consistently handle the pr_allow bitmask

Return a boolean (i.e. 0 or 1) from prison_allow, instead of the flag
value itself, which is what sysctl expects.

Add prison_set_allow(), which can set or clear a permission bit, and
propagates cleared bits down to child jails.

Use prison_allow() and prison_set_allow() in the various jail.allow.*
sysctls, and others that depend on thoe permissions.

Add locking around checking both pr_allow and pr_enforce_statfs in
prison_priv_check().

show more ...


# 5d58f959 26-Dec-2020 Jamie Gritton <jamie@FreeBSD.org>

jail: Fix lock-free access to dynamic pr.allow flags

Use atomic access and a memory barrier to ensure that the flag parameter
in pr_flag_allow is indeed set after the rest of the structure is valid.

jail: Fix lock-free access to dynamic pr.allow flags

Use atomic access and a memory barrier to ensure that the flag parameter
in pr_flag_allow is indeed set after the rest of the structure is valid.

Simplify adding flag bits with pr_allow_all, a dynamic version of
PR_ALLOW_ALL_STATIC.

show more ...


# 7de883c8 26-Dec-2020 Jamie Gritton <jamie@FreeBSD.org>

jail: Fix an O(n^2) loop when adding jails

When a jail is added using the default (system-chosen) JID, and
non-default-JID jails already exist, a loop through the allprison
list could restart and re

jail: Fix an O(n^2) loop when adding jails

When a jail is added using the default (system-chosen) JID, and
non-default-JID jails already exist, a loop through the allprison
list could restart and result in unnecessary O(n^2) behaviour.
There should never be more than two list passes required.

Also clean up inefficient (though still O(n)) allprison list traversal
when finding jails by ID, or when adding jails in the common case of
all default JIDs.

show more ...


# 05e1e482 18-Nov-2020 Mariusz Zaborski <oshogbo@FreeBSD.org>

jail: introduce per jail suser_enabled setting

The suser_enable sysctl allows to remove a privileged rights from uid 0.
This change introduce per jail setting which allow to make root a
normal user.

jail: introduce per jail suser_enabled setting

The suser_enable sysctl allows to remove a privileged rights from uid 0.
This change introduce per jail setting which allow to make root a
normal user.

Reviewed by: jamie
Previous version reviewed by: kevans, emaste, markj, me_igalic.co
Discussed with: pjd
Differential Revision: https://reviews.freebsd.org/D27128

show more ...


# 21fe9441 18-Nov-2020 Mariusz Zaborski <oshogbo@FreeBSD.org>

Fix style nits.


Revision tags: release/12.2.0
# 6fed89b1 02-Sep-2020 Mateusz Guzik <mjg@FreeBSD.org>

kern: clean up empty lines in .c and .h files


# e2515283 27-Aug-2020 Glen Barber <gjb@FreeBSD.org>

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)


# a459a6cf 25-Aug-2020 Mateusz Guzik <mjg@FreeBSD.org>

vfs: respect PRIV_VFS_LOOKUP in vaccess_smr

Reported by: novel


# c7aa572c 31-Jul-2020 Glen Barber <gjb@FreeBSD.org>

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)


# f7d38a13 19-Jul-2020 Adrian Chadd <adrian@FreeBSD.org>

[net80211] Add new privileges; restrict what can be done in a jail.

Split the MANAGE privilege into MANAGE, SETMAC and CREATE_VAP.

+ VAP_MANAGE is everything but setting the MAC and creating a VAP.

[net80211] Add new privileges; restrict what can be done in a jail.

Split the MANAGE privilege into MANAGE, SETMAC and CREATE_VAP.

+ VAP_MANAGE is everything but setting the MAC and creating a VAP.
+ VAP_SETMAC is setting the MAC address of the VAP.
Typically you wouldn't want the jail to be able to modify this.
+ CREATE_VAP is to create a new VAP. Again, you don't want to be doing
this in a jail, but this DOES stop being able to run some corner
cases like Dynamic WDS (DWDS) AP in a jail/vnet. We can figure this
bit out later.

This allows me to run wpa_supplicant in a jail after transferring
a STA VAP into it. I unfortunately can't currently set the wlan
debugging inside the jail; that would be super useful!

Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D25630

show more ...


Revision tags: release/11.4.0
# 63619b6d 04-Jun-2020 Kyle Evans <kevans@FreeBSD.org>

vfs: add restrictions to read(2) of a directory [2/2]

This commit adds the priv(9) that waters down the sysctl to make it only
allow read(2) of a dirfd by the system root. Jailed root is not allowed

vfs: add restrictions to read(2) of a directory [2/2]

This commit adds the priv(9) that waters down the sysctl to make it only
allow read(2) of a dirfd by the system root. Jailed root is not allowed, but
jail policy and superuser policy will abstain from allowing/denying it so
that a MAC module can fully control the policy.

Such a MAC module has been written, and can be found at:
https://people.freebsd.org/~kevans/mac_read_dir-0.1.0.tar.gz

It is expected that the MAC module won't be needed by many, as most only
need to do such diagnostics that require this behavior as system root
anyways. Interested parties are welcome to grab the MAC module above and
create a port or locally integrate it, and with enough support it could see
introduction to base. As noted in mac_read_dir.c, it is released under the
BSD 2 clause license and allows the restrictions to be lifted for only
jailed root or for all unprivileged users.

PR: 246412
Reviewed by: mckusick, kib, emaste, jilles, cy, phk, imp (all previous)
Reviewed by: rgrimes (latest version)
Differential Revision: https://reviews.freebsd.org/D24596

show more ...


# 3f8bc99c 18-Apr-2020 Kristof Provost <kp@FreeBSD.org>

ethersubr: Make the mac address generation more robust

If we create two (vnet) jails and create a bridge interface in each we end up
with the same mac address on both bridge interfaces.
These very o

ethersubr: Make the mac address generation more robust

If we create two (vnet) jails and create a bridge interface in each we end up
with the same mac address on both bridge interfaces.
These very often conflicts, resulting in same mac address in both jails.

Mitigate this problem by including the jail name in the mac address.

Reviewed by: kevans, melifaro
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24383

show more ...


# c3188289 16-Apr-2020 Kyle Evans <kevans@FreeBSD.org>

Preload hostuuid for early-boot use

prison0's hostuuid will get set by the hostid rc script, either after
generating it and saving it to /etc/hostid or by simply reading /etc/hostid.

Some things (e

Preload hostuuid for early-boot use

prison0's hostuuid will get set by the hostid rc script, either after
generating it and saving it to /etc/hostid or by simply reading /etc/hostid.

Some things (e.g. arbitrary MAC address generation) may use the hostuuid as
a factor in early boot, so providing a way to read /etc/hostid (if it's
available) and using it before userland starts up is desirable. The code is
written such that the preload doesn't *have* to be /etc/hostid, thus not
assuming that there will be newline at the end of the buffer or even the
exact shape of the newline. White trailing whitespace/non-printables
trimmed, the result will be validated as a valid uuid before it's used for
early boot purposes.

The preload can be turned off with hostuuid_load="NO" in /boot/loader.conf,
just as other preloads; it's worth noting that this is a 37-byte file, the
overhead is believed to be generally minimal.

It doesn't seem necessary at this time to be concerned with kern.hostid.

One does wonder if we should consider validating hostuuids coming in
via jail_set(2); some bits seem to care about uuid form and we bother
validating format of smbios-provided uuid and in-fact whatever uuid comes
from /etc/hostid.

Reviewed by: karels, delphij, jamie
MFC after: 1 week (don't preload by default, probably)
Differential Revision: https://reviews.freebsd.org/D24288

show more ...


# 1b786d01 14-Mar-2020 Bjoern A. Zeeb <bz@FreeBSD.org>

kern_jail: missing \0 termination check on osrelease parameter

If a user spplies a non-\0 terminated osrelease parameter reading it back
may disclose kernel memory.
This is a problem in case of nest

kern_jail: missing \0 termination check on osrelease parameter

If a user spplies a non-\0 terminated osrelease parameter reading it back
may disclose kernel memory.
This is a problem in case of nested jails (children.max > 0, which is not
the default). Otherwise root outside the jail has access to kernel memory
by other means and root inside a jail cannot create a child jail.

Add the proper \0 check at the end of a supplied osrelease parameter and
make sure any copies of the field will be \0-terminated.

Submitted by: Hans Christian Woithe (chwoithe yahoo.com)
MFC after: 3 days

show more ...


# 75dfc66c 27-Feb-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r358269 through r358399.


# 7029da5c 26-Feb-2020 Pawel Biernacki <kaktus@FreeBSD.org>

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly mark

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT

Approved by: kib (mentor, blanket)
Commented by: kib, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D23718

show more ...


# 74dc6beb 14-Feb-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r357855 through r357920.


# 7b2ff0dc 13-Feb-2020 Mateusz Guzik <mjg@FreeBSD.org>

Partially decompose priv_check by adding priv_check_cred_vfs_generation

During buildkernel there are very frequent calls to priv_check and they
all are for PRIV_VFS_GENERATION (coming from stat/fsta

Partially decompose priv_check by adding priv_check_cred_vfs_generation

During buildkernel there are very frequent calls to priv_check and they
all are for PRIV_VFS_GENERATION (coming from stat/fstat).

This results in branching on several potential privileges checking if
perhaps that's the one which has to be evaluated.

Instead of the kitchen-sink approach provide a way to have commonly used
privs directly evaluated.

show more ...


# e6081fe8 13-Feb-2020 Mateusz Guzik <mjg@FreeBSD.org>

Inline jailed().

It is constantly called from priv_check.


# 44e86fbd 13-Feb-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r357662 through r357854.


# 3eb6b656 08-Feb-2020 Mateusz Guzik <mjg@FreeBSD.org>

vfs: remove now useless ENODEV handling from vn_fullpath consumers

Noted by: ngie


12345678910>>...24