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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1222791288.19676.114.camel@moss-spartans.epoch.ncsc.mil>
Date:	Tue, 30 Sep 2008 12:14:48 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Kentaro Takeda <takedakn@...data.co.jp>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, haradats@...data.co.jp,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.


On Tue, 2008-09-30 at 10:45 -0500, Serge E. Hallyn wrote:
> Quoting Kentaro Takeda (takedakn@...data.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

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