Next message: Wayne Salamon: "Re: Patch to swapon/swapoff"
Woops, forgot to CC the list.
attached mail follows:
On Wed, 2001-11-14 at 09:37, Emily Ratliff wrote:
> Hi Chris & Nick,
>
> Thanks for talking to me about this. I have been watching the list and did
> see that you did that. The reason that I didn't do it that way originally
> was that Greg asked me to do them separately. My plan was to work on the
> stacking code, using SELinux's example of stacking with the capabilities
> module as an example. Having everything in one module makes sense and is
> fine with me.
>
> I noticed that you also changed some code to keep the module closer to the
> Openwall original than grsecurity's version. I am glad that you did that
> and would like that to be a design goal whenever possible. When I checked
> with Solar Designer to see if he was ok with us including the Openwall
> patches in LSM as modules, he said that he hoped that what we produced
> would be of higher quality than grsecurity.
>
> I think it makes sense to coordinate our efforts. First of all, thank you,
> Nick, for doing the modules and your kind note that my module made a good
> starting point.
>
> The modules remaining are SECURE_PROC and SECURE_SHM. SECURE_FD_0_1_2
> should also be added based on Richard Offer's code. We need to drive out
> the memory leak and there is an issue that it requires an additional hook.
> The hook wasn't accepted the first time around, but it was proposed mostly
> as a proof of concept. Are new hooks acceptible at this stage of LSM or
> should it wait until Phase 2?
>
> I haven't had a chance yet, but I will look over the SECURE_LINK and
> SECURE_FIFO code. I also would like to do at least one more of SECURE_PROC
> and SECURE_SHM but I haven't started either yet. Are you working on one or
> both, Nick?
>
Currently SECURE_PROC is not easily doable without
inode_ops->permissions containing a dentry struct. I spoke with chris
in #lsm-dev today and he suggested a possible temporary fix using
file_ops->open until the new permission structure goes into effect in
2.5. Although once this is added, SECURE_PROC should be fairly straight
forward.
I made an attempt at SECURE_SHM this evening, and im not sure about a
few things.
1. OpenWall's SECURE_SHM contists of three chunks of code, the two in
ipc/shm.c, (shm_close(), a check for shm_nattch, and the addition of
shm_exit()). The check for shm_nattach in shm_close uses killseg(id),
if shm_nattch <= 0. What im not sure is how would it be possible to
kill the ID as shm_ops->free_security is in its current state. id is
initialized as id = SWP_OFFSET(shmd->vm_pte) & SHM_ID_MASK, also of note
is shp = shm_segs[id], which is looped threw in shm_exit(), but is
nowhere to be seen in the 2.4 IPC code.
2. The same holds true for the shm_exit() function which destroys
segments that where created, but not attached to. This is done with a
for loop, which uses the after mentioned non-existant shm_seg array. It
uses killseg(id) after checks of shp == IPC_UNUSED || shp == IPC_NOID,
shp->u.shm_cpid != current->pid, and shm_nattch <= 0, as well.
3. And the third chunk of code in ipc/util.c, which im guessing would
not apply with LSM.
Im not quite sure how to go about this, so please feel free to finish it
up. :)
> Yes, the copyright holder should be IBM, not me, you can put my email
> address in as the contact info by the copyright.
>
> Thanks,
>
> Emily
>
> --
> Emily Ratliff
> IBM Linux Technology Center, Security
>
>
>
Thanks!
Nick Bellinger
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30
: Thu Nov 15 2001 - 01:29:49 PST