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.

branches: 1.4.12; 1.4.16;
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

Add support for multi-position electro-mechanical keylocks. An example
driver, gpiolock(4), is provided as an example how to interface real hardware.
A new securemodel, securemodel_keylock, is provided to show how this can
be used to tie keylocks to overall system security. This is experimental
code. The diff has been on tech-kern for several weeks.

Reviewed by many, kauth(9) integration reviewed by Elad Efrat; approved by
tonnerre@ and tron@. Thanks to everyone who provided feedback.

branches: 1.2.18;
Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

branches: 1.1.2; 1.1.6; 1.1.10; 1.1.30; 1.1.32; 1.1.36; 1.1.38;
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! :)

Do not release secmodels_lock when it is not held.

Sent on tech-kern@, ok lars@

branches: 1.1.4; 1.1.6; 1.1.10; 1.1.26;
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.

Provide necessary forward declarations or includes.

branches: 1.4.48; 1.4.54;
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.

branches: 1.3.10; 1.3.14;
Remove secmodel.h, forgotten in previous commit:

http://mail-index.netbsd.org/source-changes/2009/10/02/msg001437.html

branches: 1.2.44;
Remove advertising clause from all of my stuff.

branches: 1.1.2; 1.1.6; 1.1.10;
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! :)

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.

branches: 1.6.48;
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.

branches: 1.5.12; 1.5.16;
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

branches: 1.4.44;
Implement secmodel_bsd44_start(), secmodel_bsd44_stop(), and
secmodel_overlay_start().

Remove advertising clause from all of my stuff.

Add prototypes for the sysctl(9) setup routines for LKMs only.

branches: 1.1.2; 1.1.6; 1.1.10;
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! :)

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.

branches: 1.3.12; 1.3.16;
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

branches: 1.2.18;
Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

branches: 1.1.2; 1.1.6; 1.1.10; 1.1.30; 1.1.32; 1.1.36; 1.1.38;
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! :)

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.

branches: 1.16.30;
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.

branches: 1.15.6; 1.15.10;
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.

branches: 1.14.2;
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).

branches: 1.13.12;
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

Move dovfsusermount to secmodel_bsd44, where it really belongs.

The secmodel code now creates the same knob in two places: both under the
secmodel itself, as well as the widely known location.

Mailing list references:

http://mail-index.netbsd.org/source-changes/2009/05/02/msg220641.html
http://mail-index.netbsd.org/tech-kern/2009/05/03/msg005015.html

branches: 1.11.18; 1.11.32;
Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

branches: 1.10.18; 1.10.20; 1.10.24; 1.10.26;
Use secmodel_register() and secmodel_deregister().

Implement secmodel_bsd44_start(), secmodel_bsd44_stop(), and
secmodel_overlay_start().

Remove advertising clause from all of my stuff.

Don't compile secmodel_start() if built as an LKM.

Make the securelevel contained by not exposing the variable that keeps
it outside secmodel_bsd44_securelevel.c.

Explicitly 'extern int securelevel;' in the sysctl(9) setup routine.

branches: 1.4.2; 1.4.6;
Create 'security.curtain' for documentation compatibility.

branches: 1.3.2;
Make the sysctl warnings on dmesg ("..returned 17") go away, after many
people didn't like them.

branches: 1.2.2;
Add __KERNEL_RCSID(), requested by and okay xtraeme@.

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! :)

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

Move dovfsusermount to secmodel_bsd44, where it really belongs.

The secmodel code now creates the same knob in two places: both under the
secmodel itself, as well as the widely known location.

Mailing list references:

http://mail-index.netbsd.org/source-changes/2009/05/02/msg220641.html
http://mail-index.netbsd.org/tech-kern/2009/05/03/msg005015.html

branches: 1.4.18; 1.4.32;
Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

branches: 1.3.18; 1.3.20; 1.3.24; 1.3.26;
Remove advertising clause from all of my stuff.

branches: 1.2.2; 1.2.6; 1.2.10;
Add __KERNEL_RCSID(), requested by and okay xtraeme@.

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! :)

Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

branches: 1.30.6; 1.30.8; 1.30.12; 1.30.14;
Merge some of the less invasive changes from the vmlocking branch:

- kthread, callout, devsw API changes
- select()/poll() improvements
- miscellaneous MT safety improvements

branches: 1.29.6; 1.29.8;
Make 'securelevel' internal to the secmodel.

Remove advertising clause from all of my stuff.

Add 'stop' routines to do the exact opposite of the 'start' routines for
'securelevel' and 'suser' parts of secmodel_bsd44.

Don't leak listeners.

Consistent naming in sysctl(9) setup routines.

Make the securelevel contained by not exposing the variable that keeps
it outside secmodel_bsd44_securelevel.c.

Add KAUTH_SYSTEM_CHSYSFLAGS so we can get rid of the last three
securelevel references (ufs, ext2fs, tmpfs).

Intentionally undocumented.

Make mount(2) and unmount(2) use kauth(9) for security policy.

Okay yamt@.

Remove XXX comment about making 'securelevel' a static.

