Commit Graph

9 Commits

Author SHA1 Message Date
ad
0efea177e3 Remove LKMs and switch to the module framework, pass 1.
Proposed on tech-kern@.
2008-11-12 12:35:50 +00:00
elad
c27d5f30b6 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@.
2008-01-23 15:04:38 +00:00
ad
bbc79e58a6 Pull in my modules code for review/test/hacking. 2008-01-16 12:34:50 +00:00
ad
7f75548e50 vp->v_rdev, not vp->v_un.vu_specinfo->si_rdev. 2008-01-14 17:56:21 +00:00
ad
2ecdf58c2c Remove systrace. Ok core@. 2007-12-31 15:31:24 +00:00
elad
41b84354cb Deprecate KAUTH_REQ_SYSTEM_TIME_BACKWARDS, as it was merged into
KAUTH_REQ_SYSTEM_TIME_SYSTEM.
2007-11-25 09:39:26 +00:00
elad
abb7851f4d Refactor time modification checks and place them in the secmodel code.
okay christos@
2007-11-25 00:35:26 +00:00
elad
b242e18ba4 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@.
2007-11-24 20:47:14 +00:00
elad
6887492c26 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
2007-11-21 22:49:05 +00:00