Feature changed by: Frederic Crozat (fcrozat) Feature #323500, revision 3 Title: Kernel: Add support for new AppArmor rule types - openSUSE Distribution: Unconfirmed + openSUSE Distribution: New Priority Requester: Important Requested by: Christian Boltz (cboltz) + Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Matthias Eckermann (mge1512) Feature #323500, revision 7 Title: Kernel: Add support for new AppArmor rule types - openSUSE Distribution: New + openSUSE Distribution: Evaluation by project manager Priority Requester: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Goldwyn Rodrigues (goldwynr) Feature #323500, revision 10 Title: Kernel: Add support for new AppArmor rule types openSUSE Distribution: Evaluation by engineering manager Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. + Discussion: + #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) + I have added the current patches in upstream vanilla tree. Thanks to + John's tree, this was simpler than I thought. This series covers + namespace labeling and stacking. However, as the first comment + (addition) says, the rest would not make it upstream until 4.14. What + is remaining is mount, signals, dbus, keys. etc. We do carry some + legacy network patches though. + I will keep a close watch to see as and when new patches appear. -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Jeff Mahoney (jeff_mahoney) Feature #323500, revision 14 Title: Kernel: Add support for new AppArmor rule types - openSUSE Distribution: Evaluation by engineering manager + openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. + #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) + OpenSUSE will be updated once all of the commits have landed upstream; + Likely 4.14. Then we'll update the userspace. -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Libor Pechacek (LPechacek) Feature #323500, revision 17 - Title: Kernel: Add support for new AppArmor rule types + Title: [BETA 1] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Libor Pechacek (LPechacek) Feature #323500, revision 19 Title: [BETA 1] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. + #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) + +1 No backports to TW. + @Christian, use KOTD with Tumbleweed for your testing. -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Jeff Mahoney (jeff_mahoney) Feature #323500, revision 22 Title: [BETA 1] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Documentation Impact: Security Guide Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) +1 No backports to TW. @Christian, use KOTD with Tumbleweed for your testing. + #8: Jeff Mahoney (jeff_mahoney) (2017-09-28 09:40:30) (reply to #7) + The kernel master branch is now at 4.14-rc2, which included the net + mediation patches finally landing upstream! -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Mel Gorman (mgorman) Feature #323500, revision 24 Title: [BETA 5] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Documentation Impact: Security Guide Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) +1 No backports to TW. @Christian, use KOTD with Tumbleweed for your testing. #8: Jeff Mahoney (jeff_mahoney) (2017-09-28 09:40:30) (reply to #7) The kernel master branch is now at 4.14-rc2, which included the net mediation patches finally landing upstream! + #9: Mel Gorman (mgorman) (2018-02-23 10:52:52) (reply to #8) + Note that this FATE is not without consequences. It pulled in support + for mediating signals but the system overhead for signals is massive + even if apparmor is not installed and no profiles are loaded. It's + visible in any signal microbenchmark. It's also visible in benchmarks + like dbench and tbench which are very signal-intensive. + This FATE is far from free even when the apparmor package is not + installed. -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Goldwyn Rodrigues (goldwynr) Feature #323500, revision 26 Title: [BETA 5] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Documentation Impact: Security Guide Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) +1 No backports to TW. @Christian, use KOTD with Tumbleweed for your testing. #8: Jeff Mahoney (jeff_mahoney) (2017-09-28 09:40:30) (reply to #7) The kernel master branch is now at 4.14-rc2, which included the net mediation patches finally landing upstream! #9: Mel Gorman (mgorman) (2018-02-23 10:52:52) (reply to #8) Note that this FATE is not without consequences. It pulled in support for mediating signals but the system overhead for signals is massive even if apparmor is not installed and no profiles are loaded. It's visible in any signal microbenchmark. It's also visible in benchmarks like dbench and tbench which are very signal-intensive. This FATE is far from free even when the apparmor package is not installed. #10: Goldwyn Rodrigues (goldwynr) (2018-02-23 13:10:11) (reply to #9) Thanks for testing and letting me know. I assume you are disabling apparmor needs to load in the beginning for security purposes to cover as many programs/profiles as possible. Unfortunately, security has its costs. I believe you disabled apparmor in kernel boot parameters using apparmor=0. I could work on disabling part of the feature as sysfs switch as MgE suggested for RC2 if it is really required. From a practical point of view, I am not sure how many programs are affected by this. I let Jeff or management decide this. + Release Notes: + Challenge: + Processes need to be safeguarded from not just the files or network + they are capable to sockets but with other aspects as well. For example + genuine processes can be arbitrarily terminated by signals from other + processes. Compromised processes can try to exhaust resources by + increasing their rlimits. + Solution: + Apparmor includes new features to further safeguard and restrict your + processes. These features include: * mount * rlimit * ptrace * signal -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Christian Boltz (cboltz) Feature #323500, revision 28 Title: [BETA 5] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Documentation Impact: Security Guide Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) +1 No backports to TW. @Christian, use KOTD with Tumbleweed for your testing. #8: Jeff Mahoney (jeff_mahoney) (2017-09-28 09:40:30) (reply to #7) The kernel master branch is now at 4.14-rc2, which included the net mediation patches finally landing upstream! #9: Mel Gorman (mgorman) (2018-02-23 10:52:52) (reply to #8) Note that this FATE is not without consequences. It pulled in support for mediating signals but the system overhead for signals is massive even if apparmor is not installed and no profiles are loaded. It's visible in any signal microbenchmark. It's also visible in benchmarks like dbench and tbench which are very signal-intensive. This FATE is far from free even when the apparmor package is not installed. #10: Goldwyn Rodrigues (goldwynr) (2018-02-23 13:10:11) (reply to #9) Thanks for testing and letting me know. I assume you are disabling apparmor needs to load in the beginning for security purposes to cover as many programs/profiles as possible. Unfortunately, security has its costs. I believe you disabled apparmor in kernel boot parameters using apparmor=0. I could work on disabling part of the feature as sysfs switch as MgE suggested for RC2 if it is really required. From a practical point of view, I am not sure how many programs are affected by this. I let Jeff or management decide this. #11: Libor Pechacek (lpechacek) (2018-04-17 06:54:58Z) Obviously done in SLE 15. + #12: Christian Boltz (cboltz) (2018-04-17 16:53:34) (reply to #11) + Well, more or less - upstreaming was delayed, so not all rule types are + supported in the upstream kernel yet. Support for dbus and unix rules + is still missing. network rules are also not in the upstream kernel + yet, but [open]SUSE carries this patch since years. + Also note that I removed "rlimit" from the release notes sniplet - + rlimit rules are supported since years, so there's nothing new about + them ;-) + OTOH, pivot_root was upstreamed in 4.14, therefore I added it to the + release notes sniplet. Release Notes: Challenge: Processes need to be safeguarded from not just the files or network they are capable to sockets but with other aspects as well. For example genuine processes can be arbitrarily terminated by signals from other - processes. Compromised processes can try to exhaust resources by - increasing their rlimits. + processes. Solution: Apparmor includes new features to further safeguard and restrict your - processes. These features include: * mount * rlimit * ptrace * signal + processes. These features include: * mount * pivot_root * ptrace * + signal -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Sven Seeberg (sven15) Feature #323500, revision 31 Title: [BETA 5] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Documentation Impact: Security Guide Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) +1 No backports to TW. @Christian, use KOTD with Tumbleweed for your testing. #8: Jeff Mahoney (jeff_mahoney) (2017-09-28 09:40:30) (reply to #7) The kernel master branch is now at 4.14-rc2, which included the net mediation patches finally landing upstream! #9: Mel Gorman (mgorman) (2018-02-23 10:52:52) (reply to #8) Note that this FATE is not without consequences. It pulled in support for mediating signals but the system overhead for signals is massive even if apparmor is not installed and no profiles are loaded. It's visible in any signal microbenchmark. It's also visible in benchmarks like dbench and tbench which are very signal-intensive. This FATE is far from free even when the apparmor package is not installed. #10: Goldwyn Rodrigues (goldwynr) (2018-02-23 13:10:11) (reply to #9) Thanks for testing and letting me know. I assume you are disabling apparmor needs to load in the beginning for security purposes to cover as many programs/profiles as possible. Unfortunately, security has its costs. I believe you disabled apparmor in kernel boot parameters using apparmor=0. I could work on disabling part of the feature as sysfs switch as MgE suggested for RC2 if it is really required. From a practical point of view, I am not sure how many programs are affected by this. I let Jeff or management decide this. #11: Libor Pechacek (lpechacek) (2018-04-17 06:54:58Z) Obviously done in SLE 15. #12: Christian Boltz (cboltz) (2018-04-17 16:53:34) (reply to #11) Well, more or less - upstreaming was delayed, so not all rule types are supported in the upstream kernel yet. Support for dbus and unix rules is still missing. network rules are also not in the upstream kernel yet, but [open]SUSE carries this patch since years. Also note that I removed "rlimit" from the release notes sniplet - rlimit rules are supported since years, so there's nothing new about them ;-) OTOH, pivot_root was upstreamed in 4.14, therefore I added it to the release notes sniplet. + #13: Sven Seeberg (sven15) (2018-04-27 17:47:20) + The shipped man page also includes unix and dbus rules. Is that a + mistake or are these features also included in SLE/Leap 15? Release Notes: New AppArmor Features to Restrict Processes Challenge: To properly protect processes, they must be safeguarded from not only from files and network connections, but also from other process. For example, processes can be arbitrarily terminated by signals from other processes. Solution: The version of AppArmor shipped with SLE 15 includes new features to further safeguard and restrict your processes. These features include: * mount * pivot_root * ptrace * signal -- openSUSE Feature: https://features.opensuse.org/323500