branches: 1.20.2;
Make machdep scope architecture-agnostic by removing all arch-specific
requests and centralizing them all. The result is that some of these
are not used on some architectures, but the documentation was updated
to reflect that.

Change kauth(9) KPI for kauth_authorize_device_passthru() to add another
argument, u_long, serving as a bit-mask of generic requests for the
passthru request.

Discussed on tech-security@ and tech-kern@. Okay tls@.

branches: 1.18.2;
Move ktrace, ptrace, systrace, and procfs to use kauth(9).

First, remove process_checkioperm() calls from MD code. Similar checks
using kauth(9) routines (on the process scope, using appropriate action)
are done in the callers.

Add secmodel back-end to handle each subsystem.

Add an XXX comment so we don't forget what we need to do here:

* XXX: This is bogus. We should be failing the request
* XXX: not only if this specific slice is mounted, but
* XXX: if it's on a disk with any other mounted slice.

Prevent iopl/ioperm in securelevel 1, not 2.

Introduce KAUTH_REQ_MACHDEP_{ALPHA,X86}_UNMANAGEDMEM to handle access
to unmanaged memory.

These are the last two securelevel references in the MD code.

branches: 1.14.2;
__unused removal on arguments; approved by core.

Better VCHR handling.

simplify & fix logic in device/rawio/spec.

Use KASSERT() as requested by yamt@.

Change KAUTH_SYSTEM_RAWIO to KAUTH_DEVICE_RAWIO_SPEC (moving the raw i/o
requests to the device scope) and add KAUTH_DEVICE_RAWIO_PASSTHRU.

Expose iskmemdev() through sys/conf.h.

okay yamt@

- sprinkle __unused on function decls.
- fix a couple of unused bugs
- no more -Wno-unused for i386

For raw disk requests, in case we don't have a vnode/device, use a
generic policy: always allow reading, allow writing in securelevel < 1
only.

Add missing break.

Make code more readable by removing some more casts forgotten in
previous commit.

Remove ugly (void *) casts from network scope authorization wrapper and
calls to it.

While here, adapt code for system scope listeners to avoid some more
casts (forgotten in previous run).

Update documentation.

For the VBLK case, we always check vfs_mountedon() and it has nothing
to do with the security model used. Move back the call to spec_open(),
which can now return the real return value from vfs_mountedon() (EBUSY)
and not EPERM, changing semantics.

branches: 1.3.2; 1.3.4;
In secmodel_bsd44_securelevel_system_cb(), compare dev_t dev with
NODEV, not 0, since 0 is a legit value for a dev_t. Now I can
'mount /dev/wd0a /mnt' again.

Add __KERNEL_RCSID(), requested by and okay xtraeme@.

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! :)

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

Implement the vnode scope and adapt tmpfs to use it.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/07/04/msg005404.html

reduce the number of KAUTH_DEVICE_BLUETOOTH_SEND/RECV requests
by passing the packet type as an argument rather than having
a different request for each type.

(from a suggestion by mrg)

remove last usage of KAUTH_ISSUSER in bluetooth code by adding
some requests to the device scope:

KAUTH_DEVICE_BLUETOOTH_SEND_COMMAND
KAUTH_DEVICE_BLUETOOTH_RECV_COMMAND
KAUTH_DEVICE_BLUETOOTH_RECV_EVENT
KAUTH_DEVICE_BLUETOOTH_RECV_DATA

and a listener tied to the HCI protocol that will approve the basic
minimum to be sent and received.

handle the requests in the bsd44_suser listener by approving all
when the credential is root.

Extend the existing security models for upcoming gpio(4) changes.
Reviewed and feedback by Elad Efrat.

Add and use a network scope action/request for tun(4), similar to ppp(4),
sl(4), and strip(4).

Introduce several actions/requests for authorizing file-system related
operations, specifically quota and block allocation from reserved space.

Modify ufs_quotactl() to accomodate passing "mp" earlier by vfs_busy()ing
it a little bit higher.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/04/26/msg004936.html

Note that the umapfs request mentioned in this thread was NOT added as
there is still on-going discussion regarding the proper implementation.

Introduce actions/requests to handle authorization for ppp(4), sl(4),
strip(4), btuart(4) and bcsp(4) network interfaces and devices.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/04/27/msg004955.html

Add device scope actions for rnd(4) and use them.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/04/27/msg004953.html

Add a bluetooth action to the device scope and use it in netbt as a
replacement for KAUTH_GENERIC_ISSUSER.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/04/25/msg004905.html

Bluetooth-specific authorization wrapper might come later.

Remove a few KAUTH_GENERIC_ISSUSER in favor of more descriptive
alternatives.

Discussed on tech-kern:

http://mail-index.netbsd.org/tech-kern/2009/04/11/msg004798.html

Input from ad@, christos@, dyoung@, tsutsui@.

Okay ad@.

branches: 1.61.4;
Correct check for autoloaded modules.

Remove LKMs and switch to the module framework, pass 1.

Proposed on tech-kern@.

branches: 1.59.2; 1.59.4;
- Be clear about whether module load is explicit or system initiated (auto).
- Require that module_lock is held to autoload, so that any preconditions
can be safely checked.

