Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

On November 8, 2016 4:56:54 PM PST, Kees Cook [off-list ref] wrote:

On Tue, Nov 8, 2016 at 4:47 PM, Josh Triplett [off-list ref]
wrote:

quoted

On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote:

quoted

On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett

[off-list ref] wrote:

quoted

quoted

quoted

Some embedded systems can do without the prctl syscall, saving

some

quoted

quoted

quoted

space.

This also avoids regular increases in tinyconfig size as people

add more

quoted

quoted

quoted

non-optional functionality to prctl (observed via the 0-day kernel
infrastructure).

bloat-o-meter results:

add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-2143 (-2143)
function                                     old     new   delta
offsets                                       23      12     -11
prctl_set_auxv                                97       -     -97
sys_prctl                                    794       -    -794
prctl_set_mm                                1241       -   -1241
Total: Before=1902583, After=1900440, chg -0.11%

Signed-off-by: Josh Triplett <redacted>

I'm absolutely a fan of doing this, but I wonder how this interacts
with the LSMs that define prctl hooks, etc. I wouldn't expect a

system

quoted

quoted

that didn't want prctl to want an LSM, but maybe the LSMs all need

to

quoted

quoted

depend on CONFIG_PRCTL now?

I did think about that (as well as SECCOMP), but I did confirm that

the

quoted

kernel builds fine with allyesconfig minus CONFIG_PRCTL.  An LSM that
wants to restrict access to some prctls should be fine with no

process

quoted

having any access to prctl. :)  Beyond that, anything wanting
configuration via LSM (such as SECCOMP) still exists and functions,

even

quoted

if you can't access it from outside the kernel.

Okay, testing that is good, thanks.

Seccomp can use the seccomp() syscall, so missing prctl isn't a big
deal there.

Things like Yama, though, are almost useless in the !PRCTL case. I
think a "depends on PRCTL" should be added at least to Yama. All the
other LSMs are configured in other ways, and they'll just have some
dead code around their prctl hooks; no big deal.

OK, I'll add that dependency to Yama in v2.

This does also beg the question about how to configure some process
behaviors by default if PRCTL is disabled, but if people want those
things, they can write patches, I would think. :)

Agreed.