1. 15 Oct, 2021 1 commit
  2. 11 Jul, 2019 2 commits
  3. 02 Apr, 2019 1 commit
    • intrigeri's avatar
      Refresh patch (refs: #16414) · 242f0e43
      intrigeri authored
      apparmor 2.13.2-10 updated abstractions/base in a way that conflicts
      with the tweaks we do there to support AppArmor aliases.
      242f0e43
  4. 05 Jan, 2019 2 commits
  5. 05 Nov, 2018 1 commit
  6. 29 Aug, 2018 1 commit
  7. 14 Aug, 2018 1 commit
  8. 03 Jun, 2018 1 commit
  9. 10 Mar, 2018 1 commit
  10. 20 Feb, 2018 1 commit
  11. 16 Nov, 2017 1 commit
  12. 05 Oct, 2017 1 commit
  13. 04 Jan, 2017 2 commits
  14. 02 Jan, 2017 1 commit
  15. 01 Jan, 2017 1 commit
  16. 08 Dec, 2016 2 commits
  17. 22 Jul, 2016 1 commit
  18. 17 Jan, 2016 1 commit
  19. 06 Jun, 2015 1 commit
    • intrigeri's avatar
      Update AppArmor aliases adjustments to work with AppArmor 2.9. · 0a50f827
      intrigeri authored
      It is quite a bit more picky and failed to load profiles with:
      
        profile has merged rule with conflicting x modifiers
        ERROR processing regexs for profile sanitized_helper, failed to load
      
      Looking at it closely, one realizes that it's totally correct, and our previous
      adjustments were incomplete.
      
      This change includes re-diff'ing so that this patch applies cleanly against
      the profiles shipped by apparmor 2.9.0-3~bpo70+1 (uploaded to our APT overlay
      for this branch, but not to Debian yet).
      0a50f827
  20. 04 Jun, 2015 1 commit
  21. 03 Jun, 2015 1 commit
    • intrigeri's avatar
      Use aliases so that our AppArmor policy applies to /lib/live/mount/overlay/... · 6e48b6d6
      intrigeri authored
      Use aliases so that our AppArmor policy applies to /lib/live/mount/overlay/ and /lib/live/mount/rootfs/filesystem.squashfs/ as well as to it applies to /.
      
      That's something I wanted to avoid initially, for various reasons that are
      explained already in [[contribute/design/application_isolation]]. However, now
      that /lib/live/mount/overlay/ is accessible, I see no better way to protect
      files accessed via this path as well as the same files accessed by
      "normal" paths.
      
      These changes are likely to increase policy compilation time a bit, benchmarking
      will tell. If that's too severe a problem, we have a few potential ways out,
      that are already documented in the "Increased policy compilation time" section
      of the aforementioned piece of design doc.
      6e48b6d6