Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/sys/secmodel/extensions/secmodel_extensions.c

509 lines
13 KiB
C
Raw Permalink Normal View History

Introduce KAUTH_REQ_PROCESS_CANSEE_KPTR, and use it in the already-existing modstat code. No real functional change.
2018-09-04 17:31:18 +03:00
/* $NetBSD: secmodel_extensions.c,v 1.10 2018/09/04 14:31:19 maxv Exp $ */
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
/*-
* Copyright (c) 2011 Elad Efrat <elad@NetBSD.org>
* All rights reserved.
*
* 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. 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.
*/
#include <sys/cdefs.h>
Introduce KAUTH_REQ_PROCESS_CANSEE_KPTR, and use it in the already-existing modstat code. No real functional change.
2018-09-04 17:31:18 +03:00
__KERNEL_RCSID(0, "$NetBSD: secmodel_extensions.c,v 1.10 2018/09/04 14:31:19 maxv Exp $");
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
#include <sys/types.h>
#include <sys/param.h>
#include <sys/kauth.h>
#include <sys/mount.h>
#include <sys/vnode.h>
#include <sys/socketvar.h>
#include <sys/sysctl.h>
#include <sys/proc.h>
Add new sysctl(3) entry: security.models.extensions.user_set_dbregs Model this new sysctl(3) entry after "user_set_cpu_affinity" in the same level of sysctl(3) switches. Allow to read unconditionally Debug Registers (no change here). This is convenient as even if a user of a debugger does not use hardware assisted watchpoints/breakpoints, a debugger can still prompt these values to store in an internal cache with context of registers. Reading them should have no security concerns. Add a paranoid MI switch that prohibits by default setting these registers by a regular user (non-superuser). Make this switch disabled by default. There are enough reserved bits out there to allow using them unconditionally on hardened hosts. Features shipped with Debug Registers are optional features in debuggers. There is no reduction in elementary functionality. Reviewed by <christos> Sponsored by <The NetBSD Foundation>
2018-04-08 17:46:32 +03:00
#include <sys/ptrace.h>
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
#include <sys/module.h>
#include <secmodel/secmodel.h>
#include <secmodel/extensions/extensions.h>
MODULE(MODULE_CLASS_SECMODEL, extensions, NULL);
Replace the remaining KAUTH_GENERIC_ISSUSER authorization calls with something meaningful. All relevant documentation has been updated or written. Most of these changes were brought up in the following messages: http://mail-index.netbsd.org/tech-kern/2012/01/18/msg012490.html http://mail-index.netbsd.org/tech-kern/2012/01/19/msg012502.html http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012728.html Thanks to christos, manu, njoly, and jmmv for input. Huge thanks to pgoyette for spinning these changes through some build cycles and ATF.
2012-03-13 22:40:26 +04:00
static int dovfsusermount;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
static int curtain;
static int user_set_cpu_affinity;
Add new sysctl(3) entry: security.models.extensions.user_set_dbregs Model this new sysctl(3) entry after "user_set_cpu_affinity" in the same level of sysctl(3) switches. Allow to read unconditionally Debug Registers (no change here). This is convenient as even if a user of a debugger does not use hardware assisted watchpoints/breakpoints, a debugger can still prompt these values to store in an internal cache with context of registers. Reading them should have no security concerns. Add a paranoid MI switch that prohibits by default setting these registers by a regular user (non-superuser). Make this switch disabled by default. There are enough reserved bits out there to allow using them unconditionally on hardened hosts. Features shipped with Debug Registers are optional features in debuggers. There is no reduction in elementary functionality. Reviewed by <christos> Sponsored by <The NetBSD Foundation>
2018-04-08 17:46:32 +03:00
#ifdef PT_SETDBREGS
int user_set_dbregs;
#endif
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
static kauth_listener_t l_system, l_process, l_network;
static secmodel_t extensions_sm;
static struct sysctllog *extensions_sysctl_log;
static void secmodel_extensions_init(void);
static void secmodel_extensions_start(void);
static void secmodel_extensions_stop(void);
static void sysctl_security_extensions_setup(struct sysctllog **);
static int sysctl_extensions_user_handler(SYSCTLFN_PROTO);
static int sysctl_extensions_curtain_handler(SYSCTLFN_PROTO);
static bool is_securelevel_above(int);
static int secmodel_extensions_system_cb(kauth_cred_t, kauth_action_t,
void *, void *, void *, void *, void *);
static int secmodel_extensions_process_cb(kauth_cred_t, kauth_action_t,
void *, void *, void *, void *, void *);
static int secmodel_extensions_network_cb(kauth_cred_t, kauth_action_t,
void *, void *, void *, void *, void *);
static void
sysctl_security_extensions_setup(struct sysctllog **clog)
{
Re-instate backwards compatible security.models.bsd44.{curtain,securelevel}. They were mistakenly removed when curtain and securelevel moved to secmodel_extensions(9). Reported by tls@ on tech-security@. XXX will ask for pull-up for -6.
2013-01-28 04:51:29 +04:00
const struct sysctlnode *rnode, *rnode2;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
sysctl_createv(clog, 0, NULL, &rnode,
CTLFLAG_PERMANENT,
CTLTYPE_NODE, "models", NULL,
NULL, 0, NULL, 0,
Ensure that the top level sysctl nodes (kern, vfs, net, ...) exist before the sysctl link sets are processed, and remove redundancy. Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate lines of code.
2014-02-25 22:30:08 +04:00
CTL_SECURITY, CTL_CREATE, CTL_EOL);
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
Re-instate backwards compatible security.models.bsd44.{curtain,securelevel}. They were mistakenly removed when curtain and securelevel moved to secmodel_extensions(9). Reported by tls@ on tech-security@. XXX will ask for pull-up for -6.
2013-01-28 04:51:29 +04:00
/* Compatibility: security.models.bsd44 */
rnode2 = rnode;
sysctl_createv(clog, 0, &rnode2, &rnode2,
CTLFLAG_PERMANENT,
CTLTYPE_NODE, "bsd44", NULL,
NULL, 0, NULL, 0,
CTL_CREATE, CTL_EOL);
/* Compatibility: security.models.bsd44.curtain */
sysctl_createv(clog, 0, &rnode2, NULL,
CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
CTLTYPE_INT, "curtain",
SYSCTL_DESCR("Curtain information about objects to "\
"users not owning them."),
sysctl_extensions_curtain_handler, 0, &curtain, 0,
CTL_CREATE, CTL_EOL);
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
sysctl_createv(clog, 0, &rnode, &rnode,
CTLFLAG_PERMANENT,
CTLTYPE_NODE, "extensions", NULL,
NULL, 0, NULL, 0,
CTL_CREATE, CTL_EOL);
sysctl_createv(clog, 0, &rnode, NULL,
CTLFLAG_PERMANENT,
CTLTYPE_STRING, "name", NULL,
NULL, 0, __UNCONST(SECMODEL_EXTENSIONS_NAME), 0,
CTL_CREATE, CTL_EOL);
sysctl_createv(clog, 0, &rnode, NULL,
CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
CTLTYPE_INT, "usermount",
SYSCTL_DESCR("Whether unprivileged users may mount "
"filesystems"),
sysctl_extensions_user_handler, 0, &dovfsusermount, 0,
CTL_CREATE, CTL_EOL);
sysctl_createv(clog, 0, &rnode, NULL,
CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
CTLTYPE_INT, "curtain",
SYSCTL_DESCR("Curtain information about objects to "\
"users not owning them."),
sysctl_extensions_curtain_handler, 0, &curtain, 0,
CTL_CREATE, CTL_EOL);
sysctl_createv(clog, 0, &rnode, NULL,
CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
CTLTYPE_INT, "user_set_cpu_affinity",
SYSCTL_DESCR("Whether unprivileged users may control "\
"CPU affinity."),
sysctl_extensions_user_handler, 0,
&user_set_cpu_affinity, 0,
CTL_CREATE, CTL_EOL);
Add new sysctl(3) entry: security.models.extensions.user_set_dbregs Model this new sysctl(3) entry after "user_set_cpu_affinity" in the same level of sysctl(3) switches. Allow to read unconditionally Debug Registers (no change here). This is convenient as even if a user of a debugger does not use hardware assisted watchpoints/breakpoints, a debugger can still prompt these values to store in an internal cache with context of registers. Reading them should have no security concerns. Add a paranoid MI switch that prohibits by default setting these registers by a regular user (non-superuser). Make this switch disabled by default. There are enough reserved bits out there to allow using them unconditionally on hardened hosts. Features shipped with Debug Registers are optional features in debuggers. There is no reduction in elementary functionality. Reviewed by <christos> Sponsored by <The NetBSD Foundation>
2018-04-08 17:46:32 +03:00
#ifdef PT_SETDBREGS
sysctl_createv(clog, 0, &rnode, NULL,
CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
CTLTYPE_INT, "user_set_dbregs",
SYSCTL_DESCR("Whether unprivileged users may set "\
"CPU Debug Registers."),
sysctl_extensions_user_handler, 0,
&user_set_dbregs, 0,
CTL_CREATE, CTL_EOL);
#endif
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
/* Compatibility: vfs.generic.usermount */
sysctl_createv(clog, 0, NULL, NULL,
CTLFLAG_PERMANENT,
CTLTYPE_NODE, "generic",
SYSCTL_DESCR("Non-specific vfs related information"),
NULL, 0, NULL, 0,
CTL_VFS, VFS_GENERIC, CTL_EOL);
sysctl_createv(clog, 0, NULL, NULL,
CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
CTLTYPE_INT, "usermount",
SYSCTL_DESCR("Whether unprivileged users may mount "
"filesystems"),
sysctl_extensions_user_handler, 0, &dovfsusermount, 0,
CTL_VFS, VFS_GENERIC, VFS_USERMOUNT, CTL_EOL);
/* Compatibility: security.curtain */
Ensure that the top level sysctl nodes (kern, vfs, net, ...) exist before the sysctl link sets are processed, and remove redundancy. Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate lines of code.
2014-02-25 22:30:08 +04:00
sysctl_createv(clog, 0, NULL, NULL,
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
CTLTYPE_INT, "curtain",
SYSCTL_DESCR("Curtain information about objects to "\
"users not owning them."),
sysctl_extensions_curtain_handler, 0, &curtain, 0,
Ensure that the top level sysctl nodes (kern, vfs, net, ...) exist before the sysctl link sets are processed, and remove redundancy. Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate lines of code.
2014-02-25 22:30:08 +04:00
CTL_SECURITY, CTL_CREATE, CTL_EOL);
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
}
static int
sysctl_extensions_curtain_handler(SYSCTLFN_ARGS)
{
struct sysctlnode node;
int val, error;
val = *(int *)rnode->sysctl_data;
node = *rnode;
node.sysctl_data = &val;
error = sysctl_lookup(SYSCTLFN_CALL(&node));
if (error || newp == NULL)
return error;
/* shortcut */
if (val == *(int *)rnode->sysctl_data)
return 0;
/* curtain cannot be disabled when securelevel is above 0 */
if (val == 0 && is_securelevel_above(0)) {
return EPERM;
}
*(int *)rnode->sysctl_data = val;
return 0;
}
/*
* Generic sysctl extensions handler for user mount and set CPU affinity
* rights. Checks the following conditions:
* - setting value to 0 is always permitted (decrease user rights)
* - setting value != 0 is not permitted when securelevel is above 0 (increase
* user rights).
*/
static int
sysctl_extensions_user_handler(SYSCTLFN_ARGS)
{
struct sysctlnode node;
int val, error;
val = *(int *)rnode->sysctl_data;
node = *rnode;
node.sysctl_data = &val;
error = sysctl_lookup(SYSCTLFN_CALL(&node));
if (error || newp == NULL)
return error;
/* shortcut */
if (val == *(int *)rnode->sysctl_data)
return 0;
/* we cannot grant more rights to users when securelevel is above 0 */
if (val != 0 && is_securelevel_above(0)) {
return EPERM;
}
*(int *)rnode->sysctl_data = val;
return 0;
}
/*
* Query secmodel_securelevel(9) to know whether securelevel is strictly
* above 'level' or not.
* Returns true if it is, false otherwise (when securelevel is absent or
* securelevel is at or below 'level').
*/
static bool
is_securelevel_above(int level)
{
bool above;
int error;
error = secmodel_eval("org.netbsd.secmodel.securelevel",
"is-securelevel-above", KAUTH_ARG(level), &above);
if (error == 0 && above)
return true;
else
return false;
}
static void
secmodel_extensions_init(void)
{
curtain = 0;
user_set_cpu_affinity = 0;
Add new sysctl(3) entry: security.models.extensions.user_set_dbregs Model this new sysctl(3) entry after "user_set_cpu_affinity" in the same level of sysctl(3) switches. Allow to read unconditionally Debug Registers (no change here). This is convenient as even if a user of a debugger does not use hardware assisted watchpoints/breakpoints, a debugger can still prompt these values to store in an internal cache with context of registers. Reading them should have no security concerns. Add a paranoid MI switch that prohibits by default setting these registers by a regular user (non-superuser). Make this switch disabled by default. There are enough reserved bits out there to allow using them unconditionally on hardened hosts. Features shipped with Debug Registers are optional features in debuggers. There is no reduction in elementary functionality. Reviewed by <christos> Sponsored by <The NetBSD Foundation>
2018-04-08 17:46:32 +03:00
#ifdef PT_SETDBREGS
user_set_dbregs = 0;
#endif
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
}
static void
secmodel_extensions_start(void)
{
l_system = kauth_listen_scope(KAUTH_SCOPE_SYSTEM,
secmodel_extensions_system_cb, NULL);
l_process = kauth_listen_scope(KAUTH_SCOPE_PROCESS,
secmodel_extensions_process_cb, NULL);
l_network = kauth_listen_scope(KAUTH_SCOPE_NETWORK,
secmodel_extensions_network_cb, NULL);
}
static void
secmodel_extensions_stop(void)
{
kauth_unlisten_scope(l_system);
kauth_unlisten_scope(l_process);
kauth_unlisten_scope(l_network);
}
static int
extensions_modcmd(modcmd_t cmd, void *arg)
{
int error = 0;
switch (cmd) {
case MODULE_CMD_INIT:
error = secmodel_register(&extensions_sm,
SECMODEL_EXTENSIONS_ID, SECMODEL_EXTENSIONS_NAME,
NULL, NULL, NULL);
if (error != 0)
printf("extensions_modcmd::init: secmodel_register "
"returned %d\n", error);
secmodel_extensions_init();
secmodel_extensions_start();
sysctl_security_extensions_setup(&extensions_sysctl_log);
break;
case MODULE_CMD_FINI:
sysctl_teardown(&extensions_sysctl_log);
secmodel_extensions_stop();
error = secmodel_deregister(extensions_sm);
if (error != 0)
printf("extensions_modcmd::fini: secmodel_deregister "
"returned %d\n", error);
break;
case MODULE_CMD_AUTOUNLOAD:
error = EPERM;
break;
default:
error = ENOTTY;
break;
}
return (error);
}
static int
secmodel_extensions_system_cb(kauth_cred_t cred, kauth_action_t action,
void *cookie, void *arg0, void *arg1, void *arg2, void *arg3)
{
Replace the remaining KAUTH_GENERIC_ISSUSER authorization calls with something meaningful. All relevant documentation has been updated or written. Most of these changes were brought up in the following messages: http://mail-index.netbsd.org/tech-kern/2012/01/18/msg012490.html http://mail-index.netbsd.org/tech-kern/2012/01/19/msg012502.html http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012728.html Thanks to christos, manu, njoly, and jmmv for input. Huge thanks to pgoyette for spinning these changes through some build cycles and ATF.
2012-03-13 22:40:26 +04:00
vnode_t *vp;
struct vattr va;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
struct mount *mp;
u_long flags;
int result;
enum kauth_system_req req;
Replace the remaining KAUTH_GENERIC_ISSUSER authorization calls with something meaningful. All relevant documentation has been updated or written. Most of these changes were brought up in the following messages: http://mail-index.netbsd.org/tech-kern/2012/01/18/msg012490.html http://mail-index.netbsd.org/tech-kern/2012/01/19/msg012502.html http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012728.html Thanks to christos, manu, njoly, and jmmv for input. Huge thanks to pgoyette for spinning these changes through some build cycles and ATF.
2012-03-13 22:40:26 +04:00
int error;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
req = (enum kauth_system_req)arg0;
result = KAUTH_RESULT_DEFER;
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
switch (action) {
case KAUTH_SYSTEM_MOUNT:
if (dovfsusermount == 0)
Replace the remaining KAUTH_GENERIC_ISSUSER authorization calls with something meaningful. All relevant documentation has been updated or written. Most of these changes were brought up in the following messages: http://mail-index.netbsd.org/tech-kern/2012/01/18/msg012490.html http://mail-index.netbsd.org/tech-kern/2012/01/19/msg012502.html http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012728.html Thanks to christos, manu, njoly, and jmmv for input. Huge thanks to pgoyette for spinning these changes through some build cycles and ATF.
2012-03-13 22:40:26 +04:00
break;
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
switch (req) {
case KAUTH_REQ_SYSTEM_MOUNT_NEW:
vp = (vnode_t *)arg1;
mp = vp->v_mount;
flags = (u_long)arg2;
/*
* Ensure that the user owns the directory onto which
* the mount is attempted.
*/
vn_lock(vp, LK_SHARED | LK_RETRY);
error = VOP_GETATTR(vp, &va, cred);
VOP_UNLOCK(vp);
if (error)
break;
if (va.va_uid != kauth_cred_geteuid(cred))
break;
error = usermount_common_policy(mp, flags);
if (error)
break;
Replace the remaining KAUTH_GENERIC_ISSUSER authorization calls with something meaningful. All relevant documentation has been updated or written. Most of these changes were brought up in the following messages: http://mail-index.netbsd.org/tech-kern/2012/01/18/msg012490.html http://mail-index.netbsd.org/tech-kern/2012/01/19/msg012502.html http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012728.html Thanks to christos, manu, njoly, and jmmv for input. Huge thanks to pgoyette for spinning these changes through some build cycles and ATF.
2012-03-13 22:40:26 +04:00
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
result = KAUTH_RESULT_ALLOW;
Replace the remaining KAUTH_GENERIC_ISSUSER authorization calls with something meaningful. All relevant documentation has been updated or written. Most of these changes were brought up in the following messages: http://mail-index.netbsd.org/tech-kern/2012/01/18/msg012490.html http://mail-index.netbsd.org/tech-kern/2012/01/19/msg012502.html http://mail-index.netbsd.org/tech-kern/2012/02/17/msg012728.html Thanks to christos, manu, njoly, and jmmv for input. Huge thanks to pgoyette for spinning these changes through some build cycles and ATF.
2012-03-13 22:40:26 +04:00
break;
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
case KAUTH_REQ_SYSTEM_MOUNT_UNMOUNT:
mp = arg1;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
/* Must own the mount. */
if (mp->mnt_stat.f_owner == kauth_cred_geteuid(cred))
result = KAUTH_RESULT_ALLOW;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
break;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
case KAUTH_REQ_SYSTEM_MOUNT_UPDATE:
mp = arg1;
flags = (u_long)arg2;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
/* Must own the mount. */
if (mp->mnt_stat.f_owner == kauth_cred_geteuid(cred) &&
usermount_common_policy(mp, flags) == 0)
result = KAUTH_RESULT_ALLOW;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
break;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
secmodel_extensions_system_cb() is not mount-specific, even though KAUTH_SYSTEM_MOUNT happens to be the only option handled here. Put everything into a swith(action). No functional change.
2015-12-12 17:57:52 +03:00
default:
break;
}
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
break;
default:
break;
}
return (result);
}
static int
secmodel_extensions_process_cb(kauth_cred_t cred, kauth_action_t action,
void *cookie, void *arg0, void *arg1, void *arg2, void *arg3)
{
int result;
enum kauth_process_req req;
result = KAUTH_RESULT_DEFER;
req = (enum kauth_process_req)arg1;
switch (action) {
case KAUTH_PROCESS_CANSEE:
switch (req) {
case KAUTH_REQ_PROCESS_CANSEE_ARGS:
case KAUTH_REQ_PROCESS_CANSEE_ENTRY:
case KAUTH_REQ_PROCESS_CANSEE_OPENFILES:
Add KAUTH_REQ_PROCESS_CANSEE_EPROC, and use it for the kern.proc node. Same permission as before, so no functional change.
2018-08-25 12:54:37 +03:00
case KAUTH_REQ_PROCESS_CANSEE_EPROC:
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
if (curtain != 0) {
struct proc *p = arg0;
/*
* Only process' owner and root can see
* through curtain
*/
if (!kauth_cred_uidmatch(cred, p->p_cred)) {
int error;
bool isroot = false;
error = secmodel_eval(
"org.netbsd.secmodel.suser",
"is-root", cred, &isroot);
if (error == 0 && !isroot)
result = KAUTH_RESULT_DENY;
}
}
break;
Introduce KAUTH_REQ_PROCESS_CANSEE_KPTR, and use it in the already-existing modstat code. No real functional change.
2018-09-04 17:31:18 +03:00
case KAUTH_REQ_PROCESS_CANSEE_KPTR:
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
default:
break;
}
break;
case KAUTH_PROCESS_SCHEDULER_SETAFFINITY:
if (user_set_cpu_affinity != 0) {
When user_set_cpu_affinity is non-zero, only allow users to modify the CPU affinity of the LWPs they own.
2011-12-05 01:04:51 +04:00
struct proc *p = arg0;
if (kauth_cred_uidmatch(cred, p->p_cred))
result = KAUTH_RESULT_ALLOW;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
}
break;
default:
break;
}
return (result);
}
static int
secmodel_extensions_network_cb(kauth_cred_t cred, kauth_action_t action,
void *cookie, void *arg0, void *arg1, void *arg2, void *arg3)
{
int result;
enum kauth_network_req req;
result = KAUTH_RESULT_DEFER;
req = (enum kauth_network_req)arg0;
if (action != KAUTH_NETWORK_SOCKET ||
req != KAUTH_REQ_NETWORK_SOCKET_CANSEE)
return result;
if (curtain != 0) {
struct socket *so = (struct socket *)arg1;
Make the callback deal with embryonic connections which do not have credentials yet. Fixes PR kern/47598.
2013-02-28 19:23:24 +04:00
if (__predict_false(so == NULL || so->so_cred == NULL))
return KAUTH_RESULT_DENY;
Implement the register/deregister/evaluation API for secmodel(9). It allows registration of callbacks that can be used later for cross-secmodel "safe" communication. When a secmodel wishes to know a property maintained by another secmodel, it has to submit a request to it so the other secmodel can proceed to evaluating the request. This is done through the secmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY; This one asks the suser module if the credentials are assumed to be root when evaluated by suser module. If the module is present, it will respond. If absent, the call will return an error. Args and command are arbitrarily defined; it's up to the secmodel(9) to document what it expects. Typical example is securelevel testing: when someone wants to know whether securelevel is raised above a certain level or not, the caller has to request this property to the secmodel_securelevel(9) module. Given that securelevel module may be absent from system's context (thus making access to the global "securelevel" variable impossible or unsafe), this API can cope with this absence and return an error. We are using secmodel_eval(9) to implement a secmodel_extensions(9) module, which plugs with the bsd44, suser and securelevel secmodels to provide the logic behind curtain, usermount and user_set_cpu_affinity modes, without adding hooks to traditional secmodels. This solves a real issue with the current secmodel(9) code, as usermount or user_set_cpu_affinity are not really tied to secmodel_suser(9). The secmodel_eval(9) is also used to restrict security.models settings when securelevel is above 0, through the "is-securelevel-above" evaluation: - curtain can be enabled any time, but cannot be disabled if securelevel is above 0. - usermount/user_set_cpu_affinity can be disabled any time, but cannot be enabled if securelevel is above 0. Regarding sysctl(7) entries: curtain and usermount are now found under security.models.extensions tree. The security.curtain and vfs.generic.usermount are still accessible for backwards compat. Documentation is incoming, I am proof-reading my writings. Written by elad@, reviewed and tested (anita test + interact for rights tests) by me. ok elad@. See also http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html XXX might consider va0 mapping too. XXX Having a secmodel(9) specific printf (like aprint_*) for reporting secmodel(9) errors might be a good idea, but I am not sure on how to design such a function right now.
2011-12-04 23:24:58 +04:00
if (!kauth_cred_uidmatch(cred, so->so_cred)) {
int error;
bool isroot = false;
error = secmodel_eval("org.netbsd.secmodel.suser",
"is-root", cred, &isroot);
if (error == 0 && !isroot)
result = KAUTH_RESULT_DENY;
}
}
return (result);
}