1. 13 Jan, 2021 1 commit
  2. 14 Apr, 2020 1 commit
  3. 21 Feb, 2020 1 commit
  4. 25 Nov, 2019 1 commit
    • intrigeri's avatar
      AppArmor: bring back aliases for the read-write branch of the root filesystem,... · d09dbefd
      intrigeri authored
      AppArmor: bring back aliases for the read-write branch of the root filesystem, adjust the test suite accordingly
      Since 3cdeadfe, the upper-dir (read-write
      branch) of the overlayfs we mount on / is now exposed again, so to ensure
      it does not provide alternative paths that would allow apps to access
      files that AppArmor is supposed to block, we need to bring back the aliases
      we previously had for aufs, modulo the read-write branch is now
      /lib/live/mount/overlay/rw instead of /lib/live/mount/overlay.
  5. 11 Jul, 2019 2 commits
  6. 03 Apr, 2019 2 commits
  7. 28 Jan, 2019 1 commit
  8. 19 Nov, 2018 6 commits
    • intrigeri's avatar
      Add HTML anchor. · 29854ab5
      intrigeri authored
    • intrigeri's avatar
      Update "ship a cached pre-compiled AppArmor policy". · 77f05fd2
      intrigeri authored
      All the pieces we needed from AppArmor upstream and from Debian are now in place
      in Buster, which allowed me to confirm all the hypothesis made in the previous
      version of this text. So let's drop all hypothetical statements and instead
      describe the current implementation constraints.
    • intrigeri's avatar
      Drop unrealistic idea. · 84c35373
      intrigeri authored
      This idea was always a bit over-optimistic. The "ship a cached pre-compiled
      policy" now appears to be very feasible so let's drop the other option.
    • intrigeri's avatar
      Remove another potential problem that's not one. · 13a6b4d3
      intrigeri authored
      The binary cache is per-profile: it's not a monolithic thing that either
      entirely valid or not. So any additional AppArmor profile shipped by Additional
      Software is compiled at postinst time, regardless of whether the cache for the
      policy we ship by default was loaded from the USB stick or generated from
      scratch at boot time.
    • intrigeri's avatar
      Remove highly theoretical potential problem. · b04c0891
      intrigeri authored
      I really don't see what could lead us to add AppArmor alias rules
      at login time: we already have hard-coded all the alias rules
      we need.
    • intrigeri's avatar
      Remove obsolete potential problem. · 84b674fd
      intrigeri authored
      This is pretty well documented by now.
  9. 03 Jul, 2018 1 commit
    • intrigeri's avatar
      Bundle our custom prefs into the Tor Browser's omni.ja (refs: #15023) · b52a5596
      intrigeri authored
      Shipping them in user.js has a few downsides:
       - They override whatever is in prefs.js so basically prefs in user.js are
         locked:  any modification done in about:config will be reverted next time Tor
         Browser starts, which can be a PITA when developing Tails.
       - In about:config, all these prefs are listed as modified by the user,
         which feels wrong.
       - It makes it harder for derivatives to implement things properly.
  10. 01 Jul, 2018 1 commit
  11. 09 Nov, 2017 1 commit
  12. 13 Sep, 2017 1 commit
  13. 04 Jan, 2017 1 commit
  14. 20 Feb, 2016 1 commit
  15. 14 Sep, 2015 1 commit
  16. 25 Aug, 2015 1 commit
  17. 13 Jun, 2015 1 commit
  18. 04 Jun, 2015 1 commit
  19. 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.
  20. 03 May, 2015 2 commits
  21. 01 May, 2015 1 commit
  22. 09 Apr, 2015 1 commit
  23. 29 Mar, 2015 1 commit
    • intrigeri's avatar
      Convert a few X session startup programs to `systemd --user' units. · 9fb0136e
      intrigeri authored
      This is merely preparatory work that lays down some foundations.
      For now, we're using two targets:
       * basic.target sets up things that should be done as early as possible, don't
         need access to X, notifications, nor D-Bus ; it is automatically started by
         `systemd --user' when the logind session is created. Note that this happens
         after persistence has been set up, when the GDM autologin is triggered, and
         before /etc/gdm3/Xsession is run:
         - tails-add-GNOME-bookmarks.service
         - tails-create-tor-browser-directories.service
       * desktop.target: we're starting it via xdg/autostart during the GNOME session
         startup. There are a few units wanted by this target so far:
         - tails-configure-keyboard.service
         - tails-virt-notify-user: ideally, this should have something like
           After=notifications-ready.target (and then, most other things that
           wait for GNOME Shell to be ready to handle notifications could do the
           same instead of grep'ing the process list).
         - tails-warn-about-disabled-persistence.service
         - tails-upgrade-frontend.service: the idea is to later use systemd units
           ordering to make it run at a time that increases chances for the system
           having enough free memory; e.g. as soon as possible once the session is
           ready, Tor has bootstrapped, and some other memory-hungry programs we run
           at session startup time have completed.
         - tails-security-check.service: similarly, the idea is that we could get
           rid of the wrapper — that merely waits for Tor to have finished
           bootstrapping — given another systemd unit.
      Most of these units exit early unless they're run by the `amnesia' user.
      Otherwise they break e.g. Tails Greeter startup, and probably worse.
      Also note that the units that may take ages to complete have Type=simple.
      With Type=oneshot, systemd would wait for them to complete before running any
      follow-up units, and before considering the target they're part of has been
      reached. Two of our units can take minutes to complete, so the desktop.target
      startup would fail. Now, using Type=simple has one drawback: it makes it harder
      to order other units relatively to tails-security-check-wrapper's and
      tails-upgrade-frontend-wrapper's completion. This doesn't feel too bothering,
      though: it's more likely that we want to configure these units to start after
      others, than the opposite.
      Also, when the GNOME session is initialized, we import the relevant D-Bus, X11
      and locales variables into systemd --user's environment, so that our units can
      use them. We do that immediately before starting desktop.target.
  24. 14 Mar, 2015 1 commit
  25. 10 Mar, 2015 3 commits
  26. 07 Mar, 2015 1 commit
  27. 06 Feb, 2015 1 commit
  28. 05 Feb, 2015 1 commit
  29. 28 Nov, 2014 1 commit
    • Tails developers's avatar
      Wrap Totem to torify it with torsocks. · ec0865b7
      Tails developers authored
      Also, AppArmor: allow Totem to read torsocks.conf. Technically speaking, it's
      not really required, as the compiled-in defaults are the same as whatever is in
      the stock torsocks.conf. But still, this avoids nasty error messages in the logs
      and when running Totem from a terminal.
  30. 20 Oct, 2014 1 commit