Home_greyopenFATE - openSUSE feature tracking > #310292
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

TOMOYO Integration

Feature state

Package Wishlist
openSUSE Distribution


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.

User benefit:

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


  • Bugzilla: (https://bugzilla.novell.com/show_bug.cgi?id=668381)


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.


icons/user_comment.png M. H. wrote: (8 years ago)

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.

icons/user_comment.png P. R. wrote: (8 years ago)

AppArmor was just merged into Kernel so saying it is dead is ... not right :-)

icons/user_comment.png T. H. wrote: (8 years ago)
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.
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.
icons/user_comment.png T. H. wrote: (7 years ago)

Well, it seems that it is too late for enabling TOMOYO 2.3 in openSUSE 11.4
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.
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

icons/user_comment.png C. B. wrote: (7 years ago)

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 = :-)

icons/user_comment.png T. H. wrote: (7 years ago)

What issues did you get with using TOMOYO in runlevel 5?
Feel free to report TOMOYO issues to tomoyo-users-en ML.


icons/user_comment.png P. B. wrote: (7 years ago)

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.

icons/user_comment.png J. E. wrote: (7 years ago)

Con: TOMOYO is in the kernel already, so it is practically already shipped. (Unless there is some userspace tools required.)

icons/user_comment.png J. E. wrote: (7 years ago)

Though it's disabled in the .config. So this needs talking to the SUSE kernel team instead (preferably bugzilla I suspect).

Last change: 7 years ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint