Serge E. Hallyn wrote:
quoted text
> Quoting Kentaro Takeda (takedakn@nttdata.co.jp):
>   
>> Serge E. Hallyn wrote:
>>     
>>> Unfortunately I think that is a shortcoming in the security_path_*
>>> patchset.  Unfortunate bc that is going to be a pain to work out.
>>>       
>> Thanks for your constructive and tough suggestion. ;-)
>>
>>     
>>> So for starters,
>>> both vfs_mknod and vfs_create do may_create, so just pull that
>>> into the callers.
>>>       
>> Do you mean that we should move DAC code to all the caller of vfs_* ? 
>>     
>
> That's not reasonable, is it.
>
> The rule thus far has been 'DAC before MAC'.  Question to all:  do we
> insist on keeping it that way?
>
> If the answer is yes, then the security_path_hooks patch is inherently
> wrong.
>
> If the answer is no, then Kentaro doesn't need to resort to this
> ugliness to try and get may_delete() called before his MAC code, only to
> have may_delete() called a second time from the vfs_* functions.
>
> -serge
>
>   

I have always believed that MAC should come first, then DAC, because
MAC may care if you can see the mode bits. The current DAC before MAC
is an artifact of the desire for the LSM to behave cleanly as a
strictly additional mechanism. From an ideal security perspective
MAC should be first, but the pragmatic DAC first isn't going to cause
too much grief. If Tomoyo wants to do what I think is the right thing,
well, it's OK with me.



--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/