Re: [Tails-dev] Feature #5301 - Clone or Backup Persistent Volume

[emmapeel]

sajolida:
> Spencer:
>>> Emma Peel (in copy) could be
>>> interested as she's been giving a workshop on Tails backups last week
>>> and 32C3.
>>

Ok, I didn't tried Andrew's script, but I can say that the 'permissions
issue' was for the users that attended the most difficult part to follow.

As in after backing up they lose the configurations,
live-additional-software, etc.








signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Feature #5301 - Clone or Backup Persistent Volume

[Andrew Gallagher]

Andrew Gallagher
> On 10 Jan 2016, at 08:40, emmapeel  wrote:
> 
> Ok, I didn't tried Andrew's script, but I can say that the 'permissions
> issue' was for the users that attended the most difficult part to follow.
> 
> As in after backing up they lose the configurations,
> live-additional-software, etc.

Yes, the tool performs the equivalent of 
tails-fix-persistent-volume-permissions on the target partition after rsyncing. 
I had to code it separately as t-f-p-v-p hardcodes the location of the source 
partition. 

Solving that was particularly urgent, as I use apt persistence to pull my 
custom software onto the tails drive for testing, which is much easier than 
rebuilding images. 

(The only wrinkle that still trips me up is that persisting single files is not 
supported, so I have to persist the entire /etc/apt/sources.list.d directory, 
thus tails upgrades require manual intervention - but that's a separate issue)

A
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [Secure Desktops] Tails' MAC 'leak prevention' question

[intrigeri]

Hi,

[not Cc'ing other mailing-lists because 1. what I'm going to discuss
has little to do with the initial request, and is mostly
Tails -specific; 2. I don't fancy cross-posting entire discussions.
Let's report back to the other lists once we've reached some kind of
conclusion here.]

anonym wrote (22 Dec 2015 16:21:50 GMT) :
> Patrick Schleizer:
>> Wouldn't it be possible, and simpler, to block all networking with
>> iptables to prevent early MAC leaks so kernel module blacklisting could
>> be avoided?

After spending hours hunting down #9012 today, I must say I'm
interested in any solution that does not rely on un-blacklisting
kernel modules :]

> I'm not sure it would be simpler. The module blocking approach
> definitely makes some other parts of the implementation simpler and
> decoupled so the MAC spoofing system more or less can be plugged into
> the existing Tails without modifying other parts.

Right. I'd like to keep this property, and I think we can keep it
while changing the way we block outgoing connections during boot.

How about this minimal change:

a) We remove the modules blacklist logic.
b) We set up a boot-time firewall that blocks all outgoing connections
   to non-loopback interfaces.
c) We keep the udev MAC spoofing hook as-is: when the user hasn't made
   a decision yet, we don't do anything; if the user has made
   a decision already, we apply it.
d) We make all our NM hooks exit early unless the user has made their
   MAC spoofing decision already, just like they most of them exit
   early unless we're up'ing a non-loopback interface.
e) Once the user has made their decision wrt. MAC spoofing (that is,
   in tails-unblock-network, run by PostLogin, just as it is now):

   1. We record that decision in some place where all legitimate
  interested parties (at least the MAC spoofing udev hook, and our
  NM hooks) can check it out.
   2. We trigger udev, wait for it to settle. The goal here is to have
  the udev MAC spoofing hook run.
   3. We replace the boot-time firewall with the production one.
   4. We start NetworkManager.

For coldplugged network adapters: in theory, udev settle guarantees
that the firewall is unlocked, and NM is started, /after/ the MAC
spoofing hook has been run.

For hotplugged network adapters: in theory, udev should not make
a device available to NM before the MAC spoofing hook has run; that's
exactly what our current implementation relies on, to make it safe to
hotplug such devices, even though the corresponding modules are *not*
blacklisted anymore when they're plugged, right?

It feels to easy, so perhaps I'm missing what makes it hard?

> Also, it feels safer to rely on the lack of code (i.e. no module loaded)
> than more code (iptables (via ferm) and netfilter blocking absolutely
> everything for some device, even low-level wireless active probing etc).

I think that the above proposal addresses all other problems you
raised with the netfilter-based idea, so unless I missed a serious
problem, then this argument might be the only strong one we have in
favour of our current implementation (aside of the fact that our
current implementation exists and works in most cases already, of
course :)

> Also note that we want to support hotplugging network devices safely
> (w.r.t. MAC spoofing) after boot and logging in, so the firewall rules
> would have to be updated dynamically upon when a device is added (and
> removed!), which seems complex and makes me feel a bit uneasy.

I'd rather not do that, indeed. But I don't think we need it.

I've found it helpful to think about how we currently handle
hotplugged devices: we don't update the blacklist dynamically, we just
delete it once the user has made their decision. And then, we assume
that we can do the right thing even once the blacklist has been
removed, so I don't see why we would need more precise, per-device
rules, than what I'm suggesting above (boot-time vs.
production firewall), if we were to switch to
a netfilter-based approach.

Cheers!
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Help! JavaScript / GNOME Shell extension problem || removing topIcons

[intrigeri]

Hi,

one the remaining issues that make me a bit sad about the current
state of Tails/Jessie (scheduled to be released in two weeks) is:

  https://labs.riseup.net/code/issues/10576

Sadly, I lack the expertise needed to efficiently debug this, so
I figured I'd better call for help now, instead of being all "I'm so
sorry in I didn't become a JS expert yet" in two weeks.

Anyone at ease with JavaScript and/or the GNOME Shell extensions
system, who has time to give a hand?

Here are the other options I think we have; we don't need to choose,
each of the three paths is worth the effort in itself:

 * Try and reproduce the bug on Tails/Stretch: it might be that this
   is all caused by a bug in GNOME Shell, GLib or something, that
   might have been fixed in more recent version of GNOME. We have no
   branch that builds ISO images based on Debian Stretch yet, though.
   Any taker? Worst case, I expect that anonym and I will start
   working on it in May/June, to the latest, if we manage to resist
   the temptation this long.

 * Speed up the removal of the topIcons extension, that was meant as
   a temporary solution anyway; this would work if, and only if, it is
   _really_ the culprit. There are quite a few blockers, including
   replacing Vidalia with Tor Monitor:

 https://labs.riseup.net/code/issues/8309

   Note that in my experience, I think I've always seen the bug happen
   after the Vidalia icon appeared, so it might be that there's some
   bad topIcons/Vidalia interaction, that would be solved "simply" by
   replacing Vidalia (even if we keep topIcons a bit longer, for the
   other icons we need to move up there).

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.