Feature changed by: Stefan Knorr (stfnknorr) Feature #323500, revision 35 Title: [BETA 5] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Documentation Editor: Sven Seeberg (sven15) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Documentation Impact: Security Guide Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) +1 No backports to TW. @Christian, use KOTD with Tumbleweed for your testing. #8: Jeff Mahoney (jeff_mahoney) (2017-09-28 09:40:30) (reply to #7) The kernel master branch is now at 4.14-rc2, which included the net mediation patches finally landing upstream! #9: Mel Gorman (mgorman) (2018-02-23 10:52:52) (reply to #8) Note that this FATE is not without consequences. It pulled in support for mediating signals but the system overhead for signals is massive even if apparmor is not installed and no profiles are loaded. It's visible in any signal microbenchmark. It's also visible in benchmarks like dbench and tbench which are very signal-intensive. This FATE is far from free even when the apparmor package is not installed. #10: Goldwyn Rodrigues (goldwynr) (2018-02-23 13:10:11) (reply to #9) Thanks for testing and letting me know. I assume you are disabling apparmor needs to load in the beginning for security purposes to cover as many programs/profiles as possible. Unfortunately, security has its costs. I believe you disabled apparmor in kernel boot parameters using apparmor=0. I could work on disabling part of the feature as sysfs switch as MgE suggested for RC2 if it is really required. From a practical point of view, I am not sure how many programs are affected by this. I let Jeff or management decide this. #11: Libor Pechacek (lpechacek) (2018-04-17 06:54:58Z) Obviously done in SLE 15. #12: Christian Boltz (cboltz) (2018-04-17 16:53:34) (reply to #11) Well, more or less - upstreaming was delayed, so not all rule types are supported in the upstream kernel yet. Support for dbus and unix rules is still missing. network rules are also not in the upstream kernel yet, but [open]SUSE carries this patch since years. Also note that I removed "rlimit" from the release notes sniplet - rlimit rules are supported since years, so there's nothing new about them ;-) OTOH, pivot_root was upstreamed in 4.14, therefore I added it to the release notes sniplet. #13: Sven Seeberg (sven15) (2018-04-27 17:47:20) The shipped man page also includes unix and dbus rules. Is that a mistake or are these features also included in SLE/Leap 15? #14: Christian Boltz (cboltz) (2018-04-27 18:24:28) (reply to #13) Yes and no ;-) unix and dbus rules are supported in userspace (apparmor_parser, aa-logprof etc.) so that they can handle profiles that contain these rules. AFAIK dbus userspace also has AppArmor support already. However, kernel 4.14 doesn't support unix and dbus rules yet, which means that they get ignored in practise. ("Ignored" means that all unix and dbus actions are allowed.) Release Notes: New AppArmor Features to Restrict Processes Challenge: - To properly protect processes, they must be safeguarded from not only - from files and network connections, but also from other process. For + To properly protect processes, they must be safeguarded not only from + files and network connections, but also from other process. For example, processes can be arbitrarily terminated by signals from other processes. Solution: The version of AppArmor shipped with SLE 15 includes new features to further safeguard and restrict your processes. These features include: * mount * pivot_root * ptrace * signal -- openSUSE Feature: https://features.opensuse.org/323500