On 12/8/2010 6:25 AM, Kyle Moffett wrote: > On Tue, Dec 7, 2010 at 12:34, Stephen Smalley <stephen.smalley@xxxxxxxxx> wrote: >> On Tue, Dec 7, 2010 at 11:56 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
