On Thu, 2018-05-10 at 23:26 +0000, Luis R. Rodriguez wrote:

On Wed, May 09, 2018 at 10:00:58PM -0400, Mimi Zohar wrote:

quoted

On Wed, 2018-05-09 at 23:48 +0000, Luis R. Rodriguez wrote:

quoted

On Wed, May 09, 2018 at 06:06:57PM -0400, Mimi Zohar wrote:

quoted

quoted

quoted

quoted

Yes, writing regdb as a micro/mini LSM sounds reasonable. ?The LSM
would differentiate between other firmware and the regulatory.db based
on the firmware's pathname.

If that is the only way then it would be silly to do the mini LSM as all
calls would have to have the check. A special LSM hook for just the
regulatory db also doesn't make much sense.

All calls to request_firmware() are already going through this LSM
hook. ?I should have said, it would be based on both READING_FIRMWARE
and the firmware's pathname.

Yes, but it would still be a strcmp() computation added for all
READING_FIRMWARE. In that sense, the current arrangement is only open coding the
signature verification for the regulatory.db file.  One way to avoid this would
be to add an LSM specific to the regulatory db

Casey already commented on this suggestion.

Sorry but I must have missed this, can you send me the email or URL where he did that?
I never got a copy of that email I think.

My mistake. ?I've posted similar patches for kexec_load and for the
firmware sysfs fallback, both call security_kernel_read_file().
Casey's comment was in regards to kexec_load[1], not for the sysfs
fallback mode. ?Here's the link to the most recent version of the
kexec_load patches.[2]

[1]?http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006690.html
[2] http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006854.html

Mimi

--
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