Visit Our UNIX and Linux User Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

secmodel_extensions(9) [netbsd man page]

SECMODEL_EXTENSIONS(9)					   BSD Kernel Developer's Manual				    SECMODEL_EXTENSIONS(9)

NAME
secmodel_extensions -- Extensions security model DESCRIPTION
secmodel_extensions implements extensions to the traditional security model based on the original 4.4BSD. They can be used to grant addi- tional privileges to ordinary users, or enable specific security measures like curtain mode. The extensions are described below. Curtain mode When enabled, all returned objects will be filtered according to the user-id requesting information about them, preventing users from access- ing objects they do not own. It affects the output of many commands, including fstat(1), netstat(1), ps(1), sockstat(1), and w(1). This extension is enabled by setting security.models.extensions.curtain or security.curtain sysctl(7) to a non-zero value. It can be enabled at any time, but cannot be disabled anymore when the securelevel of the system is above 0. Non-superuser mounts When enabled, it allows file-systems to be mounted by an ordinary user who owns the point node and has at least read access to the special device mount(8) arguments. Note that the nosuid and nodev flags must be given for non-superuser mounts. This extension is enabled by setting security.models.extensions.usermount or vfs.generic.usermount sysctl(7) to a non-zero value. It can be disabled at any time, but cannot be enabled anymore when the securelevel of the system is above 0. Non-superuser control of CPU sets When enabled, an ordinary user is allowed to control the CPU affinity(3) of the processes and threads he owns. This extension is enabled by setting security.models.extensions.user_set_cpu_affinity sysctl(7) to a non-zero value. It can be disabled at any time, but cannot be enabled anymore when the securelevel of the system is above 0. SEE ALSO
affinity(3), sched(3), sysctl(7), kauth(9), secmodel(9), secmodel_bsd44(9), secmodel_securelevel(9), secmodel_suser(9) AUTHORS
Elad Efrat <elad@NetBSD.org> BSD
December 3, 2011 BSD

Check Out this Related Man Page

MAC_SEEOTHERUIDS(4)					   BSD Kernel Interfaces Manual 				       MAC_SEEOTHERUIDS(4)

NAME
mac_seeotheruids -- simple policy controlling whether users see other users SYNOPSIS
To compile the policy into your kernel, place the following lines in your kernel configuration file: options MAC options MAC_SEEOTHERUIDS Alternately, to load the module at boot time, place the following line in your kernel configuration file: options MAC and in loader.conf(5): mac_seeotheruids_load="YES" DESCRIPTION
The mac_seeotheruids policy module, when enabled, denies users to see processes or sockets owned by other users. To enable mac_seeotheruids, set the sysctl OID security.mac.seeotheruids.enabled to 1. To permit superuser awareness of other credentials by virtue of privilege, set the sysctl OID security.mac.seeotheruids.suser_privileged to 1. To allow users to see processes and sockets owned by the same primary group, set the sysctl OID security.mac.seeotheruids.primarygroup_enabled to 1. To allow processes with a specific group ID to be exempt from the policy, set the sysctl OID security.mac.seeotheruids.specificgid_enabled to 1, and security.mac.seeotheruids.specificgid to the group ID to be exempted. Label Format No labels are defined for mac_seeotheruids. SEE ALSO
mac(4), mac_biba(4), mac_bsdextended(4), mac_ifoff(4), mac_lomac(4), mac_mls(4), mac_none(4), mac_partition(4), mac_portacl(4), mac_test(4), mac(9) HISTORY
The mac_seeotheruids policy module first appeared in FreeBSD 5.0 and was developed by the TrustedBSD Project. AUTHORS
This software was contributed to the FreeBSD Project by Network Associates Labs, the Security Research Division of Network Associates Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (``CBOSS''), as part of the DARPA CHATS research program. BUGS
See mac(9) concerning appropriateness for production use. The TrustedBSD MAC Framework is considered experimental in FreeBSD. While the MAC Framework design is intended to support the containment of the root user, not all attack channels are currently protected by entry point checks. As such, MAC Framework policies should not be relied on, in isolation, to protect against a malicious privileged user. BSD
October 6, 2005 BSD

Featured Tech Videos