Bug 542986 - FutureFeature: Please enable TOMOYO Linux security module
FutureFeature: Please enable TOMOYO Linux security module
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
http://tomoyo.sourceforge.jp/
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-01 07:00 EST by Tetsuo Handa
Modified: 2012-01-24 17:13 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-06 09:43:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tetsuo Handa 2009-12-01 07:00:28 EST
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.
Comment 1 Tetsuo Handa 2010-02-23 23:48:26 EST
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.
Comment 2 Bug Zapper 2010-03-15 09:24:22 EDT
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
Comment 3 Tetsuo Handa 2010-06-21 07:47:45 EDT
No response yet. Is there something I can do?

Regards.
Comment 4 Dave Jones 2010-08-16 15:05:09 EDT
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).
Comment 5 Tetsuo Handa 2012-01-06 07:14:28 EST
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.
Comment 6 Dave Jones 2012-01-06 09:43:46 EST
we do not have the resources to support multiple LSMs.
Comment 7 Tetsuo Handa 2012-01-06 19:39:45 EST
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.
Comment 8 Josh Boyer 2012-01-06 19:52:23 EST
(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.
Comment 9 Jamie Nguyen 2012-01-07 05:28:28 EST
(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.
Comment 10 Toshiharu Harada 2012-01-07 08:39:36 EST
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.
Comment 11 Akemi Yagi 2012-01-24 17:13:17 EST
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.

Note You need to log in before you can comment on or make changes to this bug.