-----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@xxxxxxxxxxx
>
> --
> selinux mailing list
> selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEUEARECAAYFAk0m6dYACgkQMlxVo39jgT9F5gCfWDourvS45UA3wrO1A5rTH8DW
M78Al1db64irh4cibw+R+hWDl4oxJNw=
=YAuO
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