Move uidinfo to its own module in kern_uidinfo.c and include in rump.
No functional change to uidinfo.

branches: 1.57.4; 1.57.10;
Remove include of sys/pset.h in sys/lwp.h header.
Include it in few appropriate sources.

Forgot this file in the previous commit.

Backend for the newly added KAUTH_NETWORK_NFS action.

Spotted by Paul Goyette on current-users@, thanks!

Factor out the guts of get/setparam so it can be used from the compat code.

Make the FreeBSD and Linux compat code convert the parameters to their
native representation and call the native routines.

Remove KAUTH_PROCESS_SCHEDULER_GET/SET.

Update documentation and examples.

XXX: For now, only the Linux compat code does the priority conversion
XXX: right.

Linux priority conversion code from yamt@, thanks!

Okay yamt@.

Default defer, not deny.

Idea okay wrstuden@, no objections on tech-kern@ and tech-security@.

branches: 1.53.2; 1.53.6;
PR/37986: YAMAMOTO Takashi: any user can hog the all cpu with
_sched_setparam.

Pass proper context to kauth(9) for a decision to made based on the
scheduling policy and priority.

Fold KAUTH_REQ_PROCESS_SCHEDULER_* to KAUTH_PROCESS_SCHEDULER_*. In other
words, don't pass an action and a request, and just use a single action to
indicate what is the operation in question.

This is the first step in fixing PR/37986, which calls for policy/priority
checking in the secmodel code. Right now we're lacking room for another
parameter required to make a decision, and this change makes room for such.

Default deny and explicit allow policy in all listeners.

No objections on tech-security@ and tech-kern@.

Add, document, and use KAUTH_REQ_PROCESS_KTRACE_PERSISTENT.

KTRFAC_ROOT -> KTRFAC_PERSISTENT, and update comments.

Discussed with christos@ and yamt@.

Replace a KAUTH_GENERIC_ISSUSER in the cpuctl code with a proper kauth
request.

Reviewed by ad@, tested by me.

Use proper kauth(9) actions/requests for native scheduler stuff and the
recently introduced processor-sets.

Discussed with and okay rmind@, yamt@, and christos@.

Tons of process scope changes.

- Add a KAUTH_PROCESS_SCHEDULER action, to handle scheduler related
requests, and add specific requests for set/get scheduler policy and
set/get scheduler parameters.

- Add a KAUTH_PROCESS_KEVENT_FILTER action, to handle kevent(2) related
requests.

- Add a KAUTH_DEVICE_TTY_STI action to handle requests to TIOCSTI.

- Add requests for the KAUTH_PROCESS_CANSEE action, indicating what
process information is being looked at (entry itself, args, env,
open files).

- Add requests for the KAUTH_PROCESS_RLIMIT action indicating set/get.

- Add requests for the KAUTH_PROCESS_CORENAME action indicating set/get.

- Make bsd44 secmodel code handle the newly added rqeuests appropriately.

All of the above make it possible to issue finer-grained kauth(9) calls in
many places, removing some KAUTH_GENERIC_ISSUSER requests.

- Remove the "CAN" from KAUTH_PROCESS_CAN{KTRACE,PROCFS,PTRACE,SIGNAL}.

Discussed with christos@ and yamt@.

Pull in my modules code for review/test/hacking.

Make fork use kauth.

Been running in my tree for over a month at least.

Reviewed and okay yamt@, and special thanks to him as well as rittera@
for making this possible through fixing NDIS to not call fork1() with
l1 != curlwp.

Remove systrace. Ok core@.

branches: 1.42.6;
Add PT_TRACE_ME to switch statement.

This caused trouble with ptrace, and noted just now thanks to a strict
policy design. Noted (and fix verified by) mjf@, thanks.

Deprecate KAUTH_REQ_SYSTEM_TIME_BACKWARDS, as it was merged into
KAUTH_REQ_SYSTEM_TIME_SYSTEM.

Refactor time modification checks and place them in the secmodel code.

okay christos@

Fix a long time issue where the securelevel secmodel would explicitly
allow certain operations.

The suser module of the bsd44 secmodel code was made aware of the missing
operations that were explicitly allowed in the securelevel module, and
the logic in the latter was modified to a default defer, deny where not
allowed.

This concept, which is the correct way to write secmodel code, was first
brought up by pavel@ a long time ago.

okay christos@.

Kill another instance of KAUTH_GENERIC_ISSUSER.

branches: 1.37.16; 1.37.18; 1.37.24;
Replace the Mach-derived boolean_t type with the C99 bool type. A
future commit will replace use of TRUE and FALSE with true and false.

Change the process/lwp flags seen by userland via sysctl back to the
P_*/L_* naming convention, and rename the in-kernel flags to avoid
conflict. (P_ -> PK_, L_ -> LW_ ). Add back the (now unused) LSDEAD
constant.

Restores source compatibility with pre-newlock2 tools like ps or top.

Reviewed by Andrew Doran.

branches: 1.35.2;
Merge newlock2 to head.

