Mailinglist Archive: opensuse-features (263 mails)

< Previous Next >
[openFATE 310292] TOMOYO Integration
Feature changed by: Jan Engelhardt (jengelh)
Feature #310292, revision 20
Title: TOMOYO Integration

openSUSE Distribution: New
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_bug.cgi?id=668381

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

< Previous Next >
This Thread
References