[PATCH] LSPP audit enablement: storing selinux ocontext and scontext

[Stephen Smalley]

On Thu, 2005-10-13 at 00:30 -0500, Dustin Kirkland wrote:
> On 10/12/05, Klaus Weidner <klaus at atsec.com> wrote:
> > In an IRC discussion about IPC object audit today, Chris Wright mentioned
> > that he's concerned about multiple or missing records and also general
> > code aesthetics.
> >
> > I'm not very familiar with the code, but I think it may be an option to
> > put the hooks in the *_checkid() and *get() functions instead of hooking
> > ipcperm(), those seem to be used more consistently. It would mean a
> > minimal slowdown in non-permission-checking calls as a tradeoff for
> > a cleaner interface, assuming that this would indeed get rid of
> > duplication.
> 
> Stephen-
> 
> I'm curious about your take on this...  The code is hooked in
> ipcperms() and near the DAC checks mainly because of a discussion on
> the (then closed) LSPP list on/around May 19, 2005.  Just wondering if
> you have any objections.

Leveraging ipcperms only seemed natural (for both LSM and audit), given
its wide (but admittedly incomplete and coarse-grained) coverage.  I'm
not sure why the overlap/duplication is a concern for audit if it isn't
already a concern for the corresponding LSM hooks.  In the SELinux case,
we chose to implement a coarse-grained check there even though we had
finer-grained checks in the other hooks just to ensure that all access
was mediated, because we had greater confidence that ipcperms would be
maintained and used in any further System V IPC development, whereas
fine-grained LSM hooks have a way of disappearing from the tree when the
underlying code is rewritten.

You'd have to audit (code audit) the current usage of *checkid to see
whether it is a suitable location for audit (security audit) purposes.
For sem, I see it being used in find_undo and exit_sem, and the latter
doesn't tolerate failure (BUG_ON) from it, so you'd have to adjust for
possible audit failures.  For msg, it happens outside of the loop on a
msgsnd and msgrcv, unlike the permission checking, which might be ok for
audit (unless you are concerned about the IPC object being relabeled
during the potential sleep, but no interface exists for relabeling IPC
objects yet).

-- 
Stephen Smalley
National Security Agency