Messages in this thread | | | Date | Tue, 30 Sep 2008 19:33:32 -0700 | From | Casey Schaufler <> | Subject | Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions. |
| |
Serge E. Hallyn wrote: > 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.
| |