- Add a cred_free_thread() function (conditional on DIAGNOSTICS) that drops
a per-thread ucred reference to be used in debugging code when leaving
the kernel.
fully protect p_ucred yet so Giant is needed until all the p_ucred
locking is done. This is the original reason td_ucred was not used
immediately after its addition. Unfortunately, not using td_ucred is
not enough to avoid problems. Since p_ucred could be stale, we could
actually be dereferencing a stale pointer to dink with the refcount, so
we really need Giant to avoid foot-shooting. This allows td_ucred to
be safely used as well.
spares (the size of the field was changed from u_short to u_int to
reflect what it really ends up being). Accordingly, change users of
xucred to set and check this field as appropriate. In the kernel,
this is being done inside the new cru2x() routine which takes a
`struct ucred' and fills out a `struct xucred' according to the
former. This also has the pleasant sideaffect of removing some
duplicate code.
Reviewed by: rwatson
New locks are:
- pgrpsess_lock which locks the whole pgrps and sessions,
- pg_mtx which protects the pgrp members, and
- s_mtx which protects the session members.
Please refer to sys/proc.h for the coverage of these locks.
Changes on the pgrp/session interface:
- pgfind() needs the pgrpsess_lock held.
- The caller of enterpgrp() is responsible to allocate a new pgrp and
session.
- Call enterthispgrp() in order to enter an existing pgrp.
- pgsignal() requires a pgrp lock held.
Reviewed by: jhb, alfred
Tested on: cvsup.jp.FreeBSD.org
(which is a quad-CPU machine running -current)
reaquiring it. In the same vein, don't bother dropping the thread cred
when goinf ot userland. We are guaranteed to nned it when we come back,
(which we are guaranteed to do).
Reviewed by: jhb@freebsd.org, bde@freebsd.org (slightly different version)
authorized based on a subject credential rather than a subject process.
This will permit the same logic to be reused in situations where only
the credential generating the signal is available, such as in the
delivery of SIGIO.
- Because of two clauses, the automatic success against curproc,
and the session semantics for SIGCONT, not all logic can be pushed
into cr_cansignal(), but those cases should not apply for most other
consumers of cr_cansignal().
- This brings the base system inter-process authorization code more
into line with the MAC implementation.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
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
- uid's -> uids
- whitespace improvements, linewrap improvements
- reorder copyright more appropriately
- remove redundant MP SAFE comments, add one "NOT MPSAFE?"
for setgroups(), which seems to be the sole un-changed system
call in the file.
- clean up securelevel_g?() functions, improve comments.
Largely submitted by: bde
that new models can inhabit kern.security.<modelname>.
o While I'm there, shorten somewhat excessive variable names, and clean
things up a little.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
- Restore inferior() to being iterative rather than recursive.
- Assert that the proctree_lock is held in inferior() and change the one
caller to get a shared lock of it. This also ensures that we hold the
lock after performing the check so the check can't be made invalid out
from under us after the check but before we act on it.
Requested by: bde
debug another process based on their respective {effective,additional,
saved,real} gid's. p1 is only permitted to debug p2 if its effective
gids (egid + additional groups) are a strict superset of the gids of
p2. This implements properly the security test previously incorrectly
implemented in kern_ktrace.c, and is consistent with the kernel
security policy (although might be slightly confusing for those more
familiar with the userland policy).
o Restructure p_candebug() logic so that various results are generated
comparing uids, gids, credential changes, and then composed in a
single check before testing for privilege. These tests encapsulate
the "BSD" inter-process debugging policy. Other non-BSD checks remain
seperate. Additional comments are added.
Submitted by: tmm, rwatson
Obtained from: TrustedBSD Project
Reviewed by: petef, tmm, rwatson
really be moved elsewhere: p_candebug() encapsulates the security
policy decision, whereas the P_INEXEC check has to do with "correctness"
regarding race conditions, rather than security policy.
Example: even if no security protections were enforced (the "uids are
advisory" model), removing P_INEXEC could result in incorrect operation
due to races on credential evaluation and modification during execve().
Obtained from: TrustedBSD Project
it has not yet returned. Use this flag to deny debugging requests while
the process is execve()ing, and close once and for all any race conditions
that might occur between execve() and various debugging interfaces.
Reviewed by: jhb, rwatson
of Giant during the Giant unwinding phase, and start work on instrumenting
Giant for the file and proc mutexes.
These wrappers allow developers to turn on and off Giant around various
subsystems. DEVELOPERS SHOULD NEVER TURN OFF GIANT AROUND A SUBSYSTEM JUST
BECAUSE THE SYSCTL EXISTS! General developers should only considering
turning on Giant for a subsystem whos default is off (to help track down
bugs). Only developers working on particular subsystems who know what
they are doing should consider turning off Giant.
These wrappers will greatly improve our ability to unwind Giant and test
the kernel on a (mostly) subsystem by subsystem basis. They allow Giant
unwinding developers (GUDs) to emplace appropriate subsystem and structural
mutexes in the main tree and then request that the larger community test
the work by turning off Giant around the subsystem(s), without the larger
community having to mess around with patches. These wrappers also allow
GUDs to boot into a (more likely to be) working system in the midst of
their unwinding work and to test that work under more controlled
circumstances.
There is a master sysctl, kern.giant.all, which defaults to 0 (off). If
turned on it overrides *ALL* other kern.giant sysctls and forces Giant to
be turned on for all wrapped subsystems. If turned off then Giant around
individual subsystems are controlled by various other kern.giant.XXX sysctls.
Code which overlaps multiple subsystems must have all related subsystem Giant
sysctls turned off in order to run without Giant.
- crhold() returns a reference to the ucred whose refcount it bumps.
- crcopy() now simply copies the credentials from one credential to
another and has no return value.
- a new crshared() primitive is added which returns true if a ucred's
refcount is > 1 and false (0) otherwise.
a single kern.security.seeotheruids_permitted, describes as:
"Unprivileged processes may see subjects/objects with different real uid"
NOTE: kern.ps_showallprocs exists in -STABLE, and therefore there is
an API change. kern.ipc.showallsockets does not.
- Check kern.security.seeotheruids_permitted in cr_cansee().
- Replace visibility calls to socheckuid() with cr_cansee() (retain
the change to socheckuid() in ipfw, where it is used for rule-matching).
- Remove prison_unpcb() and make use of cr_cansee() against the UNIX
domain socket credential instead of comparing root vnodes for the
UDS and the process. This allows multiple jails to share the same
chroot() and not see each others UNIX domain sockets.
- Remove unused socheckproc().
Now that cr_cansee() is used universally for socket visibility, a variety
of policies are more consistently enforced, including uid-based
restrictions and jail-based restrictions. This also better-supports
the introduction of additional MAC models.
Reviewed by: ps, billf
Obtained from: TrustedBSD Project
processes to attach debugging to themselves even though the
global kern_unprivileged_procdebug_permitted policy might disallow
this.
o Move the kern_unprivileged_procdebug_permitted check above the
(p1==p2) check.
Reviewed by: des
securelevel_gt(), determine first if a local securelevel exists --
if so, perform the check based on imax(local, global). Otherwise,
simply use the global value.
o Note: even though local securelevels might lag below the global one,
if the global value is updated to higher than local values, maximum
will still be used, making the global dominant even if there is local
lag.
Obtained from: TrustedBSD Project
for securelevel_ge() and securelevel_gt(), I was a little surprised,
but fixed it. Turns out that it was the code that was inverted, during
a whitespace cleanup in my commit tree. This commit inverts the
checks, and restores the comment.
abstract the securelevel implementation details from the checking
code. The call in -CURRENT accepts a struct ucred--in -STABLE, it
will accept struct proc. This facilitates the upcoming commit of
per-jail securelevel support. The calls will also generate a
kernel printf if the calls are made with NULL ucred/proc pointers:
generally speaking, there are few instances of this, and they should
be fixed.
o Update p_candebug() to use securelevel_gt(); future updates to the
remainder of the kernel tree will be committed soon.
Obtained from: TrustedBSD Project
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
by renaming it to kern.security.suser_enabled. This makes the name
consistent with other use: "permitted" now refers to a specific right
or privilege, whereas "enabled" refers to a feature. As this hasn't
been MFC'd, and using this destroys a running system currently, I believe
the user base of the sysctl will not be too unhappy.
o While I'm at it, un-staticize and export the supporting variable, as it
will be used by kern_cap.c shortly.
Obtained from: TrustedBSD Project
of debugging the current process when that is in conflict with other
restrictions (such as jail, unprivileged_procdebug_permitted, etc).
o This corrects anomolies in the behavior of
kern.security.unprivileged_procdebug_permitted when using truss and
ktrace. The theory goes that this is now safe to use.
Obtained from: TrustedBSD Project
MIB entries.
o Relocate kern.suser_permitted to kern.security.suser_permitted.
o Introduce new kern.security.unprivileged_procdebug_permitted, which
(when set to 0) prevents processes without privilege from performing
a variety of inter-process debugging activities. The default is 1,
to provide current behavior.
This feature allows "hardened" systems to disable access to debugging
facilities, which have been associated with a number of past security
vulnerabilities. Previously, while procfs could be unmounted, other
in-kernel facilities (such as ptrace()) were still available. This
setting should not be modified on normal development systems, as it
will result in frustration. Some utilities respond poorly to
failing to get the debugging access they require, and error response
by these utilities may be improved in the future in the name of
beautification.
Note that there are currently some odd interactions with some
facilities, which will need to be resolved before this should be used
in production, including odd interactions with truss and ktrace.
Note also that currently, tracing is permitted on the current process
regardless of this flag, for compatibility with previous
authorization code in various facilities, but that will probably
change (and resolve the odd interactions).
Obtained from: TrustedBSD Project
The p_can(...) construct was a premature (and, it turns out,
awkward) abstraction. The individual calls to p_canxxx() better
reflect differences between the inter-process authorization checks,
such as differing checks based on the type of signal. This has
a side effect of improving code readability.
o Replace direct credential authorization checks in ktrace() with
invocation of p_candebug(), while maintaining the special case
check of KTR_ROOT. This allows ktrace() to "play more nicely"
with new mandatory access control schemes, as well as making its
authorization checks consistent with other "debugging class"
checks.
o Eliminate "privused" construct for p_can*() calls which allowed the
caller to determine if privilege was required for successful
evaluation of the access control check. This primitive is currently
unused, and as such, serves only to complicate the API.
Approved by: ({procfs,linprocfs} changes) des
Obtained from: TrustedBSD Project
real uid, saved uid, real gid, and saved gid to ucred, as well as the
pcred->pc_uidinfo, which was associated with the real uid, only rename
it to cr_ruidinfo so as not to conflict with cr_uidinfo, which
corresponds to the effective uid.
o Remove p_cred from struct proc; add p_ucred to struct proc, replacing
original macro that pointed.
p->p_ucred to p->p_cred->pc_ucred.
o Universally update code so that it makes use of ucred instead of pcred,
p->p_ucred instead of p->p_pcred, cr_ruidinfo instead of p_uidinfo,
cr_{r,sv}{u,g}id instead of p_*, etc.
o Remove pcred0 and its initialization from init_main.c; initialize
cr_ruidinfo there.
o Restruction many credential modification chunks to always crdup while
we figure out locking and optimizations; generally speaking, this
means moving to a structure like this:
newcred = crdup(oldcred);
...
p->p_ucred = newcred;
crfree(oldcred);
It's not race-free, but better than nothing. There are also races
in sys_process.c, all inter-process authorization, fork, exec, and
exit.
o Remove sigio->sio_ruid since sigio->sio_ucred now contains the ruid;
remove comments indicating that the old arrangement was a problem.
o Restructure exec1() a little to use newcred/oldcred arrangement, and
use improved uid management primitives.
o Clean up exit1() so as to do less work in credential cleanup due to
pcred removal.
o Clean up fork1() so as to do less work in credential cleanup and
allocation.
o Clean up ktrcanset() to take into account changes, and move to using
suser_xxx() instead of performing a direct uid==0 comparision.
o Improve commenting in various kern_prot.c credential modification
calls to better document current behavior. In a couple of places,
current behavior is a little questionable and we need to check
POSIX.1 to make sure it's "right". More commenting work still
remains to be done.
o Update credential management calls, such as crfree(), to take into
account new ruidinfo reference.
o Modify or add the following uid and gid helper routines:
change_euid()
change_egid()
change_ruid()
change_rgid()
change_svuid()
change_svgid()
In each case, the call now acts on a credential not a process, and as
such no longer requires more complicated process locking/etc. They
now assume the caller will do any necessary allocation of an
exclusive credential reference. Each is commented to document its
reference requirements.
o CANSIGIO() is simplified to require only credentials, not processes
and pcreds.
o Remove lots of (p_pcred==NULL) checks.
o Add an XXX to authorization code in nfs_lock.c, since it's
questionable, and needs to be considered carefully.
o Simplify posix4 authorization code to require only credentials, not
processes and pcreds. Note that this authorization, as well as
CANSIGIO(), needs to be updated to use the p_cansignal() and
p_cansched() centralized authorization routines, as they currently
do not take into account some desirable restrictions that are handled
by the centralized routines, as well as being inconsistent with other
similar authorization instances.
o Update libkvm to take these changes into account.
Obtained from: TrustedBSD Project
Reviewed by: green, bde, jhb, freebsd-arch, freebsd-audit
