linux-kernel - Re: [TOMOYO #11 (linux-next) 01/11] Introduce new LSM hooks where vfsmount is available.

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <48FCF6CA.2060406@cs.columbia.edu>
Date:	Mon, 20 Oct 2008 17:23:22 -0400
From:	Shaya Potter <spotter@...columbia.edu>
To:	crispin@...spincowan.com
CC:	Kentaro Takeda <takedakn@...data.co.jp>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Chris Wright <chrisw@...s-sol.org>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Toshiharu Harada <haradats@...data.co.jp>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Al Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@....de>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [TOMOYO #11 (linux-next) 01/11] Introduce new LSM hooks where
 vfsmount is available.

crispin@...spincowan.com wrote:
> Quoting Shaya Potter <spotter@...columbia.edu>:
>> I know I'm late to the game in this, but as I recently asked about this
>> and didn't get an answer, I'll re-ask my approach.
>>
>> Why can't you do this
>>
>> in lookup()
>>
>> - resolve rules (not for single process, but for all processes) for
>> said path and tag dentry (seem to already have a hook)
>>
>> in permission()
> 
> Because it doesn't work 
> http://kerneltrap.org/mailarchive/linux-fsdevel/2007/6/8/319446
> 
> Quick summary: The difference between the pathname model and the label 
> model is dynamism. The accessi really is determined by the pathname to 
> the file that you used to access the file. If you try to compute access 
> based on attributes tagged onto the file, then you have to re-compute 
> those attributes every time someone renames a file.

ok.  simple question then so why not just recompute them every every 
rename?  are rename's that common relative to all other file operations 
where we care?

invalidate the dentry on rename, it will force it to go back through 
lookup() instead of being found in the cache and shouldn't it implicitly 
recalculate it?

I don't see why one can't maintain the dynamism with a focus just on 
lookup and permission (minus the multiple names to the same object 
issues which is a security problem waiting to happen anyways)

I could very well be missing something, I'm fully ready to eat crow.  I 
just felt it should be asked.
--
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/