Add another hardwired exception to the SOCK_RAW / superuser rule, because
(PF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI) sockets need to be accessable for
normal users.

Kill KAUTH_PROCESS_RESOURCE and just replace it with two actions for
nice and rlimit.

Avoid proc_uidmatch() for rlimits if p is curproc.

Make readable.

Remove advertising clause from all of my stuff.

Fallthrough.

Add 'stop' routines to do the exact opposite of the 'start' routines for
'securelevel' and 'suser' parts of secmodel_bsd44.

Don't leak listeners.

Add missing break...

Need vnode.h here.

Make mount(2) and unmount(2) use kauth(9) for security policy.

Okay yamt@.

branches: 1.23.2;
Refactor a bit the ptrace(2) code: first make the keep-kernel-stable
decisions, then have a kauth(9) call for security policy enforcement,
and only then proceed to processing each request.

Add a KAUTH_PROCESS_CANSEE call right after pfind(). This should really
be done differently, so mark it with XXX.

Make machdep scope architecture-agnostic by removing all arch-specific
requests and centralizing them all. The result is that some of these
are not used on some architectures, but the documentation was updated
to reflect that.

PR/35226: Johann Franz: Problems with permissions in
/usr/pkg/emul/linux/proc .

Okay mlelstv@

Add requests indicating access to unmanaged memory for arm, pc532, powerpc,
sh3, sh5, and vax, and use them instead of KAUTH_GENERIC_ISSUSER.

Update documentation and example secmodel code.

Don't allow anyone but the superuser to do 'ctl' on procfs nodes.

- moves 'nice' access semantics to secmodel code,
- makes sysctl_proc_find() just lookup the process,
- use KAUTH_PROCESS_CANSEE requests to determine if the caller is
allowed to view the target process' corename, stop flags, and
rlimits,
- use explicit kauth(9) calls with KAUTH_PROCESS_CORENAME,
KAUTH_REQ_PROCESS_RESOURCE_NICE, KAUTH_REQ_PROCESS_RESOURCE_RLIMIT,
and KAUTH_PROCESS_STOPFLAG when modifying the aforementioned.
- sync man-page and example skeleton secmodel with reality.

okay yamt@

this is a pullup candidate.

branches: 1.17.2;
Move ktrace, ptrace, systrace, and procfs to use kauth(9).

First, remove process_checkioperm() calls from MD code. Similar checks
using kauth(9) routines (on the process scope, using appropriate action)
are done in the callers.

Add secmodel back-end to handle each subsystem.

branches: 1.16.2;
__unused removal on arguments; approved by core.

Fix a regression in socket(2): in the BSD 4.4 security model, you
don't have to be the superuser to open a PF_ROUTE socket.

Now, 'route -n get default' works again.

Use integers, not pointers to integers, for KAUTH_REQ_NETWORK_SOCKET_OPEN.

Reminded by yamt@, thanks!

Introduce KAUTH_REQ_NETWORK_SOCKET_OPEN, to check if opening a socket is
allowed. It takes three int * arguments indicating domain, type, and
protocol. Replace previous KAUTH_REQ_NETWORK_SOCKET_RAWSOCK with it (but
keep it still).

Places that used to explicitly check for privileged context now don't
need it anymore, so I replaced these with XXX comment indiacting it for
future reference.

Documented and updated examples as well.

oops, fix license. (hah!)

Introduce a new action on the network scope, KAUTH_NETWORK_INTERFACE,
used to manage network interfaces.

Add four sub-actions to fulfill generic needs for now, until a more
carefully defined usage of the interface is documented: get, set,
getpriv, and setpriv.

Add a new ALTQ kauth(9) request, KAUTH_REQ_NETWORK_ALTQ_JOBS.

Introduce KAUTH_REQ_NETWORK_SOCKET_CANSEE. Since we're not gonna be having
credentials on sockets, at least not anytime soon, this is a way to check
if we can "look" at a socket. Later on when (and if) we do have socket
credentials, the interface usage remains the same because we pass the
socket.

This also fixes sysctl for inet/inet6 pcblist.

- sprinkle __unused on function decls.
- fix a couple of unused bugs
- no more -Wno-unused for i386

Implement the "device" scope.

It uses an authorization wrapper per device class on the system to
ensure type-safety.

For now, it supports only terminal (TTY) devices, and has two actions
for them: "open terminal" and "privileged set". Sample usage has been
added to i386 and hp300 code for reference.

Update documentation.

Don't care for super-user in packet filter rules, it's done via a device
anyway. Same as the clock-related change few days ago.

Should address PR/34635 from victori at lamer0 dot com

Super-user access only matters for part of the KAUTH_SYSTEM_TIME requests,
so defer the ones we don't care about.

Thanks to Jukka Salmi for the ktrace output!

Make code more readable by removing some more casts forgotten in
previous commit.

Remove ugly (void *) casts from network scope authorization wrapper and
calls to it.

While here, adapt code for system scope listeners to avoid some more
casts (forgotten in previous run).

Update documentation.

branches: 1.2.2; 1.2.4;
Add __KERNEL_RCSID(), requested by and okay xtraeme@.

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! :)

Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

