Re: Other pending changes

ratliffat_private

On Tue, 5 Feb 2002, Chris Wright wrote:
> the shm_close hook (as far as Openwall is concerened) is not fully
> resolved yet (IIRC).
To expand upon this:

There are a couple of issues with the SECURE_SHM part of owlsm that 
have greater implications on LSM and could benefit from community input. 

A little background:
The SECURE_SHM part of Openwall patch "automatically destroys shared 
memory segments when their attach count becomes zero after a detach or a 
process termination. It will also destroy segments that were created, but 
never attached to, on exit from the process." The shm_close hook is 
required do the first part, it sets SHM_DEST on the shared memory segment 
when the attach count becomes 0 so that it is destroyed. 

However, if the segment has never been attached to, shm_close is never 
called. So we need to add this functionality to a function called by the 
task_ops->free_security hook. This has 2 implications: 1) it alters the 
functionality of SECURE_SHM by delaying destroying the shared memory 
segments until the parent has waited for the process, so zombies will keep 
their unattached shared memory segments. (This is not a problem, just an 
annoyance) 2) it means that our module needs access to currently 
unexported symbols (shm_ids and shm_destroy). It also needs access to the 
definition of shm_ids structure (struct ipc_ids) which is currently in 
ipc/util.h rather than include/linux/ipc.h (that is, it is non-public).

The bottom line:
SECURE_SHM is an example of desirable functionality that is not easily 
implementable in LSM due to lack of access to non-public interfaces. Do 
you all see a way around this that I am missing? 

I don't think that this is unique to SECURE_SHM, but I am not sure if it 
is due to the fact that SECURE_SHM is not access control functionality, or 
whether it is just because it touches a part of the kernel that exports 
very few of its symbols. I can see other module writers having this 
problem and I'd like to know what the LSM community's opinion is.

Thanks,

Emily

PS. As always, thanks to Chris Wright for discussing these issues with me 
on IRC and pointing me in the right direction.

Emily Ratliff
IBM Linux Technology Center, Security

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