PATCH: "Kernel Insider" (security optimization)

PATCH: "Kernel Insider" (security optimization)

[bruj0]

Hello, i wrote a modification for kernels 2.4.x, actually it can be
lodaded as a module and its not intrusive. I would love to get you opinions,
critics, flames about it. Plase CC: me becouse im not in the list. thanx
The whole package with a intructions is at
http://securityportal.com.ar/files/insider-1.6.tar.gz

This is the description:
INSIDER
-------
Its a linux kernel modification, that allows to decide wich uid, pid or
file can open a tcp socket in listening state.
The changes to the kernel are really insignificant, only to export 2
variables.
When  a program tries to open a port it first makes a md5 checksum
of the file and compares it with the config list then it compares the user
id and finally the pid.
The policy is to "DENY" everything that is not in the allowed list.

Bruj0

Re: PATCH: "Kernel Insider" (security optimization)

[David Wagner]

>Its a linux kernel modification, that allows to decide wich uid, pid or
>file can open a tcp socket in listening state.

- Putting access control on listen() [rather than socket()/bind()]
  seems like a really bad idea.  In particular, in some cases one can
  bind to a port and receive messages on it without ever calling listen(),
  if I am not mistaken.

- The use of sock_i_uid(sock) seems poorly chosen; if sock->socket==NULL,
  then your module will mistakenly think that the action was requested by
  uid 0.  In general, the return value from sock_i_uid() cannot be trusted
  for permission checks for several reasons.  Why don't you simply use
  current->euid for your permission checks?

- Checking pid's doesn't seem like a good idea.  If a process listed in
  allowed_pids dies, then some other malicious process can wrap the pid
  space and take over that trusted pid, thereby subverting your access
  control policy.

- Are you aware of previous work on this subject?  In particular, you
  might enjoy checking out the Janus project, which is a much more general
  implementation of this idea: http://www.cs.berkeley.edu/~daw/janus/

- You should really join the mailing list hosted by Crispin Cowan working
  to develop kernel hooks for this sort of kernel security modification.