mac: allow policies to restrict vnode-backed mmap max_prot#2191
Open
mcoelho80 wants to merge 1 commit into
Open
mac: allow policies to restrict vnode-backed mmap max_prot#2191mcoelho80 wants to merge 1 commit into
mcoelho80 wants to merge 1 commit into
Conversation
For vnode-backed mappings, MAC policies currently get a chance to check the protection requested by mmap(2). However, a mapping created without PROT_EXEC may still retain VM_PROT_EXECUTE in max_prot and later be upgraded with mprotect(PROT_EXEC): fd = open(path, O_RDONLY); addr = mmap(NULL, len, PROT_READ, MAP_PRIVATE, fd, 0); mprotect(addr, len, PROT_READ | PROT_EXEC); At mprotect(2) time, the VM layer no longer has the same vnode context that was available during mmap(2). As a result, a MAC policy that intends to prevent executable mappings from a given vnode may be bypassed by first creating a non-executable mapping and then upgrading it later. Without this enforcement point, the MAC framework does not provide policy authors with a complete mechanism to enforce vnode-based executable mapping restrictions. This can make a policy look correct while leaving a bypass path open. Let MAC policies reduce max_prot during the vnode-backed mmap path, while the vnode is still available. This allows a policy to remove VM_PROT_EXECUTE from max_prot, causing a later mprotect(PROT_EXEC) to fail naturally in the VM layer. If the reduced max_prot no longer contains the protection requested for the initial mmap, fail the mmap with EACCES. This does not change behavior for policies that do not implement the downgrade hook. Signed-off-by: Marcelo Coelho <mcoelho80@hotmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For vnode-backed mappings, MAC policies currently get a chance to check the protection requested by mmap(2). However, a mapping created without PROT_EXEC may still retain VM_PROT_EXECUTE in max_prot and later be upgraded with mprotect(PROT_EXEC):
At mprotect(2) time, the VM layer no longer has the same vnode context that was available during mmap(2). As a result, a MAC policy that intends to prevent executable mappings from a given vnode may be bypassed by first creating a non-executable mapping and then upgrading it later.
Without this enforcement point, the MAC framework does not provide policy authors with a complete mechanism to enforce vnode-based executable mapping restrictions. This can make a policy look correct while leaving a bypass path open.
Let MAC policies reduce max_prot during the vnode-backed mmap path, while the vnode is still available. This allows a policy to remove VM_PROT_EXECUTE from max_prot, causing a later mprotect(PROT_EXEC) to fail naturally in the VM layer.
If the reduced max_prot no longer contains the protection requested for the initial mmap, fail the mmap with EACCES.
This does not change behavior for policies that do not implement the downgrade hook.