linux-security-module October 2008 archive
Main Archive Page > Month Archives  > linux-security-module archives
linux-security-module: Re: path based security in 4 easy steps w

Re: path based security in 4 easy steps with minimal kernel changes

From: Shaya Potter <spotter_at_nospam>
Date: Mon Oct 27 2008 - 02:31:51 GMT
To: Casey Schaufler <casey@schaufler-ca.com>


Casey Schaufler wrote:
> Shaya Potter wrote:
>> I figure this might be just beating my head against a wall, as people >> aren't interested, but here's a bit more of a roadmap on how I believe >> path based security can be easily implemented with no changes to the >> kernel besides the addition of a one or 2 more LSM hooks >>
>
> I think you are unlikely to convince many people until you can produce
> code that demonstrates the viability of your scheme. I am curious to see
> how well your cookie scheme works.

I know, I hope to get to it, but busy trying to finish my phd. I hope to proceed in a few steps which should make it easy for people to plug things in

  1. add security pointer to dentry
  2. figure out the new hooks that are needed (allocate/free/set dentry security data, revalidate dentry hook....)
  3. write a null LSM module that basically just provides wrapper functions for the hooks that allocate security object, could check security object in permission and free it appropriately.
  4. extend LSM module to show it can handle renames via the cookie scheme I described (implement rename and revalidate hooks)

might take a little bit of time though even though each step is relatively easy.

in re a bit more detail on #1 and #2, do these changes seem reasonable

  1. add security pointer in dentry
  2. allocate space for dentry security object add - dentry_alloc_security modify - d_alloc()
  3. free space used by dentry security pointer add - dentry_free_security modify - __d_free()
  4. set/verify/update security object add - dentry_lookup modify - good Q. most complicated, might be easiest to redo revalidate code paths.

Thoughts on the best location within the lookup() code paths? with a stackable fs it was easy as I could just provide my own revalidate function. As do_revalidate() is only called if ->d_revalidate() exists.

thought would be to push

the

if (dentry && dentry->d_op && dentry->d_op->d_revalidate)

check into do_revlidate() itself and have it just return dentry if d->revalidate doesn't exist.

ideas on best location for ensuring "up to dateness" of dentry would be most appreciated.

thanks,

shaya -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html