Feature added by: Martyn Hare (NthDeGeek) Feature #310292, revision 1 Title: TOMOYO YaST Integration openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Martyn Hare (nthdegeek) Partner organization: openSUSE.org Description: Add TOMOYO as an option for security on OpenSuSE's YaST. 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. 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 -- openSUSE Feature: https://features.opensuse.org/310292