mirror of
https://github.com/freebsd/freebsd-src
synced 2024-10-22 16:29:38 +00:00
800c940832
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>
141 lines
4.3 KiB
Groff
141 lines
4.3 KiB
Groff
.\"
|
|
.\" Copyright (c) 1996 Julian R Elischer
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" This code is derived from software contributed by Kenneth Stailey.
|
|
.\"
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
.\" modification, are permitted provided that the following conditions
|
|
.\" are met:
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
|
.\" must display the following acknowledgement:
|
|
.\" This product includes software developed for the FreeBSD Project
|
|
.\" by Julian R Elischer
|
|
.\" 4. The name of the author may not be used to endorse or promote products
|
|
.\" derived from this software without specific prior written permission.
|
|
.\"
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
|
.\" BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
.\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
|
.\" AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
.\" SUCH DAMAGE.
|
|
.\"
|
|
.\" $FreeBSD$
|
|
.\"
|
|
.Dd April 2, 2002
|
|
.Dt SUSER 9
|
|
.Os
|
|
.Sh NAME
|
|
.Nm suser ,
|
|
.Nm suser_cred
|
|
.Nd check if credentials have superuser privileges
|
|
.Sh SYNOPSIS
|
|
.In sys/param.h
|
|
.In sys/systm.h
|
|
.Ft int
|
|
.Fn suser "struct thread *td"
|
|
.Ft int
|
|
.Fn suser_cred "struct ucred *cred" "int flag"
|
|
.Sh DESCRIPTION
|
|
The
|
|
.Fn suser
|
|
and
|
|
.Fn suser_cred
|
|
functions check if the credentials given include superuser powers.
|
|
.Pp
|
|
These interfaces have now been obsoleted by
|
|
.Xr priv 9 ,
|
|
and are provided only for compatibility with third party kernel modules that
|
|
have not yet been updated to the new interface.
|
|
They should not be used in any new kernel code.
|
|
.Pp
|
|
The
|
|
.Fn suser
|
|
function is the most common, and should be used unless special
|
|
circumstances dictate otherwise.
|
|
.Pp
|
|
The
|
|
.Fn suser_cred
|
|
function should be used when the credentials to be checked are
|
|
not the thread's own, when there is no thread, when superuser
|
|
powers should be extended to imprisoned roots, or when the credential
|
|
to be checked is the real user rather than the effective user.
|
|
.Pp
|
|
By default, a process does not command superuser powers if it has
|
|
been imprisoned by the
|
|
.Xr jail 2
|
|
system call.
|
|
There are cases however where this is appropriate, and this can
|
|
be done by passing
|
|
.Dv SUSER_ALLOWJAIL
|
|
in the
|
|
.Fa flag
|
|
argument to the
|
|
.Fn suser_cred
|
|
function.
|
|
It is important to review carefully in each case that
|
|
this does not weaken the prison.
|
|
Generally, only where the action is protected by
|
|
.Xr chroot 2
|
|
implicit in the
|
|
.Xr jail 2
|
|
call should such powers be granted.
|
|
.Pp
|
|
By default, the credential checked is the effective user.
|
|
There are cases
|
|
where it is instead necessary to check the real user (for example, when
|
|
determining if resource limits should be applied), and this can be done
|
|
by passing the
|
|
.Dv SUSER_RUID
|
|
flag in the
|
|
.Fa flag
|
|
argument to the
|
|
.Fn suser_cred
|
|
function.
|
|
.Pp
|
|
The
|
|
.Fn suser
|
|
and
|
|
.Fn suser_cred
|
|
functions note the fact that superuser powers have been used in the
|
|
process structure of the process specified.
|
|
Because part of their function is to notice
|
|
whether superuser powers have been used,
|
|
the functions should only be called after other permission
|
|
possibilities have been exhausted.
|
|
.Sh RETURN VALUES
|
|
The
|
|
.Fn suser
|
|
and
|
|
.Fn suser_cred
|
|
functions return 0 if the user has superuser powers and
|
|
.Er EPERM
|
|
otherwise.
|
|
This is the
|
|
.Em reverse logic
|
|
of some other implementations of
|
|
.Fn suser
|
|
in which a TRUE response indicates superuser powers.
|
|
.Sh SEE ALSO
|
|
.Xr chroot 2 ,
|
|
.Xr jail 2 ,
|
|
.Xr priv 9
|
|
.Sh BUGS
|
|
The
|
|
.Fn suser
|
|
and
|
|
.Fn suser_cred
|
|
functions do not, in fact, record that superuser privileges have been
|
|
used, and have not done so since August 2000.
|