| Main Archive Page > Month Archives > linux-security-module archives |
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
- add security pointer to dentry
- figure out the new hooks that are needed (allocate/free/set dentry security data, revalidate dentry hook....)
- 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.
- 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
- add security pointer in dentry
- allocate space for dentry security object add - dentry_alloc_security modify - d_alloc()
- free space used by dentry security pointer add - dentry_free_security modify - __d_free()
- 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