Feature changed by: Jeff Mahoney (jeff_mahoney) Feature #310292, revision 21 Title: TOMOYO Integration - openSUSE Distribution: New + openSUSE Distribution: Done Priority Requester: Important Package Wishlist: New Priority Requester: Important Requested by: Martyn Hare (nthdegeek) Partner organization: openSUSE.org Description: Add TOMOYO as an option for security on OpenSuSE. It offers more features than AppArmor and with the correct YaST integration it can be made to work in the same "targeted" way as AppArmor does by default, offering powerful features to less experienced users without causing system-wide changes. It is pathname based just like AppArmor but also provides domain separation based upon execution history. Just like AA it offers an extensive learning mode which is simple to use and policies are human readable. Relations: - Bugzilla: (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=668381) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/show... Use Case: Derek wants a system where only applications with a created policy may execute according to principle of least authority. With AppArmor he can only lock down specific applications, and SELinux uses a complex labelling system (and doesn't offer POLA). With TOMOYO he can apply learning mode to analyse normal behaviour system-wide, then tweak human- readable policy to run as enforced. Suzie runs a server where remote access is limited but local access is intended to be unimpeded. TOMOYO would differentiate between a local login shell and remote login shell by the execution history, resulting in a restricted shell remotely but not locally without the need to create hard links or use alternative user accounts. John wants to limit who can directly connect to his P2P client, but needs to keep the port randomised to avoid conflicts with others on his residential network, but has other applications listening on ports too - TOMOYO allows him to restrict what direct inbound connections are accepted by the P2P application. Business case (Partner benefit): openSUSE.org: Benefits to OpenSuSE: * The ability for an end-user to lock down the whole system if he/she chooses in addition to the ability to lock down individual applications * Conditional checking of permissions based on whether file is owned and/or what user is accessing files * Control over listening, sending and receiving over the network per- process on a per-port and/or per-IP basis * Enhanced control over the use of capabilities on a global and/or per- app basis * Security which can be LSM or non-LSM (1.x has out-of-tree patches, 2. x which is in-tree uses LSM) * If using 1.x the end-user may run TOMOYO in parallel with either AppArmor or SELinux (this may allow SELinux policies to get additional testing!) * Hard link security bypassing resolved through control over the ability to create and/or use hard links Discussion: #1: Martyn Hare (nthdegeek) (2010-08-05 18:14:01) Additional Note: Mandriva ditched AppArmor the moment Novell fired the AppArmor team. Only Ubuntu really puts time into AA. It's dead when compared to TOMOYO and it's time to add new options to OpenSuSE. #2: Pavol Rusnak (prusnak) (2010-08-05 19:25:27) AppArmor was just merged into Kernel so saying it is dead is ... not right :-) #3: Tetsuo Handa (kumaneko) (2010-09-18 06:51:14) Additional information: TOMOYO 1.x is not using LSM but can be built as a LKM (loadable kernel module) provided that LSM-like hook is incorporated into the kenrel. http://sourceforge.jp/projects/tomoyo/svn/view/trunk/1.7.x/ccs-patch/include/linux/ccsecurity.h?root=tomoyo&revision=HEAD&content-type=text% 2Fplain http://sourceforge.jp/projects/tomoyo/svn/view/trunk/1.7.x/ccs-patch/patches/ccs-patch-2.6.36.diff?root=tomoyo&revision=HEAD&content-type=text% 2Fplain As with LSM modules, TOMOYO 1.x does nothing for those who don't use TOMOYO 1.x . TOMOYO 1.x is best for using with SELinux's targeted policy or AppArmor, for users can easily develop TOMOYO's policy where it is difficult to distribute readymade policy (e.g. SSH shell session, homemade CGI programs). TOMOYO 2.x is using LSM, and is subset of TOMOYO 1.x (because TOMOYO 2. x can use only LSM hooks accepted by upstream subsystem maintainers). Currently enabled by Ubuntu 9.10, Debian Squeeze, Mandriva 2010.0 . Mandriva developed GUI for TOMOYO 2.2 . Maybe you can use it. To Martyn Hare: I'm distributing kernel packages with TOMOYO 1.x enabled since openSUSE 10.1 . If you want to use TOMOYO 1.x on openSUSE 11.4, I can make it for you. #5: Tetsuo Handa (kumaneko) (2011-01-19 13:46:20) (reply to #3) Well, it seems that it is too late for enabling TOMOYO 2.3 in openSUSE 11.4 kernels. Current non-LSM version of TOMOYO is TOMOYO 1.8. ( http://tomoyo.sourceforge.jp/1.8/ ) If you can accept use of TOMOYO kernels without SUSE's support but you can't accept replacing kernel package (i.e. recompiling kernel from source), you can use AKARI instead. ( http://akari.sourceforge.jp/ ) AKARI is a LKM(loadable kernel module)&LSM(linux security module) version of TOMOYO 1.8 that provides as much functionality as possible, without asking users to replace (or recompile) kernel package. http://akari.sourceforge.jp/comparison.html Like TOMOYO 1.x, you can run AKARI in parallel with other LSM modules. F.Y.R. https://wiki.archlinux.org/index.php/TOMOYO_Linux #4: Clint Burford (clintburford) (2010-12-22 23:50:33) Hello Everyone! I recently configured SELinux in openSUSE 11.2, although I wanted TOMOYO. I tried for a while to configure TOMOYO on openSUSE 11.2 but had issues with runlevel 5. Futhermore, I hope more people vote for TOMOYO as a nice added security feature. Why not have " TOMOYO Linux : Behavior oriented system analyzer and protector." openSUSE + TOMOYO = :- ) #6: Tetsuo Handa (kumaneko) (2011-01-19 13:51:49) (reply to #4) What issues did you get with using TOMOYO in runlevel 5? Feel free to report TOMOYO issues to tomoyo-users-en ML. http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en #7: Pascal Bleser (pbleser) (2011-06-05 10:29:50) Seems like the discussion has stalled at this point. Most votes here are pro, even though there aren't that many of them. The con votes have no comments, hence they're moot (if you're against it, please explain *why* or it's useless). The bugzilla entry depends on this FATE item for enabling tomoyo in 12.1. We definitely need to clarify the situation right now or it will be simply forgotten in 12.1 again. #8: Jan Engelhardt (jengelh) (2011-06-06 12:50:32) (reply to #7) Con: TOMOYO is in the kernel already, so it is practically already shipped. (Unless there is some userspace tools required.) #9: Jan Engelhardt (jengelh) (2011-06-06 12:55:17) (reply to #8) Though it's disabled in the .config. So this needs talking to the SUSE kernel team instead (preferably bugzilla I suspect). -- openSUSE Feature: https://features.opensuse.org/310292