Re: Revising the remaining IPC hooks

mike_wrayat_private

From: Stephen Smalley <sdsat_private>
To: <linux-security-moduleat_private>
Sent: 11 October 2002 16:21
Subject: Re: Revising the remaining IPC hooks

>
> I see that Linus' bk tree contains the base set of LSM IPC hooks now, so
> I'd like to resolve the issues with the remaining hooks so that we can
> submit them as well.  See below for some followup on my earlier comments.
>
> ....
> On further thought, I think it would be preferable to drop the separate
> ipc_getinfo hook and instead call the appropriate *ctl hook for the *_INFO
> ctl commands with a NULL object pointer.  This has the advantage of
> permitting the security module to safely interpret the cmd value and
> leaves us with one less hook to justify.  Notice that there are already
> existing hooks that may be called with NULL parameters in certain cases,
> e.g. file_mmap when mapping anonymous memory.  See the attached patch,
> which includes the changes from my earlier messsage for moving certain
> *ctl hook calls as well as the changes for eliminating the ipc_getinfo
> hook.  Notice that SELinux still preserves the same functional behavior by
> moving the ipc_getinfo checking into its *ctl hook functions.
>

I like this better. This lets the hooks know what kind of IPC object they
are dealing with, and passes its indentity when relevant.

> > 2) More generally, I was wondering whether we should drop all id
> > parameters from the IPC hooks, as they seem to have little value except
> > possibly auditing (which is the only way in which SELinux uses them now,
> > and even that can't be done consistently since it isn't available in
> > ipc_permission or *alloc_security).  Is anyone using the id values, and
if
> > so, how?
>
> No one has responded yet to this question.  Should I proceed with removing
> the id parameters from all of the IPC hooks?
>

Sorry about my late response to this. With the propsed changes I have no
problem with dropping the id as it's available from the relevant struct
kern_ipc_perm.

> > 4) In sem.c, sem_revalidate() is called at certain points to revalidate
> > access to a semaphore set.  sem_revalidate calls ipcperms(), so the
> > ipc_permission hook will be called as well, but no finer-grained LSM
hook
> > is called in these cases, so any finer-grained controls are not
> > revalidated.  In the case of semctl, we could certainly insert another
> > call to the sem_semctl hook after the sem_revalidate calls to revalidate
> > any finer-grained control, but in the case of alloc_undo, it wasn't
> > obvious what the right fix would be.  This naturally raises the general
> > issue of whether the fine-grained hooks are maintainable in the IPC
code.
>
> On further thought, I don't think we want to try inserting calls to the
> finer-grained hooks after sem_revalidate calls, since we would have to do
> the same locking and validation performed by sem_revalidate.  We could
> insert a call to the fine-grained sem_semop hook into sem_revalidate if we
> drop the 'sops' and 'nsops' parameters.  However, at that point, sem_semop
> will be little different than ipcperms, particularly if we drop the id
> parameters.  The only reason to retain it is if we truly need to
> distinguish semop operations from other calls to ipcperms() by the
> semaphore code.  Should we remove the sem_semop hook entirely?
>

Seems reasonable to me.

Mike

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