On Saturday, October 24, 2020 2:12 PM, Salvatore Mesoraca [off-list ref] wrote:

On Sat, 24 Oct 2020 at 12:34, Topi Miettinen toiwoton@gmail.com wrote:

quoted

On 23.10.2020 20.52, Salvatore Mesoraca wrote:

quoted

Hi,
On Thu, 22 Oct 2020 at 23:24, Topi Miettinen toiwoton@gmail.com wrote:

quoted

SARA looks interesting. What is missing is a prctl() to enable all W^X
protections irrevocably for the current process, then systemd could
enable it for services with MemoryDenyWriteExecute=yes.

SARA actually has a procattr[0] interface to do just that.
There is also a library[1] to help using it.

That means that /proc has to be available and writable at that point, so
setting up procattrs has to be done before mount namespaces are set up.
In general, it would be nice for sandboxing facilities in kernel if
there would be a way to start enforcing restrictions only at next
execve(), like setexeccon() for SELinux and aa_change_onexec() for
AppArmor. Otherwise the exact order of setting up various sandboxing
options can be very tricky to arrange correctly, since each option may
have a subtle effect to the sandboxing features enabled later. In case
of SARA, the operations done between shuffling the mount namespace and
before execve() shouldn't be affected so it isn't important. Even if it
did (a new sandboxing feature in the future would need trampolines or
JIT code generation), maybe the procattr file could be opened early but
it could be written closer to execve().

A new "apply on exec" procattr file seems reasonable and relatively easy to add.
As Kees pointed out, the main obstacle here is the fact that SARA is
not upstream :(

Salvatore

Is there a chance we will see new SARA iteration soon on lkml? :)

Jordan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel