Re: LSM Patch Additions for CAPP (C2) Audit Trails

chrisat_private

* Casey Schaufler (caseyat_private) wrote:
> 
> This is SGI's initial LSM patch for C2 (now Controlled
> Access Protection Profile (CAPP)) auditing. It is not
> complete. There will be more coming. The work left to
> do is outlined in the notes below.
<snip>
> System Calls needed:
> 
> get / set capability mask
> get/set login user id (luid)
> get arbitrary process audit mask
> set audit mask of <process, proc. group, all or uid>

are these needs met by the security syscall multiplexor, and the
opaque security blob attached to the task_struct?

general comments:

in general, throwing out any kernel logic and replacing with hook is not
acceptable.  we are striving to maintain kernel logic, and add hook
functionality.  the std_sec idea is indeed useful, but it makes the
kernel patch very invasive, and is likely to flop when presented to the
kernel developers.  some things to keep in mind.  we have placed a hook in
the capable() call.  this gives the coarse grained permissive hook that
allows us to move capabilities into a security module.  so replacing
capable() calls with other hooks is inappropriate.  all other hooks are
deemed restrictive.  so it is especially important to keep the capable
call (and it's co-located kernel DAC logic) in the kernel to preserve an
override mechanism...then add any restrictive hooks.  where possible, we
have placed hooks in/near kernel permission checks (i.e. capable(),
permission, etc.).

other than the use of close_on_exec and dup which need the fd directly
what value do you get from the fd that you can't get from the filp?

also, things that are added to the interface that basically do strict
syscall interposition are a tough sell.  we have the intention of
interposing at the kernel object level (useful as the middle of the
audit needs, but not useful in opening and closing the audit event).
some examples:
 * [f]chmod, hook for setattr already provides security
 * [f]truncate, hook in permission (for truncate, and on open for
 ftruncate), plus setattr, plus the actual truncate hook in mm/memory.c

so as mentioned before, it would be useful to see your patch broken into
pieces.  i'd like to see the following two pieces first.
1) new hooks (many of these are addressed in Stephen's email on july 2).
these are things we can consider accepting right away.
2) changes to hook (i.e. change to fd, additional parameters).  this way
we can deal with the parametric needs of each hook.

then we can look at the more audit specific hooks and argue the virtues
of auditing needs for syscall interpostion, and the changes you've made
that view kernel exported symbols (/proc/ksyms) as a reasonable layer to
interpose (i.e. the vfs_permission, and changeattr hooks).

specific comments:

we will move all post_xxx hooks and add error as hook argument.

will not accept the vfs_permission change, it moves out all kernel
logic.  yes, the vfs_permission symbol is available to modules, but if
you look in the kernel the only place it is used is in nfs_permission
which is the inode_operation for an nfs inode (so this gets called from
permission(), after our hook).

changeattr hook is not acceptable, it is there to push kernel logic into
module.  setattr hook is called before inode_change_ok.  while
inode_change_ok is exported and can be called directly from modules, it
is used in fs implemenations of the i_op->setattr function which is
called from kernel after the setattr security hook.

ptrace changes are unclear.  the removal of kernel logic is not
acceptable, and i can't tell if the pid is all that useful, it is always
the pid of the child task_struct (second argument to the ptrace call).
for security we haven't needed the information the request provides,
since the TRACEME or ATTACH requests are prerequisite (and distinct by
the child task_struct), but they could be useful to provide read-only
tracing as well as audting.

we already have many hooks in the execve code path.  the set_label function
should^Wused to ;-) give you the filename you need.  it's really preferrable
to place checks in arch independent code (so fs/exec.c/do_exec() in
this case).

hmmm...this is going to get long, perhaps i'll hold off until your patch
is broken into smaller pieces.

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module