Security implications of RT and memlock?

[David Henningsson]

Hi,

In a discussion with JACK developer Paul Davis, he says:

"at this point in time, i personally can see absolutely no reason why a 
regular user should not have access to RT scheduling or memlock if the 
kernel and PAM (or equivalent) are normally and appropriately 
configured. give the user the ability to memlock 75% of the system RAM, 
make sure that the RT scheduling parameters reserve 5% of the CPU for 
non-RT tasks. done."

The advantage of doing so is to remove one obstacle for having 
low-latency audio working OOTB, without manual configuration.

However, I'm not a security expert, so I don't know if this has any bad 
security implications. At least at kernel level, we have
/proc/sys/kernel/sched_rt_runtime_us that should keep the system from 
locking up completely in case of misbehaving software.

It would be nice if these privileges could be assigned only to a logged 
in user (like udev-acl access to hw privileges), and it would also be 
nice if there was a similar way to limit memlock (i e, 20% of the memory 
always reserved to non-locked memory, on a global level), but I don't 
know if this is possible.

I thought I'd at least bring it up and see what you'd think about it.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic