Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Smack and TOMOYO

Posted Apr 22, 2010 8:30 UTC (Thu) by rahulsundaram (subscriber, #21946)
In reply to: Smack and TOMOYO by haradats
Parent article: RHEL 6 beta version available

Red Hat's service agreement boils down "if we ship it, we support it". Enabling some configuration options implies support. Red Hat had to drop "kernel-unsupported" package in newer releases of EL precisely because customers demand support for everything that is included. Simply enabling all the options available is not a strategy that would work especially when these have security implications.

(Log in to post comments)

Smack and TOMOYO

Posted Apr 22, 2010 11:47 UTC (Thu) by lkundrak (subscriber, #43452) [Link]

Exactly.

There are third party repositories with software for RHEL that's not supported by Red Hat. Most notably, EPEL, which ships loads of software from Fedora.

Smack and tomoyo are kernel modules, which are not permitted in Fedora. There's another community-maintained repository, RPM Fusion, which would allow it though. If anyone needs tomoyo or smack for RHEL, he's free to add it to RPM Fusion.

The community around Fedora and RPM Fusion is quite supportive, if a packaging experience were a problem.

Smack and TOMOYO

Posted Apr 23, 2010 2:22 UTC (Fri) by haradats (guest, #44782) [Link]

Considering the people who develop/support SELinux and its history, I think it may be safe to say SELinux is the finest and most trustable MAC implementation in the world. However, I personally believe keeping alternatives is good for Linux users and that is the reason LSM exists. RPM Fusion sounds like a good starting point. Thanks a lot for your suggestions.

Smack and TOMOYO

Posted Apr 23, 2010 2:05 UTC (Fri) by haradats (guest, #44782) [Link]

Thank you very much for your informative comment. Now the reason EL disabled Smack and TOMOYO is clear to me and I understood why RH did so. I came to realize that if one wants his work (software) to be used globally, making it in-tree is not the goal but an important first step. Making software in-tree is technical, but affecting distributors decision should involve non-technical issues, I guess.