branches: 1.5.18; 1.5.20; 1.5.24; 1.5.26;
Remove advertising clause from all of my stuff.

Add 'stop' routines to do the exact opposite of the 'start' routines for
'securelevel' and 'suser' parts of secmodel_bsd44.

Add prototypes for the sysctl(9) setup routines for LKMs only.

branches: 1.2.2; 1.2.6;
Oops, forgot to do this one in previous commit.

Pointed out by mjf@, thanks!

branches: 1.1.2; 1.1.4;
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! :)

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

Implement the vnode scope and adapt tmpfs to use it.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/07/04/msg005404.html

Move dovfsusermount to secmodel_bsd44, where it really belongs.

The secmodel code now creates the same knob in two places: both under the
secmodel itself, as well as the widely known location.

Mailing list references:

http://mail-index.netbsd.org/source-changes/2009/05/02/msg220641.html
http://mail-index.netbsd.org/tech-kern/2009/05/03/msg005015.html

branches: 1.4.44; 1.4.60;
Remove advertising clause from all of my stuff.

Add 'stop' routines to do the exact opposite of the 'start' routines for
'securelevel' and 'suser' parts of secmodel_bsd44.

branches: 1.2.2; 1.2.6;
Implement the "device" scope.

It uses an authorization wrapper per device class on the system to
ensure type-safety.

For now, it supports only terminal (TTY) devices, and has two actions
for them: "open terminal" and "privileged set". Sample usage has been
added to i386 and hp300 code for reference.

Update documentation.

branches: 1.1.2; 1.1.4;
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! :)

branches: 1.1.4; 1.1.6;
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.

secmodel_extensions: Split vfs part into separate .c file.

This way we can provide weak rumpkern stubs that don't require
rumpvfs for things that are relevant to vfs, but if you do link
rumpvfs then you get the same logic in secmodel extensions.

secmodel_extensions: Split vfs part into separate .c file.

This way we can provide weak rumpkern stubs that don't require
rumpvfs for things that are relevant to vfs, but if you do link
rumpvfs then you get the same logic in secmodel extensions.

branches: 1.1.4; 1.1.6;
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.

secmodel_extensions: Split vfs part into separate .c file.

This way we can provide weak rumpkern stubs that don't require
rumpvfs for things that are relevant to vfs, but if you do link
rumpvfs then you get the same logic in secmodel extensions.

isroot should be bool...

secmodel: fix grammar in description of hardlink_check_gid

Implement restrictions for adding hard links to files

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.

Explicitly cast pointers to uintptr_t before casting to enums. They are
not necessarily the same size. Don't cast pointers to bool, check for
NULL instead.

branches: 1.10.6;
Introduce KAUTH_REQ_PROCESS_CANSEE_KPTR, and use it in the already-existing
modstat code. No real functional change.

Add KAUTH_REQ_PROCESS_CANSEE_EPROC, and use it for the kern.proc node.
Same permission as before, so no functional change.

branches: 1.8.2;
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>

branches: 1.7.10; 1.7.16;
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.

branches: 1.6.6;
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.

branches: 1.5.6;
Make the callback deal with embryonic connections which do not have
credentials yet. Fixes PR kern/47598.

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.

branches: 1.3.2; 1.3.4;
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.

branches: 1.2.2; 1.2.4; 1.2.8;
When user_set_cpu_affinity is non-zero, only allow users to modify
the CPU affinity of the LWPs they own.

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.

secmodel_extensions: Split vfs part into separate .c file.

This way we can provide weak rumpkern stubs that don't require
rumpvfs for things that are relevant to vfs, but if you do link
rumpvfs then you get the same logic in secmodel extensions.

branches: 1.1.2;
Add support for multi-position electro-mechanical keylocks. An example
driver, gpiolock(4), is provided as an example how to interface real hardware.
A new securemodel, securemodel_keylock, is provided to show how this can
be used to tie keylocks to overall system security. This is experimental
code. The diff has been on tech-kern for several weeks.

Reviewed by many, kauth(9) integration reviewed by Elad Efrat; approved by
tonnerre@ and tron@. Thanks to everyone who provided feedback.

Clean up _LKM --> _MODULE leftovers.

Note that _KERNEL is always defined for modules.

branches: 1.1.2;
Add support for multi-position electro-mechanical keylocks. An example
driver, gpiolock(4), is provided as an example how to interface real hardware.
A new securemodel, securemodel_keylock, is provided to show how this can
be used to tie keylocks to overall system security. This is experimental
code. The diff has been on tech-kern for several weeks.

Reviewed by many, kauth(9) integration reviewed by Elad Efrat; approved by
tonnerre@ and tron@. Thanks to everyone who provided feedback.

s/dissallow/disallow/

Remove unnecessary inclusion of <sys/timevar.h>.

branches: 1.10.6;
Explicitly cast pointers to uintptr_t before casting to enums. They are
not necessarily the same size. Don't cast pointers to bool, check for
NULL instead.

branches: 1.9.6;
Retire ipkdb entirely. The option was removed from the config files
yesterday.

ok kamil christos

