Under selinux-policy-3.9.7-7.fc14 and previous, udev was able to load kernel modules even when secure_mode_insmod=on Starting with the next policy release, 3.9.7-10.fc14, this fails, resulting in the ethernet device not being configured when the system boots; no denial is logged.
Setting secure_mode_insmod=off and rebooting results in a working system, but allows other restricted domains to load kernel modules -- which is a shame since I also have unconfined_login=off and secure_mode=on. So I added a local module with the following rule in order to get the 3.9.7-7.fc14 behavior with secure_mode_insmod=on. (The seemingly superfluous enclosing "if" is needed to avoid a duplicate rule error).
if (secure_mode_insmod) { modutils_domtrans_insmod_uncond(udev_t) }
My question is: what is the desired behavior for future policy releases? Should secure_mode_insmod=on affect udev as it currently does under 3.9.7-10.fc14 and later? (A literal reading of the description for this boolean implies it should). Or should a new boolean be added (off by default) to allow administrators to have udev load kernel modules even when secure_mode_insmod=on? Or something else?
Apologies if this is actually a non-issue due to lack of understanding on my end (but any education would be welcome in that case!)
-- Mark Montague mark@catseye.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2011 01:51 AM, Mark Montague wrote:
Under selinux-policy-3.9.7-7.fc14 and previous, udev was able to load kernel modules even when secure_mode_insmod=on Starting with the next policy release, 3.9.7-10.fc14, this fails, resulting in the ethernet device not being configured when the system boots; no denial is logged.
I think thats the expected behaviour (the "next" or new)
Setting secure_mode_insmod=off and rebooting results in a working system, but allows other restricted domains to load kernel modules -- which is a shame since I also have unconfined_login=off and secure_mode=on. So I added a local module with the following rule in order to get the 3.9.7-7.fc14 behavior with secure_mode_insmod=on. (The seemingly superfluous enclosing "if" is needed to avoid a duplicate rule error).
if (secure_mode_insmod) { modutils_domtrans_insmod_uncond(udev_t) }
If that works for you, and you want that behaviour then go for it.
But thats in my view not what "upstream" had in mind when it implemented this functionality.
Ofcourse this functionality was implemented before udev even existed so the scenario may have changed a bit, but i personally doubt that this will be upstream able.
My question is: what is the desired behavior for future policy releases? Should secure_mode_insmod=on affect udev as it currently does under 3.9.7-10.fc14 and later? (A literal reading of the description for this boolean implies it should).
- From reading the source policy it is clear to me that udev should be *conditionally* allowed to domain transition to the insmod_t domain
Meaning only if secure_mode_insmod is set to off
Or should a new boolean be added
(off by default) to allow administrators to have udev load kernel modules even when secure_mode_insmod=on? Or something else?
I do not think so no, but i may be wrong because:
1. Times change. 2. There is functionality available to allow a specified domain to *unconditionally* domain transition to insmod. (that may imply that designers of this functionality did foresee (future) issues like these
In my view it probably depends on whether there are viable scenarios to make this work properly without *breaking* secure_mode_insmod.
Apologies if this is actually a non-issue due to lack of understanding on my end (but any education would be welcome in that case!)
I would be interested to hear what others opinions are on this.
-- Mark Montague mark@catseye.org
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org