Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: [RFC][PATCH] Control ability to have a writable executable mapping Date: Tue, 09 Nov 2004 13:40:03 -0500
The attached kernel patch adds a new task->self wxpage permission check for wx private file mappings and for wx anonymous mappings to address this gap. The task->file execute permission check is still applied to private file mappings even when the wxpage check is performed for consistency (ensure that policy always allows rx mapping whenever it allows rwx mapping). There is also a small change to avc_audit() to help in policy debugging for these checks, as the exe= information is suppressed due to the mmap_sem being held by the caller. Note that writable executable shared file mappings are still controlled based on the file write and execute permission checks, not this new check. The attached policy patch excludes wxpage permission from the general_domain_access() macro so that it will not be allowed by default to most domains and adds the wxpage permission selectively to a few domains based on very preliminary experimentation with this new check. You may also find it necessary to uncomment the rule added to base_user_macros.te by the patch to allow user domains this permission, as they will otherwise be unable to load DSOs that require an executable stack (e.g. preliminary experimentation with this check prevented many gnome applications from running at all due to the inability to load a particular DSO). I know that the PAX/selinux integration patch approaches this differently, applying a check based on the executable file type rather than the process domain, but I would favor a domain-based check for its greater generality (ability to handle multiple instances of the same program in different ways) and more direct representation of the actual operation (can this process perform this action?). Admittedly, the domain-based check does impose a cost on policy writers - you have to define separate domains vs. just separate file types in order to selectively allow this permission. But I believe that this cost is justified. Please note that this patch does NOT provide the functionality of PAX, exec-shield, NX support, etc. It merely provides SELinux policy control over the ability to create an executable mapping that can contain data not covered by file permission checks. Constructive comments welcome. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security AgencyFrom: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: [RFC][PATCH] Control ability to have a writable executable mapping Date: Tue, 09 Nov 2004 16:05:10 -0500
Sorry, the last statement isn't accurate; this patch only provides SELinux policy control over the ability to have a mapping that is simultaneously writable and executable. One could still create a rw mapping and then later change its protection to rx. For anonymous mappings, the patch could be trivially modified to apply the check for any PROT_EXEC mapping and thus prevent executable anonymous mappings entirely except when explicitly allowed; that seems reasonable. Private file mappings are more problematic. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: [RFC][PATCH] Control ability to have a writable executable mapping Date: Wed, 10 Nov 2004 10:35:06 -0500
Ok, based on feedback and some sample code from Roland McGrath (but any
bugs are likely mine), here are revised kernel and policy patches with
the following changes:
This brings the check closer to the goal of controlling the ability to make executable a mapping that can contain data not covered by file permission checks. Constructive comments welcome. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security AgencyFrom: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: [RFC][PATCH] Control ability to have a writable executable mapping Date: Wed, 01 Dec 2004 12:02:25 -0500
I've attached the final form of the kernel patch (and a corresponding policy patch) that is being committed to our tree. This patch differs from the previous version in that it splits the single execmem permission check into two separate permission checks: 1) a task->self execmem check for making executable anonymous mappings and for making writable executable private file mappings, and 2) a task->file execmod check for making executable previously written private file mappings (e.g. text relocations). -- Stephen Smalley <sds@epoch.ncsc.mil> National Security AgencyFrom: Joshua Brindle <jbrindle_at_tresys.com> subject: Re: [RFC][PATCH] Control ability to have a writable executable mapping Date: Tue, 09 Nov 2004 18:15:23 -0500
>I know that the PAX/selinux integration patch approaches this That said, I know the current implementation breaks the current domain source, target object type model, and it would be better to make it the same for no better reason than consistancy. On the other hand, you are right, it does impose a higher cost on policy writing. However, it isn't clear that SELinux facilitates this sort of flag setting via permissions well, since SELinux will deny by default all the flags would be off (!) which is less secure.
>Please note that this patch does NOT provide the functionality of PAX,
>Constructive comments welcome. Joshua Brindle -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: [RFC][PATCH] Control ability to have a writable executable mapping Date: Wed, 10 Nov 2004 10:25:02 -0500
Abstractly, you want to control what code can be executed by a given domain. Basing your check on the main executable file type (which may not in fact even be the actual file that required a writable executable mapping, as that can be triggered by loading a DSO) means that you have to perform separate analysis of what domains can execute that file type if you want to know what domains can execute runtime generated code. I'm also not entirely clear that it is necessarily a property of an application under every usage scenario, e.g. if the application dlopen()'s a shared object that requires executable stack, but only does so for a certain mode of operation, you could possibly distinguish that in policy. As many applications use a single executable for multiple purposes, it seems preferable to allow for this.
> out of curiousity, is revocation handled? This doesn't change the status of revocation support in SELinux, i.e. we revalidate upon certain operations, including mmap/mprotect/read/write, but we do not presently revoke existing mappings upon a policy change or file relabel.
> It seems like the whole purpose of this is to enforce a consistancy No, we already apply checking on mmap/mprotect for file-based mappings. The new check is just an attempt to provide policy control over creation of executable mappings that wouldn't be covered by file permission checks, e.g. anonymous mappings or private file mappings that are writable or previously written. Note that the patch didn't fully address these cases; I'll post a new version shortly based on some other feedback.
> Does this fall into the same category as PaX where denying the flag No, failure to grant this permission leads to an inability to perform the mmap/mprotect (for the cases covered by the permission). But note that I had to include a change to general_domain_access() in the policy patch to remove the permission by default, as most domains use that macro and that macro typically gives all but a specific set of excluded permissions for task->self:process. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: [RFC][PATCH] Control ability to have a writable executable mapping Date: Mon, 15 Nov 2004 22:52:00 +1100
Maybe instances of the application running in different domains will be permitted to load different DSOs such that one domain is permitted to load a DSO which wants write-execute access while another domain is not permitted to load such DSOs. It's just a hypothetical, I don't know of an example of this happening. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- 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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |