1. 11 Jul, 2019 2 commits
  2. 28 Jan, 2019 1 commit
  3. 19 Nov, 2018 6 commits
    • intrigeri's avatar
      Add HTML anchor. · 29854ab5
      intrigeri authored
      29854ab5
    • 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.
      77f05fd2
    • 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.
      84c35373
    • 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.
      13a6b4d3
    • 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.
      b04c0891
    • intrigeri's avatar
      Remove obsolete potential problem. · 84b674fd
      intrigeri authored
      This is pretty well documented by now.
      84b674fd
  4. 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.
      b52a5596
  5. 01 Jul, 2018 1 commit
  6. 09 Nov, 2017 1 commit
  7. 13 Sep, 2017 1 commit
  8. 04 Jan, 2017 1 commit
  9. 20 Feb, 2016 1 commit
  10. 14 Sep, 2015 1 commit
  11. 25 Aug, 2015 1 commit
  12. 13 Jun, 2015 1 commit
  13. 04 Jun, 2015 1 commit
  14. 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
  15. 03 May, 2015 2 commits
  16. 01 May, 2015 1 commit
  17. 09 Apr, 2015 1 commit
  18. 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.
      9fb0136e
  19. 14 Mar, 2015 1 commit
  20. 10 Mar, 2015 3 commits
  21. 07 Mar, 2015 1 commit
  22. 06 Feb, 2015 1 commit
  23. 05 Feb, 2015 1 commit
  24. 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.
      ec0865b7
  25. 20 Oct, 2014 2 commits
  26. 06 Oct, 2014 1 commit