Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.

Stephen Smalley
2008-09-30T16:15:13Z

On Tue, 2008-09-30 at 10:45 -0500, 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?

It isn't a hard rule; there are already some hooks that occur before the
DAC checking, e.g. setattr, because the DAC checking happens in the fs
code as part of the inode op. But when possible, we prefer DAC before
MAC for SELinux so that we don't get noise in the audit logs from
harmless application/library probing that would be denied by DAC anyway.
Same issue would seemingly apply for learning modes of TOMOYO or
AppArmor.

> 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.

--
Stephen Smalley
National Security Agency