Research Menu

.
Skip Search Box

SELinux Mailing List

[RFC][PATCH] Control ability to have a writable executable mapping

From: Stephen Smalley <sds_at_epoch.ncsc.mil>
Date: Tue, 09 Nov 2004 13:40:03 -0500


At present, SELinux only applies permission checks to mmap/mprotect for file mappings, and it only checks write permission to the file if the mapping is shared, as the caller does not truly require write permission to the file for a private copy-on-write mapping nor would we want to grant write permission to all processes that perform such mappings. Consequently, SELinux does not currently provide policy control over the ability of a process to have a writable executable anonymous mapping or a writable executable private file mapping.

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 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.

Received on Tue 9 Nov 2004 - 13:44:02 EST
 

Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009

 
bottom

National Security Agency / Central Security Service