#
76af92ac |
| 16-Mar-2020 |
pgoyette <pgoyette@NetBSD.org> |
Use the module subsystem's ability to process SYSCTL_SETUP() entries to automate installation of sysctl nodes.
Note that there are still a number of device and pseudo-device modules that create entr
Use the module subsystem's ability to process SYSCTL_SETUP() entries to automate installation of sysctl nodes.
Note that there are still a number of device and pseudo-device modules that create entries tied to individual device units, rather than to the module itself. These are not changed.
show more ...
|
#
05fd0bf3 |
| 25-Feb-2014 |
pooka <pooka@NetBSD.org> |
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 duplicat
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.
show more ...
|
#
6519e39d |
| 04-Dec-2011 |
jym <jym@NetBSD.org> |
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
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.
show more ...
|
#
741fed91 |
| 28-Nov-2011 |
jym <jym@NetBSD.org> |
The secmodel(9)s init, start and stop routines are managed by each secmodel module(7), so there is no point in calling suser/securelevel routines from bsd44. This leads to unwanted cross-secmodel dep
The secmodel(9)s init, start and stop routines are managed by each secmodel module(7), so there is no point in calling suser/securelevel routines from bsd44. This leads to unwanted cross-secmodel dependencies.
Do not call secmodel_bsd44_init() from secmodel_overlay_init(). Doing so resets all curtain/securelevel values, which is not really needed when loading an overlay filter.
Remove the secmodel_register/deregister comments, they will be implemented differently in an upcoming patch.
ok elad@ (via private mail).
show more ...
|
#
53ca19a3 |
| 02-Oct-2009 |
elad <elad@NetBSD.org> |
First part of secmodel cleanup and other misc. changes:
- Separate the suser part of the bsd44 secmodel into its own secmodel and directory, pending even more cleanups. For revision history
First part of secmodel cleanup and other misc. changes:
- Separate the suser part of the bsd44 secmodel into its own secmodel and directory, pending even more cleanups. For revision history purposes, the original location of the files was
src/sys/secmodel/bsd44/secmodel_bsd44_suser.c src/sys/secmodel/bsd44/suser.h
- Add a man-page for secmodel_suser(9) and update the one for secmodel_bsd44(9).
- Add a "secmodel" module class and use it. Userland program and documentation updated.
- Manage secmodel count (nsecmodels) through the module framework. This eliminates the need for secmodel_{,de}register() calls in secmodel code.
- Prepare for secmodel modularization by adding relevant module bits. The secmodels don't allow auto unload. The bsd44 secmodel depends on the suser and securelevel secmodels. The overlay secmodel depends on the bsd44 secmodel. As the module class is only cosmetic, and to prevent ambiguity, the bsd44 and overlay secmodels are prefixed with "secmodel_".
- Adapt the overlay secmodel to recent changes (mainly vnode scope).
- Stop using link-sets for the sysctl node(s) creation.
- Keep sysctl variables under nodes of their relevant secmodels. In other words, don't create duplicates for the suser/securelevel secmodels under the bsd44 secmodel, as the latter is merely used for "grouping".
- For the suser and securelevel secmodels, "advertise presence" in relevant sysctl nodes (sysctl.security.models.{suser,securelevel}).
- Get rid of the LKM preprocessor stuff.
- As secmodels are now modules, there's no need for an explicit call to secmodel_start(); it's handled by the module framework. That said, the module framework was adjusted to properly load secmodels early during system startup.
- Adapt rump to changes: Instead of using empty stubs for securelevel, simply use the suser secmodel. Also replace secmodel_start() with a call to secmodel_suser_start().
- 5.99.20.
Testing was done on i386 ("release" build). Spearated module_init() changes were tested on sparc and sparc64 as well by martin@ (thanks!).
Mailing list reference:
http://mail-index.netbsd.org/tech-kern/2009/09/25/msg006135.html
show more ...
|
#
2ef031e6 |
| 23-Feb-2008 |
elad <elad@NetBSD.org> |
Adapt to secmodel_securelevel.
|
#
f266f9a5 |
| 16-Jan-2007 |
elad <elad@NetBSD.org> |
Use secmodel_register() and secmodel_deregister().
|
#
2b3921e3 |
| 16-Jan-2007 |
elad <elad@NetBSD.org> |
Implement secmodel_bsd44_start(), secmodel_bsd44_stop(), and secmodel_overlay_start().
|
#
d4e427ef |
| 15-Jan-2007 |
elad <elad@NetBSD.org> |
'&securelevel' -> 'NULL', pointed out by cube@, thanks!
|
#
76f1c03b |
| 09-Jan-2007 |
elad <elad@NetBSD.org> |
Remove advertising clause from all of my stuff.
|
#
4798cd2c |
| 29-Dec-2006 |
elad <elad@NetBSD.org> |
Support device scope.
|
#
71576e0d |
| 17-Sep-2006 |
elad <elad@NetBSD.org> |
Make the sysctl warnings on dmesg ("..returned 17") go away, after many people didn't like them.
|
#
c2ea23c5 |
| 08-Sep-2006 |
elad <elad@NetBSD.org> |
Add __KERNEL_RCSID(), requested by and okay xtraeme@.
|
#
5f7169cc |
| 08-Sep-2006 |
elad <elad@NetBSD.org> |
First take at security model abstraction.
- Add a few scopes to the kernel: system, network, and machdep.
- Add a few more actions/sub-actions (requests), and start using them as opposed to the K
First take at security model abstraction.
- Add a few scopes to the kernel: system, network, and machdep.
- Add a few more actions/sub-actions (requests), and start using them as opposed to the KAUTH_GENERIC_ISSUSER place-holders.
- Introduce a basic set of listeners that implement our "traditional" security model, called "bsd44". This is the default (and only) model we have at the moment.
- Update all relevant documentation.
- Add some code and docs to help folks who want to actually use this stuff:
* There's a sample overlay model, sitting on-top of "bsd44", for fast experimenting with tweaking just a subset of an existing model.
This is pretty cool because it's *really* straightforward to do stuff you had to use ugly hacks for until now...
* And of course, documentation describing how to do the above for quick reference, including code samples.
All of these changes were tested for regressions using a Python-based testsuite that will be (I hope) available soon via pkgsrc. Information about the tests, and how to write new ones, can be found on:
http://kauth.linbsd.org/kauthwiki
NOTE FOR DEVELOPERS: *PLEASE* don't add any code that does any of the following:
- Uses a KAUTH_GENERIC_ISSUSER kauth(9) request, - Checks 'securelevel' directly, - Checks a uid/gid directly.
(or if you feel you have to, contact me first)
This is still work in progress; It's far from being done, but now it'll be a lot easier.
Relevant mailing list threads:
http://mail-index.netbsd.org/tech-security/2006/01/25/0011.html http://mail-index.netbsd.org/tech-security/2006/03/24/0001.html http://mail-index.netbsd.org/tech-security/2006/04/18/0000.html http://mail-index.netbsd.org/tech-security/2006/05/15/0000.html http://mail-index.netbsd.org/tech-security/2006/08/01/0000.html http://mail-index.netbsd.org/tech-security/2006/08/25/0000.html
Many thanks to YAMAMOTO Takashi, Matt Thomas, and Christos Zoulas for help stablizing kauth(9).
Full credit for the regression tests, making sure these changes didn't break anything, goes to Matt Fleming and Jaime Fournier.
Happy birthday Randi! :)
show more ...
|