From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.3.250]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id oB8EnkIe026319 for ; Wed, 8 Dec 2010 09:49:46 -0500 Received: from smtp104.prem.mail.sp1.yahoo.com (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with SMTP id oB8EnjAS020701 for ; Wed, 8 Dec 2010 14:49:45 GMT Message-ID: <4CFF9B07.3070201@schaufler-ca.com> Date: Wed, 08 Dec 2010 06:49:43 -0800 From: Casey Schaufler MIME-Version: 1.0 To: Kyle Moffett CC: Stephen Smalley , Eric Paris , penguin-kernel@i-love.sakura.ne.jp, selinux@tycho.nsa.gov, sds@tycho.nsa.gov, jmorris@namei.org, linux-security-module@vger.kernel.org, viro@zeniv.linux.org.uk, hch@lst.de, Casey Schaufler Subject: Re: [RFC PATCH 1/2] fs/vfs/security: pass last path component to LSM on inode creation References: <20101203214518.30001.89859.stgit@paris.rdu.redhat.com> <4CF9C1A1.7050603@schaufler-ca.com> <1291498481.4929.77.camel@localhost.localdomain> <4CFB4191.3090106@schaufler-ca.com> <4CFE4B9E.3080408@schaufler-ca.com> <4CFE6748.8050803@schaufler-ca.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On 12/8/2010 6:25 AM, Kyle Moffett wrote: > On Tue, Dec 7, 2010 at 12:34, Stephen Smalley wrote: >> On Tue, Dec 7, 2010 at 11:56 AM, Casey Schaufler wrote: >>> Let's assume for the moment that no one has a significant objection >>> to adding the component name to inode_init_security. I am not >>> suggesting that what gets passed to inode_init_security is >>> insufficiently general. I am asking if there are other hooks that >>> also ought to have the component name as one of their parameters. >>> Yes, I understand the concept of "if it ain't broke ...", and that >>> may suffice at this point, and if not the fact that no one would be >>> using the component name in those other hooks definitely would. I >>> expect that when someone comes along with a new LSM that does access >>> controls based on the final component* they aren't going to suffer >>> unnecessary resistance from the SELinux community as they add the >>> component name as a parameter to other hooks. >>> >>> ---- >>> * For example, only files suffixed with ".exe" can be executed and >>> only files suffixed with ".so" can be mmapped. >> I think you can already achieve that via the pathname hooks, but if >> not and you want it, go for it. > Actually, there are still a few remaining hooks which might actually > be useful to add the last path component to even in SELinux. While > you of course cannot (and should not) *change* the label of a file in > a link() or rename() operation, it would potentially be useful to deny > an operation based on the old label and the new name that is being > passed in. It would also make sense if the file create() action was > able to match on the same requirements as the file "type_transition". > > EG: To prevent a compromised web application from messing with > otherwise writable .htaccess files in its data folders, you ought to > be able to do something like this (although this does imply > introducing some sort of matching order, where a "deny_name" with a > matching name is applied instead of a more-generic "allow"): > > deny_name my_web_app_t my_web_app_data_t file:rename ".htaccess"; > allow my_web_app_t my_web_app_data_t file:rename; > > deny_name my_web_app_t my_web_app_data_t file:link ".htaccess"; > allow my_web_app_t my_web_app_data_t file:link; > > Cheers, > Kyle Moffett > Thank you Kyle. I was hoping someone would follow up on that. I owe you (another?) beer. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.