FPT_W^X_EXT.1 concerns in v4.3 draft

[mclearn]

In the v4.3 draft, FPT_W^X_EXT.1 has transitioned from objective to mandatory. However, I don't believe FPT_W^X_EXT.1 can be reasonably claimed in many operating systems today and the list of exceptions that would be claimed would make the SFR all but useless.

Protections on mmap() still don't seem to have widespread adoption for W^X. I can successfully allocate memory pages with W&X in recent Linux and Solaris kernels. Custom Linux kernel modifications such as grsecurity would catch these but they are not in the mainline. Thus, mmap() would have to be considered an exception (which is a big exception).

You can adjust the permissions on a heap allocated page (i.e. those from malloc and related). The heap permissions are set by the loader (at least in Linux) to PROT_READ | PROT_WRITE. You can attempt to modify the permissions to include PROT_EXEC using mprotect as long as you do the right thing (eg. ensure page alignment, etc.), and then things like SELinux can catch it. However, as the three test cases ask for the page to be initially allocated with a specific permission set, that seemingly cannot be performed without some slight adjustment to the test AAs regarding initial permission sets.

Alternatively, adjust the SFR to have a selection which can cover system-wide usage vs. targeted usage, such as:

FPT_W^X_EXT.1.1 The OS shall prevent allocation usage of [selection: any memory region, [assignment: specific memory regions]] with both write and execute permissions except for [assignment: list of exceptions].

(It's not clear if the "list of exceptions" could be removed by adding the "specific memory regions" assignment. Probably both assignments are useful.)

The above could at least act as a transition to smooth the way to better adoption of W^X in the future. The TSS and test case AAs would have to be adjusted accordingly.

[kgal]

I agree that this requirement probably needs to be reworked. Your suggestion is definitely an improvement, but those assignments seemingly could render the actually implementation of this requirement pointless. I am wondering if the following is more appropriate.

FPT_W^X_EXT.1.1 The OS shall have a mechanism to restrict a process from executing memory regions that the process can also write to.

[mclearn]

I think your suggested wording is reasonable.

[stevegrubb]

I have to agree that this would be a problem if it were mandatory. mmap is not blocked when PROT_WRITE|PROT_EXEC is given or if a executable page becomes writable. High performance JIT compilers for several languages require this.

About using SELinux to block W^X. Can we really make claims enforced by SELinux without MAC requirements being an Objective Requirement? (I've been hesitant to use SELinux in any claims because it is unevaluated functionality.)

It has been suggested for many years [1] that the way avoid SELinux blocking this is to have 2 mappings to the same memory area: one writable and one executable. By doing this you can circumvent detection and SELinux. It is for this reason I think W^X is aspirational, but can be worked around. (See the example program in the link below.)

Also, what about ptrace modifying executable memory?

1- https://akkadia.org/drepper/selinux-mem.html

[kgal]

Would it make sense to focus only on protecting the stack?

[stevegrubb]

The Linux kernel has no technical control that would prevent an executable stack from being used. It even has a personality for read implies execute for really old programs. This problem is the same as stack smashing protection, the kernel cannot enforce either. But what you can do is treat the executable stack similar to stack smashing protection. The ELF binaries can be scanned to search for section flags that would cause an executable stack. If this were treated like stack smashing, then it could have an assurance activity to list the exceptions. I don't know how other operating systems implement non-executable stacks or protect against it at compile time. But for Linux it's a compile time issue that can be detected with readelf.

[stevegrubb]

Looks like OSPP 4.3 has been released without addressing this issue. Linux has no ability to enforce this requirement. It even has a personality for read implies write to allow very old programs to run. And the requirement can be worked around by opening 2 mmaps to the same memory region, one writable and one executable. That would probably circumvent enforcement on any OS.

[mclearn]

I have raised this with NIAP's TRRT for their take.

[kgal]

I have written up a proposal TD to make this component optional.

[adelton]

Hello @kgal, did you get any response from NIAP about the TD?

[kgal]

I have not heard anything yet, but there's talk of publishing a quick revision to make this PP compatible with MDM agent. I'll send another email to get clarification.

[mclearn]

Hi @kgal. Can you provide an update on this. Note that I had already sent a TRRT on Sept 27 with ID 1347, but have not received any response to it yet. In case you need to refer to it in your internal comms. Thanks.

[adelton]

The https://www.niap-ccevs.org/documents_and_guidance/view_td.cfm?TD=0675 makes FPT_W^X_EXT.1 Optional in OSPP 4.3.