Description of problem: TOMOYO Linux, which was merged into Linux 2.6.30, is not enabled in Fedora kernels. Version-Release number of selected component (if applicable): Fedora 11 and later. Expected results: Kernels built with CONFIG_SECURITY_TOMOYO=y . Additional info: It is a LSM module. Thus, there is no side effect except the kernel's size.
I posted as "FutureFeature" in accordance with https://fedoraproject.org/wiki/BugZappers/HouseKeeping . Did I post in a wrong place? If there is a better place to post, please let me know. Regards.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
No response yet. Is there something I can do? Regards.
we can't realistically support multiple security models. If we enable it and people start using it, developers would suddenly have two LSMs to care about (and we have a hard enough time getting them to care about one in some cases).
Re-opening this topic because a lot of progress has been made since then. (1) Linux 3.2 has been released and TOMOYO can now provide sufficient functionality. (2) TOMOYO 2.x is already enabled in Ubuntu, Debian, OpenSUSE, ArchLinux, Mandriva, CentOS+ kernels. They enable multiple LSM modules. (3) You don't need to develop and distribute TOMOYO's policy configuration because end users can develop it by their own hands. I wish you'd reconsider.
we do not have the resources to support multiple LSMs.
Excuse me, but I want to know the difference between "enable" and "support". Many distributions enable multiple LSMs (i.e. set CONFIG_SECURITY_*=y) and support one LSM (e.g. develop and distribute policy configuration). For example, they enable SELinux/SMACK/TOMOYO/AppArmor in their kernel configuration and take care of only AppArmor's policy configuration. Likewise, I think you can enable SELinux/SMACK/TOMOYO/AppArmor in your kernel configuration and take care of only SELinux's policy configuration. Why do you consider that you cannot enable multiple LSMs? I'm not asking you to develop and distribute policy configuration for SMACK/TOMOYO/AppArmor.
(In reply to comment #7) > Excuse me, but I want to know the difference between "enable" and "support". > Many distributions enable multiple LSMs (i.e. set CONFIG_SECURITY_*=y) and > support one LSM (e.g. develop and distribute policy configuration). > > For example, they enable SELinux/SMACK/TOMOYO/AppArmor in their kernel > configuration and take care of only AppArmor's policy configuration. > Likewise, I think you can enable SELinux/SMACK/TOMOYO/AppArmor in your kernel > configuration and take care of only SELinux's policy configuration. > > Why do you consider that you cannot enable multiple LSMs? I'm not asking you to > develop and distribute policy configuration for SMACK/TOMOYO/AppArmor. Simply put, we do not have the time to deal with any potential kernel bug reports that would come from enabling TOMOYO. It would be a disservice to our users to enable something we have no intention of attempting to fix when it is broken. Even if it was 100% perfect code and caused no bug reports for the kernel, it is still bloat and while it might not seem like it we are actually trying to cut down on the size of our installed kernels. Further, while Fedora might not be creating official distribution TOMOYO policies, people will create their own. That can cause any number of issues in the application stacks, where bug reports will get filed against the applications and then people will eventually say "oh, and I have TOMOYO configured". That causes additional work for the package maintainers, and SELinux already takes enough of their time when new packages are added or a policy is incorrect. Unless there is a concerted effort within the distribution to use TOMOYO, I do not see us enabling this in the kernel.
(In reply to comment #8) > Simply put, we do not have the time to deal with any potential kernel bug > reports that would come from enabling TOMOYO. It would be a disservice to our > users to enable something we have no intention of attempting to fix when it is > broken. Enabling many kernel features invariably leads to more bug reports. Sometimes, these are for niche areas of the kernel that can only be fixed upstream. However, even niche features are enabled because they are useful. Similarly, TOMOYO can only really be debugged upstream, but is enabled in several other distributions because it is useful and used by many people. In my very humble opinion, it would be a disservice to users for an optional kernel feature to be left unavailable. Distributions often enable as many hardware drivers as possible. Many will have obscure bugs, with inadequate bug reports that keep the problem unsolvable for a long time. Some become completely broken, and can only be fixed upstream. However, they remain enabled because they are useful. They remain enabled because it's often better to have it available and sometimes broken, than not having it available at all. > Even if it was 100% perfect code and caused no bug reports for the > kernel, it is still bloat and while it might not seem like it we are actually > trying to cut down on the size of our installed kernels. Bloat for one person is a critical feature for another person (and vice versa). That's why desktop distributions do not usually omit useful features for the sake of small kernel size (or omit packages for the sake of repository size). On the contrary, those distributions strive to provide many choices for their users. > That can cause any number of issues in > the application stacks, where bug reports will get filed against the > applications and then people will eventually say "oh, and I have TOMOYO > configured". That causes additional work for the package maintainers Most bug reports are inadequate, and waste developer time. But perhaps that is too pessimistic a view of users' bug reporting ability. It would be a shame to see TOMOYO still being unavailable in Fedora, despite being available in *all* other popular distributions.
Admiring the achievements and advantages of SELinux, it cannot handle pathnames and sometimes more than I need. It would be nice if we could choose the tool (module) that best matches. As Dave wrote, more modules means more resources, unfortunately. But I don't want the support team to give up to support other modules. Each module survived in the mainline has the benefits and users.
I also believe that enabling TOMOYO is beneficial for Fedora users -- and eventually for the entire RH ecosystems. In a long run, providing more choices should help propagate use of Fedora in a wider community.