branches: 1.8.28; 1.8.30;
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.

branches: 1.7.6; 1.7.10;
build fix for keylock secmodel(9).

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.

branches: 1.5.12; 1.5.16;
buildfix: define integer before use. i386 ALL kernel builds again

Factor out a block of code that appears in three places (Veriexec, keylock,
and securelevel) so that others can use it as well.

Introduce time_wraps() to check if setting the time will wrap it (or
close to it). Useful for secmodels.

Replace open-coded form with it in secmodel code (securelevel, keylock).

Note: I need to find a way to make secmodel_keylock.c ~<100 lines.

branches: 1.2.2;
Move the keylock.h header from sys/sys to sys/dev where it really belongs.
Add keylock options to the ALL kernel configuration.

Add support for multi-position electro-mechanical keylocks. An example
driver, gpiolock(4), is provided as an example how to interface real hardware.
A new securemodel, securemodel_keylock, is provided to show how this can
be used to tie keylocks to overall system security. This is experimental
code. The diff has been on tech-kern for several weeks.

Reviewed by many, kauth(9) integration reviewed by Elad Efrat; approved by
tonnerre@ and tron@. Thanks to everyone who provided feedback.

branches: 1.1.2; 1.1.6; 1.1.10;
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! :)

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.

branches: 1.4.12; 1.4.16;
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

branches: 1.3.44;
Remove advertising clause from all of my stuff.

branches: 1.2.2;
Support device scope.

branches: 1.1.2; 1.1.6; 1.1.8; 1.1.10;
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! :)

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.

branches: 1.13.30;
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.

branches: 1.12.6; 1.12.10;
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.

branches: 1.11.2;
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).

branches: 1.10.12;
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

branches: 1.9.4;
Adapt to secmodel_securelevel.

branches: 1.8.20; 1.8.36; 1.8.40;
Use secmodel_register() and secmodel_deregister().

Implement secmodel_bsd44_start(), secmodel_bsd44_stop(), and
secmodel_overlay_start().

'&securelevel' -> 'NULL', pointed out by cube@, thanks!

Remove advertising clause from all of my stuff.

branches: 1.4.2;
Support device scope.

branches: 1.3.4; 1.3.6; 1.3.8;
Make the sysctl warnings on dmesg ("..returned 17") go away, after many
people didn't like them.

branches: 1.2.2;
Add __KERNEL_RCSID(), requested by and okay xtraeme@.

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! :)

branches: 1.1.2; 1.1.4; 1.1.8; 1.1.16; 1.1.18;
Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

Remove unnecessary inclusion of <sys/timevar.h>.

branches: 1.36.2;
Accept ioctl(RNDADDDATA) estimates at securelevel 1 (but not 2).

