On 3/7/2018 11:18 AM, Sargun Dhillon wrote:

On Wed, Mar 7, 2018 at 9:45 AM, Casey Schaufler [off-list ref] wrote:

quoted

On 3/6/2018 11:23 PM, Sargun Dhillon wrote:

quoted

This commit should have no functional change. It changes the security hook
list heads struct into an array. Additionally, it exposes all of the hooks
via an enum. This loses memory layout randomization as the enum is not
randomized.

Please explain why you want to do this. I still dislike it.

Do you dislike it because of the loss of randomization, or some other reason?

I dislike a huge array of untyped function pointers.
I dislike the loss of type checking in security.c

The reason for not just having a second list_heads is that it's
somewhat ugly having to replicate that structure twice -- once for
dynamic hooks, and once for 'static' hooks.

There was discussion about this some time ago. In the case
where you don't allow dynamic hooks, you mark the lists ro_after_init
whereas in the case with them you don't, but use the locking.

Instead, we have one enum that LSMs can use and two arrays of heads
rather than an entire unrolled set of list_heads.

But how is this better? What is the advantage?

If we had a way to randomize this, would it make you comfortable?

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html