| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
If this idea turns out working well, this should be upstreamed.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
AppArmor regexps don't understand '+' yet, so
/usr/lib/cups/backend/ipp14 was not matched.
Will-fix: #10893
|
|/ |
|
|\
| |
| |
| | |
Fix-committed: #10167
|
| |
| |
| |
| | |
Will-fix: 10167
|
|/ |
|
| |
|
| |
|
|
|
|
| |
Closes: #10591
|
|
|
|
|
|
|
|
|
|
| |
This essentially reverts ALSA state handling to pre-Jessie.
For Stretch we might need something better, but it's simple enough that
we could easily turn the relevant bits of the legacy initscript into
a systemd unit file if needed.
Closes: #7591
|
|
|
|
|
|
|
|
|
|
| |
Jessie's systemd has no AppArmor support, so Tor 0.2.7.x backport for Jessie's
systemd unit files don't load the profile. We've ensure that on Stretch
everything will work just as we need, but for Jessie we need this kludge:
simply rename the system_tor profile so that it's used automatically, without
having to explicitly assign it to the service.
Closes: #10528
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
config/base_branch
features/images/TailsGreeterTorConf.png
features/step_definitions/apt.rb
features/step_definitions/checks.rb
features/step_definitions/common_steps.rb
features/step_definitions/firewall_leaks.rb
features/step_definitions/tor.rb
features/support/helpers/misc_helpers.rb
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want stream isolation so that is set here. Additionally we want to
use the standard SKS keyserver pool like the command-line gnupg client
and Seahorse use in Tails.
Note that enigmail does *not* support using hkps.
Note also that we patch the source to due to the following as noted in
`components/torbirdy.js`:
// Default preference values for TorBirdy.
// These preferences values will be "enforced": even if the user decides to
// change the preferences listed below, they will be reset to the TorBirdy
// default when Thunderbird restarts. The reason we are doing this is because
// these preferences, if changed, can introduce leaks and therefore should be
// not changed by the user. Even if the user does change them, we reset them to
// the secure default when Thunderbird starts.
|
| |
| |
| |
| |
| |
| | |
/etc/cups, /var/{cache,log,spool}/cups.
Closes: #10210
|
| |
| |
| |
| |
| |
| | |
/lib/live/mount/overlay.
This is now globally handled with aliases.
|
| |
| |
| |
| |
| |
| |
| |
| | |
It "will be merge into the greeter but is here for testing" since a year,
is fuzzy on Jessie, and we have no working Windows camouflage there anyway.
Anyone who makes it work again will want to apply this patch to the Greeter
for real, next time.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
hook.
This should avoid the need to maintain these patches and avoid them becoming
fuzzy, especially when migrating to new versions of Debian.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Closes: #9963
More specifically:
a) avoid "conflicting x modifiers" for /usr/bin/hpijs, by modifying the
/usr/bin/* rule to not match it;
b) add missing backends to the list of confined ones, and:
asked how we can better maintain this list :
https://lists.ubuntu.com/archives/apparmor/2015-August/008463.html
c) to avoid "conflicting x modifiers", replaced glob that matches
all remaining backends by a hard-coded list of third-party ones
we ship;
d) Added a note to the RM role duties to sanity check these two lists.
Also, add the attach_disconnected flag to the third_party local profile in
there, as was done in sid already, and is needed for it to work under systemd
(this patch already did that for /usr/sbin/cupsd).
|
| |
| |
| |
| | |
apparmor-adjust-totem-profile.diff: otherwise they leave .orig files around, that apparmor_parser fails to load.
|
| |
| |
| |
| |
| |
| | |
'systemctl disable'.
Closes: #9881
|
|\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
config/base_branch
config/chroot_apt/preferences
features/totem.feature
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We can't add /lib/live/mount/rootfs/*.squashfs/ to HOMEDIRS, so each such
profile will need to be patched this way.
Will-fix: #9552
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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).
|
| | |
| | |
| | |
| | | |
Fixes regression for bridge mode introduced in commit ba3de99.
|
| | |
| | |
| | |
| | | |
generic, so that it covers SquashFS installed by automatic upgrades as well.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
That abstraction gives /usr/bin/launchpad-integration wide open access to many
files and executables; on the one hand we don't care much, since we don't ship
that binary. On the other hand, some of those wide-open rules (for example,
those about /** and /{,usr/}lib*/{,**/}*.so{,.*}) won't play well with aliases:
they make the policy needlessly hard to audit, and may increase its
compilation time.
The Pidgin profile is the only one we currently ship that includes the
launchpad-integration abstraction. Same on my current Debian sid, so we should
be good at least for Tails/Jessie (and possibly even for Tails/Stretch).
|
| | |
| | |
| | |
| | | |
now have an alias for /lib/live/mount/overlay/.
|
| | |
| | |
| | |
| | | |
an alias for /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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With live-boot 3.0.1-1 in Tails 1.4~rc1, /live/overlay appears to be empty both
with ls and df. It feels wrong, because that's where the read-write branch of
our aufs mount lives, and there must be data in there.
We actually have _two_ tmpfs mounted there, as live-boot mounts stuff twice on
/live/overlay:
- with `mount -t tmpfs tmpfs /live/overlay` (line 159 in `9990-overlay.sh`)
- with `mount -t tmpfs -o rw,noatime,mode=755 tmpfs /live/overlay` (same file,
line 296)
And then, shortly after, it tries to unmount one of those, leading to a `umount:
can't umount /live/overlay: Device or resource busy` message one can see in
`/var/log/live/boot.log`. My understanding is that the top-most mountpoint
umount sees is the one used for the root aufs).
Then, live-boot runs `mount -o move /live/overlay /root/lib/live/mount/overlay`
_twice_, which is expected given live-boot does that for every mount (since
commit d2b2a461 in live-boot Git).
With all this in mind, my understanding is that the first tmpfs that was mounted
is `mount -o move`'d last, so it hides the one that was mounted last, which is
actually the one that's used as the read-write branch of the root filesystem's
union mount.
This raises two practical problems:
1. One cannot inspect how much space is used, at a given time, in the read-write
branch of the root filesystem's union mount. Probably almost nobody cares,
expect developers who want to analyze performance issues / resource
consumption, and power users who want to check whether they have enough room
left e.g. to download a large file. Admittedly, if this problem was the only
one, I would not have bothered spending so much time in live-boot's source
code to go through this analysis. Sadly, this is not the case:
2. As far as AppArmor policy is concerned, in theory the more files are hidden,
the better. However:
* if this (arguably buggy) live-boot behavior change under our feet in the
future, then our AppArmor policy may suddenly be more open than we would
like; therefore, it would be better to fix that bug ourselves now, so that
we can analyze the consequences of exposing the read-write branch's
content, _and_ adjust our AppArmor policy accordingly at the same time;
* I'm not 100% sure how AppArmor policy applies to such stacked mounts: e.g.
if some file was left open in an underlying mount, its file handle might be
used by some application to access other files (that we might otherwise
believe are not accessible). This kind of things is pretty hard for me to
reason about (I lack the corresponding low-level system skills). So, better
expose these files, and then we'll be able to actually *test* and confirm
what's the real-world effect of potentially letting applications access
them (mediated by DAC and MAC, of course), and again, adjust DAC
permissions and AppArmor policy as needed.
Now, about the actual change. Ideally we would "simply" invert the order of the
`mount -o move' operations. However, the two mounts have the same mountpoint,
and the only way we have to differentiate them is the options they were
mounted with. Given another programming language, I would just do it, but
with POSIX shell, oh well.
So, this patch simply comments out the first command that mounts a tmpfs on
/live/overlay. This is not applicable for upstream, because the large chunk of
code that's before this command and the other tmpfs mount on /live/overlay needs
such an active mount in use cases we don't care about, and even if it did not,
then this could change in the future -- and anyway, there must be a good reason
for mounting /live/overlay this early in the general case, right? :) But for us
it's OK, because the only operations before these two mount commands are about
persistence enabled at initramfs time, which we do not support and explicitly
disable on the kernel command-line.
Refs: #8007
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
bugfix/8007-AppArmor-hardening
Conflicts:
wiki/src/contribute/design/application_isolation.mdwn
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
/etc/apparmor.d/tunables/home.
This should make our Tails-specific configuration easier to maintain and audit.
|
| | | |
| | | |
| | | |
| | | | |
Refs: #7708
|
| | | | |
|
|\ \ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | | |
Conflicts:
features/step_definitions/erase_memory.rb
wiki/src/contribute/design/Time_syncing.mdwn
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
Otherwise it would set the hardware clock to the system time, violating (a
strict interpretation of) our "don't leave traces on the hardware being used"
design goal.
Will-fix: #9364
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
config/chroot_local-includes/etc/whisperback/config.py
|
| |\ \ \
| | |/ / |
|
| | |/ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Patch submitted upstream: https://rt.cpan.org/Ticket/Display.html?id=102644
This is required so that we can flag some notifications as "transient", which is
sometimes needed: GNOME Shell ignores the timeout we pass it. So, the
NotificationClosed signal is never send, and then the program that's waiting for
it would stay around forever, unless the user explicitly dismisses the
notification. This can lead to increased memory consumption. So, let's give us
the power to decide, for each notification we send, whether:
* it should stay around until the user dismisses it (or clicks on the action
button, if any), at the cost of some memory usage for the user, or of a more
complicated system that's left to be invented and implemented by us;
or,
* it will disappear after 4 seconds (see NOTIFICATION_TIMEOUT in
js/ui/messageTray.js, in the GNOME Shell source code), regardless of whether
the user has interacted with it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I've submitted this patch upstream:
https://rt.cpan.org/Ticket/Display.html?id=102643
Upstream seems to be inactive since 2009, but the entire library has 104 SLOC
(including my additions, excluding the test suite) that I understand easily, so
worst case I'll take it over there, or we'll carry the patch in Debian or
in Tails.
Will-fix: #7989 (just a first step)
|
| | | |
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
auto/build
config/chroot_apt/preferences
config/chroot_local-packageslists/tails-common.list
config/chroot_local-patches/gdm-background.diff
features/images/UnsafeBrowserStartVerification.png
features/step_definitions/apt.rb
features/step_definitions/evince.rb
po/POTFILES.in
wiki/src/contribute/design/memory_erasure.mdwn
wiki/src/support/known_issues.mdwn
|
| | |
| | |
| | |
| | |
| | |
| | | |
We've broken that when removing Polipo.
Will-fix: #8905.
|