securelevel=1 is supposed to be a reasonable default for normal
computers. This got in the way of ever getting entropy from a seed
on a machine with no HWRNG -- e.g., from another machine, or by
making the executive decision that what has been sampled is good
enough and issuing `head -c 32 < /dev/urandom > /dev/random'.

KAUTH_MACHDEP_SVS_DISABLE is deprecated.

sysctl machdep.svs.enabled can't be changed anymore
at runtime because it's now a boot option.

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.

Explicitly cast pointers to uintptr_t before casting to enums. They are
not necessarily the same size. Don't cast pointers to bool, check for
NULL instead.

branches: 1.32.4; 1.32.6;
Retire ipkdb entirely. The option was removed from the config files
yesterday.

ok kamil christos

branches: 1.31.2;
Add KAUTH_MACHDEP_SVS_DISABLE and add support to secmodel_securelevel(9).

Disabling SVS is denied at securelevel 1 and above.

branches: 1.30.22; 1.30.28;
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.

branches: 1.29.2;
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.

branches: 1.28.2;
KNF fix. spaces vs. tab

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.

branches: 1.26.2; 1.26.6;
fix secmodel implementation of CPU_UCODE.
ok wiz@ for the manpages
ok elad@

Support CPU microcode loading via cpuctl(8).
Implemented and enabled via CPU_UCODE kernel config option
for x86 and Xen Dom0.
Tested on different AMD machines with different
CPU families.

ok wiz@ for the manpages
ok releng@
ok core@ via releng@

secmodel_eval(9) may want to access securelevel before it is set
to the right value, so init it first before registering secmodel(9).

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.

branches: 1.22.2;
Whitespace fixes.

Load entropy at system boot (only works at securelevel < 1); save
at system shutdown. Disable with random_seed=NO in rc.conf if desired.

Goes to some trouble to never load or save to network filesystems.

Entropy should really be loaded by the boot loader but I am still
sorting out how to pass it to the kernel.

branches: 1.20.12;
Compare against initproc, not pid 1, to check if it's init (unify).

Unify: >= 0 -> > -1.

Cosmetic changes to declarations. No functional change.

Factor out a block of code that appears in three places (Veriexec, keylock,
and securelevel) so that others can use it as well.

Introduce time_wraps() to check if setting the time will wrap it (or
close to it). Useful for secmodels.

Replace open-coded form with it in secmodel code (securelevel, keylock).

Note: I need to find a way to make secmodel_keylock.c ~<100 lines.

Create securelevel variable under securelevel node.

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

Implement the vnode scope and adapt tmpfs to use it.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/07/04/msg005404.html

Extend the existing security models for upcoming gpio(4) changes.
Reviewed and feedback by Elad Efrat.

Sprinkle some switch defaults.

branches: 1.10.2;
merge christos-time_t

Remove LKMs and switch to the module framework, pass 1.

Proposed on tech-kern@.

branches: 1.8.6; 1.8.8; 1.8.12; 1.8.18; 1.8.20;
Tons of process scope changes.

- Add a KAUTH_PROCESS_SCHEDULER action, to handle scheduler related
requests, and add specific requests for set/get scheduler policy and
set/get scheduler parameters.

- Add a KAUTH_PROCESS_KEVENT_FILTER action, to handle kevent(2) related
requests.

- Add a KAUTH_DEVICE_TTY_STI action to handle requests to TIOCSTI.

- Add requests for the KAUTH_PROCESS_CANSEE action, indicating what
process information is being looked at (entry itself, args, env,
open files).

- Add requests for the KAUTH_PROCESS_RLIMIT action indicating set/get.

- Add requests for the KAUTH_PROCESS_CORENAME action indicating set/get.

- Make bsd44 secmodel code handle the newly added rqeuests appropriately.

All of the above make it possible to issue finer-grained kauth(9) calls in
many places, removing some KAUTH_GENERIC_ISSUSER requests.

- Remove the "CAN" from KAUTH_PROCESS_CAN{KTRACE,PROCFS,PTRACE,SIGNAL}.

Discussed with christos@ and yamt@.

Pull in my modules code for review/test/hacking.

vp->v_rdev, not vp->v_un.vu_specinfo->si_rdev.

branches: 1.5.2;
Remove systrace. Ok core@.

branches: 1.4.2; 1.4.6; 1.4.10; 1.4.14;
Deprecate KAUTH_REQ_SYSTEM_TIME_BACKWARDS, as it was merged into
KAUTH_REQ_SYSTEM_TIME_SYSTEM.

Refactor time modification checks and place them in the secmodel code.

okay christos@

Fix a long time issue where the securelevel secmodel would explicitly
allow certain operations.

The suser module of the bsd44 secmodel code was made aware of the missing
operations that were explicitly allowed in the securelevel module, and
the logic in the latter was modified to a default defer, deny where not
allowed.

This concept, which is the correct way to write secmodel code, was first
brought up by pavel@ a long time ago.

okay christos@.

branches: 1.1.2;
Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

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.

branches: 1.4.48;
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.

branches: 1.3.12; 1.3.16;
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

Implement the vnode scope and adapt tmpfs to use it.

Mailing list reference:

http://mail-index.netbsd.org/tech-kern/2009/07/04/msg005404.html

branches: 1.1.2; 1.1.4; 1.1.8; 1.1.16; 1.1.18; 1.1.28;
Make securelevel a "secmodel" of its own.

While it's true that it's part of the traditional 4.4BSD security model,
there may come a time where a different "primary" security model used for
fine-grained privileges (ie., splitting root's responsibilities to various
privileges that can be assigned) may want to still have a securelevel
setting.

Idea from Daniel Carosone:

http://mail-index.netbsd.org/tech-security/2006/08/25/0001.html

The location of the removed files, for reference, was:

src/secmodel/bsd44/secmodel_bsd44_securelevel.c
src/secmodel/bsd44/securelevel.h

branches: 1.1.4;
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

s/securlevel/securelevel/ in comment.

wg(4): Allow non-root to retrieve information other than the private
key and the peer preshared key.

Add kauth(9) enums for wg(4) and add use them in suser secmodel.

Refines fix for PR 57161.

more strip(4) removal, this time in kauth(9)

branches: 1.55.20;
Add IP_BINDANY, IPV6_BINDANY which can be used to bind to any address in
order to implement transparent proxies.

Make it clear that only KAUTH_MACHDEP_SVS_DISABLE is deprecated.

KAUTH_MACHDEP_SVS_DISABLE is deprecated.

sysctl machdep.svs.enabled can't be changed anymore
at runtime because it's now a boot option.

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.

Explicitly cast pointers to uintptr_t before casting to enums. They are
not necessarily the same size. Don't cast pointers to bool, check for
NULL instead.

branches: 1.50.6;
Add the NVMM_CTL ioctl, always privileged regardless of the permissions of
/dev/nvmm. We'll use it to provide a way for an admin to control the
registered VMs in the kernel.

Add an associated wrapper in libnvmm.

Provide a sysctl kern.expose_address to expose kernel addresses in
sysctl structure returns for non-root. Defaults to off. Turning it
on will restore sockstat/fstat and friends for regular users.

Introduce KAUTH_REQ_PROCESS_CANSEE_KPTR, and use it in the already-existing
modstat code. No real functional change.

Add KAUTH_REQ_PROCESS_CANSEE_EPROC, and use it for the kern.proc node.
Same permission as before, so no functional change.

Retire ipkdb entirely. The option was removed from the config files
yesterday.

ok kamil christos

Remove KAUTH_MACHDEP_X86PMC, now unused.

branches: 1.44.2;
Add KAUTH_MACHDEP_SVS_DISABLE and add support to secmodel_securelevel(9).

Disabling SVS is denied at securelevel 1 and above.

branches: 1.43.4;
Make the PMC syscalls privileged.

branches: 1.42.10;
Add kernel code to support intrctl(8).

branches: 1.41.6;
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.

branches: 1.40.2;
kill some -Wunused-but-set-variable warnings

branches: 1.39.2;
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.

fix secmodel implementation of CPU_UCODE.
ok wiz@ for the manpages
ok elad@

Support CPU microcode loading via cpuctl(8).
Implemented and enabled via CPU_UCODE kernel config option
for x86 and Xen Dom0.
Tested on different AMD machines with different
CPU families.

ok wiz@ for the manpages
ok releng@
ok core@ via releng@

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.

branches: 1.35.2;

Load entropy at system boot (only works at securelevel < 1); save
at system shutdown. Disable with random_seed=NO in rc.conf if desired.

Goes to some trouble to never load or save to network filesystems.

Entropy should really be loaded by the boot loader but I am still
sorting out how to pass it to the kernel.

branches: 1.34.4; 1.34.14;
Use the socket credentials, now that we have them, instead of uidinfo.

Rename KAUTH_GENERIC_CANSEE to KAUTH_GENERIC_UNUSED1 and remove handling for
the former.

(I'll remove it from the header next time a kernel version bump happens.)

Fixed security.models.suser.curtain to deny when uid does not match.
OK pooka@

- Move kauth_init() a little bit higher.

- Add spec_init() to authorize special device actions (and passthru too for
the time being). Move policy out of secmodel_suser.

Extract usermount policy to its own routine.

Add a (weak aliased) machdep_init() as a place to do machdep initialization
that can't happen as early as the other init functions as called from
cpu_startup() -- for example, register kauth(9) listeners.

Put unprivileged policy in the x86 code; used by i386, amd64, and xen.

Allow root to do things that the subsystem allows as well (unify).

This is important in the case someone manages to load the suser secmodel
and remove subsystem specific listeners; without this change they would
have ended up with a root user that can only do privileged operations.

- Add usermount_common_policy() that implements some common (everything
but access control) user mounting policies: enforced MNT_NOSUID and
MNT_NODEV, no MNT_EXPORT, MNT_EXEC propagation. This can be useful for
secmodels that are interested in simply adding finer grained user mount
support.

- Add a mount subsystem listener for KAUTH_REQ_SYSTEM_MOUNT_GET.

Move KAUTH_NETWORK_BIND::KAUTH_REQ_NETWORK_BIND_PORT policy back to the
subsystem (or close to it).

Note: Revisit KAUTH_REQ_NETWORK_BIND_PRIVPORT.

Move policies for KAUTH_PROCESS_{CANSEE,CORENAME,STOPFLAG,FORK} back to
the subsystem.

Note: Consider killing the signal listener and sticking
KAUTH_PROCESS_SIGNAL here as well.

One less include.

Make this file a little bit smaller by collapsing cases.

Move clockctl policy exception back to the subsystem.

secmodel_bsd44_curtain -> secmodel_suser_curtain (static).

Move default network interface policy back to the subsystem.

Finish moving socket policy to the subsystem.

Move sched policy back to the subsystem.

Move firewall/NAT policy back to respective subsystems (pf, ipf).

Note: the ipf code contains a lot of ifdefs, some of them for NetBSD
versions that are no longer maintained. It won't make the code more
readable, but we should consider removing them.

Move kevent policy back to the subsystem.

Put module loading policy back in the subsystem.

Revisit: consider moving kauth_init() above module_init() in main().

Put the tty opening policy back in the subsystem.

Remove include we don't need from the secmodel code.

Move some of the socket policy back to the subsystem.

Remove include we don't need in the secmodel code.

Put signal delivery policy back in the subsystem.

Remove includes we don't need.

Move routing socket security policy back to the subsystem.

- Squeeze function declarations where possible,
- KAUTH_RESULT_DEFER is the default (set at the beginning of each listener)
and as such does not need to be set explicitly in the switches.

Put procfs policy back in the subsystem.

Stick nice policy in its own subsystem and call the listener "resource"
rather than "rlimit"...

Move rlimit policy back to the subsystem.

For this we needed proc_uidmatch() exposed, which makes a lot of sense,
so put it back in sys_process.c for use in other places as well.

Move ptrace's security policy back to the subsystem itself.

Add a ptrace_init() so we have a place to register the listener; called
next to ktrinit().

Let the ipkdb subsystem allow operations related to it rather than wrongly
doing so in the suser secmodel.

Move psets security policy back to the subsystem and keep suser logic only
in the suser secmodel code.

Move ktrace's subsystem security policy to the subsystem itself, and keep
just the suser-related logic in the suser secmodel.

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

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.

branches: 1.2.48;
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.

branches: 1.1.4; 1.1.14; 1.1.18;
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