[New: openFATE 310292] TOMOYO YaST Integration
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
Feature changed by: Martyn Hare (NthDeGeek) Feature #310292, revision 2 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.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
Feature changed by: Martyn Hare (NthDeGeek) Feature #310292, revision 6 - Title: TOMOYO YaST Integration + Title: TOMOYO 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
Feature changed by: Martyn Hare (NthDeGeek) Feature #310292, revision 7 Title: TOMOYO 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 + 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. 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
Feature changed by: Martyn Hare (NthDeGeek) Feature #310292, revision 8 Title: TOMOYO 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. 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 + 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. -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Pavol Rusnak (prusnak) Feature #310292, revision 9 Title: TOMOYO 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. 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 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 :-) -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Tetsuo Handa (kumaneko) Feature #310292, revision 10 Title: TOMOYO 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. 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 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. -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Thomas Schmidt (digitaltomm) Feature #310292, revision 11 Title: TOMOYO Integration - openSUSE-11.4: Unconfirmed + 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. 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. -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Thomas Schmidt (digitaltomm) Feature #310292, revision 12 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. 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. -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Clint Burford (clintburford) Feature #310292, revision 13 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. 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. + #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 = :- + ) -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Tetsuo Handa (kumaneko) Feature #310292, revision 14 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. 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 = :- ) -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Tetsuo Handa (kumaneko) Feature #310292, revision 15 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. 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 -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Jeff Mahoney (jeff_mahoney) Feature #310292, revision 17 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... 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 -- openSUSE Feature: https://features.opensuse.org/310292
Feature changed by: Pascal Bleser (pbleser) Feature #310292, revision 19 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... 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. -- openSUSE Feature: https://features.opensuse.org/310292
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... 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
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
participants (1)
-
fate_noreply@suse.de