[Tails-dev] tails-persistence-setup and feature coupling

[Ague Mill]

Hi!

While reflecting on the implementations of persistence of Network
Manager connections and browser bookmarks, it occured to me that we
might have an undesired coupling between tails-persistence-setup and
our persistence framework as a whole.

The implementation of persistent NM connections lead me to think that
the pivot of our persistence framework is in
`amnesia.git:config/chroot_local-includes/usr/local/sbin/live-persist`.

Yet, both new persistence options required a change in
another component, namely tails-persistence-setup to update
`lib/Tails/Persistence/Configuration/Presets.pm`. 

I wonder if we should not move the content of Presets.pm to an
'external' file (from the point of view of tails-persistence-setup)
which would live closer to `live-persist` instead. It could still be
Perl code or transformed into YAML or another ad-hoc format. The trick
is that it needs to be i18n'ed somehow...

Any other opinions?

(I don't think I'm fluent enough in Perl to propose any implementation,
though.)

-- 
Ague


pgpHEBzpxqFrq.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

[Maxim Kammerer]

On Mon, Oct 15, 2012 at 6:30 PM, Abel Luck  wrote:
> Nevertheless, my point (repeating myself here), is that there should be
> a zero-second window option regardless, for those that care. Moreover,
> that option does not have to significantly affect the UX.

You can already do that if the distribution supports module
blacklisting boot options. I believe that in Debian this can be
achieved by adding “firewire-sbp2.blacklist=yes”.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Bookmarks persistence - help needed

[Ague Mill]

On Thu, Oct 11, 2012 at 11:11:14PM +0200, Alessandro Grassi wrote:
> > Yes, it is too late. But don't worry, 0.15 should be out early
> > December. :)  That gives us a little more room to have the
> > documentation well polished and delivered with more translations.
> 
> Fine. I made a new patch for documentation, and symlink patch is fixed
> to create the bookmarks folder. All the needed patches are attached.

Wonderful!

Everything works fine according to my tests, so  I have pushed your work
in the `feature/persistent_bookmarks` branch and merged it in
experimental.

Please note that I did not upload a customized tails-persistent-setup
and relied on a patch instead, as I wanted to leave
tails-persistent-setup alone until 0.14 is out.

-- 
Ague


pgpy0w7UrUpOm.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Images on doc/first_steps/persistence/configure broken in offline documentation

[Ague Mill]

Hi!

The source for the `doc/first_steps/persistence/configure` pages
contains:



Unfortunately, this relative path will not work for offline
documentation. Is there a problem in using ikiwiki's [[!img]]?

After some quick grepping, it looks like this is the only page with that
problem.

-- 
Ague


pgpZzwdY4nbth.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

[Abel Luck]

Ague Mill:
> On Mon, Oct 15, 2012 at 02:47:05PM +, Abel Luck wrote:
>> intrigeri:
>>> Hi,
>>>
>>> Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) :
 As this is a modular kernel - is there a reason not to simply add
 a "enable firewire" widget?
>>>
>>> There are several I can see:
>>>
>>> * It is a UX failure every time someone has to go out of their way to
>>>   have Tails work with their hardware.
>>> * Every such widget we add to Tails Greeter makes the greeter worse
>>>   for every Tails user: more cluttered, more complicated.
>>>
>>> That's why I still prefer the "let's guess what the user wants"
>>> approach: if they plug a device in the "X" slot, that's probably
>>> because they want to use it, so let's keep the "X" bus enabled, and
>>> disable it else.
>>>
>>> OTOH, I understand your concern, and I now think the 5 minutes delay
>>> that was suggested may be a bit too long. We did not specify exactly
>>> when the 5 minutes countdown starts, anyway. Perhaps we could start an
>>> initscript right after GDM, have it sleep 1 minute, and then disable
>>> these dangerous buses if unused? (This gives a clear visual indication
>>> of when the countdown starts.)
>>
>> Regardless of the solution proposed above, would it be possible to have
>> an alternate grub menu that disables these dangerous interfaces from the
>> get go?
> 
> Please note that Tails is using SYSLINUX at the moment and not GRUB. 

Noted.

> 
>> There could be an "Advanced" grub menu entry, that displays these
>> alternative kernel-param boot options.
>>
>> Surely, there should be *some* secure option where the window of attack
>> is zero?
> 
> How would you label it so that it does not puzzle users who are using a
> FireWire external disks, but never had to think about the word "FireWire"
> before?

Sorry, I wasn't clear. The bootime options I proposed were the firewire
disabled options.

Assuming, as seems to be the reasoning so far, that the default behavior
will be the most usable (enabled for X minutes then disabled, or w/e),
my idea is to have a "disabled from boot" alternative option.

To answer your question, my thought was it would be hidden behind an
advanced menu, so users who didn't care and didn't know will not pay it
any mind.

Example (for the sake of clarity):


++
||
|  * Boot Tails  |
|  * Memtester   |
|  * Advanced >  |<- option behind this menu
||
++

> 
> What would you write in the end-user documentation? Who would be using
> such option?
> 

The documentation would explain, in layman's terms, the risk of such
interfaces, then it would explain the default behavior of the X-minute
window. Next, it would explain the the potential threat scenarios in
which a user might be concerned about that window, and, finally,
instruct how to use the advanced option.

I would use such an option, I imagine Jake would as well (though I won't
speak for him). Any potential tails user (1) with the awareness of such
attacks and (2) desire mitigate them.


> I am afraid about the endless stream of "why are you not making it the
> default?", like the one we already get regarding Javascript. Answers
> would probably be even quite similar. I'm not having such option, but it
> really needs to be done right.
> 

Absolutely it should be done right.

You shouldn't be afraid of that question. The answer to "why are you not
making it the default?" is being discussed right now in this email
thread, see Jacob's point in the great-great-grandfather of this message
and intrigeri's reply.

I still think this should be the default, and the enabled firewire the
advanced option. I can't imagine the majority of users use firewire.
Putting the majority at risk for the minority doesn't seem a good idea,
BUT I can concede that thought with the 1-minute window proposal.

Nevertheless, my point (repeating myself here), is that there should be
a zero-second window option regardless, for those that care. Moreover,
that option does not have to significantly affect the UX.

~abel




signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] tordate issue in Tails 0.14~rc1

[anonym]

Hi,

When I ran the test suite for Tails 0.14~rc1 I seem to have made a
mistake by passing a test which didn't pass. The test in question is the
"Time" test:



While running the test suite I ran several tests in parallel (to be more
efficient :)) which resulted in me creating a new VM profile. In
VirtualBox, which I use, the default is to have it's Host-to-Guest time
syncing on by default, which is run every second or so. Of course I
happened to run the time test in this new VM, so when I messed with the
clock, it was set correctly again *by* *the* *VM* some seconds later,
which made our time sync stuff seem to work.

But running that test without Host-to-Guest time syncing will fail since
Tor won't write an unverified-microdesc-consensus like it used to write
a unverified-consensus prior to Tor 0.2.3.x. wait_on_tor_consensus()
will hence never succeed. The use of microdescriptors isn't the issue as
Tor now fails earlier, right after "Bootstrapped 10%: Finished handshake
with directory server" instead of (as earlier) "Bootstrapped 20%: Asking
for network consensus". It gives this warning:

Jan 01 01:07:38.000 [warn] Certificate not yet valid. Either their
clock is set wrong, or your clock is wrong.
Jan 01 01:07:38.000 [warn] (certificate lifetime runs from Oct 15
14:53:13 2012 GMT through Oct 15 14:53:13 2013 GMT. Your time is
Jan 01 01:07:38 2000 GMT.)
Jan 01 01:07:39.000 [warn] Certificate not yet valid. Either their
clock is set wrong, or your clock is wrong.
Jan 01 01:07:39.000 [warn] (certificate lifetime runs from Oct 15
15:16:39 2012 GMT through Oct 15 15:16:39 2013 GMT. Your time is
Jan 01 01:07:39 2000 GMT.)

For the record, I started Tor at this 16:18:46 UTC in real time.

I tried a small patch (see below) which, in essence, moves
wait_on_tor_consensus() until after the "is_clock_way_off" check + fix
(which actually makes sense in general). It worked, because the Tails
release date (today) was close enough (but still outside, I believe) to
the certificate's issue date. I faked the release date to that of
0.14~rc1 (almost a week ago) and that also worked, which is weird given
that the certificate definitely wasn't valid then. Finally I tried
setting the release date to something like a month back, and that made
it fail like before.

This means we're in trouble, and that there likely is no easy fix. I
suspect we need modifications in Tor if we want our current approach to
work again. :/ I don't really know what to make of all of this, but I
suppose I'll look into it further tomorrow. I'd appreciate any input
though :).

Cheers!

(For the record, here's the patch:)

--- 20-time.sh.orig 2012-09-01 00:08:53.765292730 +
+++ 20-time.sh  2012-09-01 00:09:25.116894099 +
@@ -226,16 +226,15 @@
 if tor_is_working; then
log "Tor has already opened a circuit"
 else
-   wait_for_tor_consensus
# It may be that all authority certificates look "expired" due to
# a clock far off into the future. In that case let's set the clock
# to the release date.
if is_clock_way_off; then
log "The clock looks very badly off. Setting system time to the
release date, restarting Tor and fetching a new consensus..."
-   date --set="$(release_date)" > /dev/null
-   service tor reload
-   wait_for_tor_consensus
+   date --set="20120901"
+   service tor restart
fi
+   wait_for_tor_consensus
maybe_set_time_from_tor_consensus
 fi

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

[Ague Mill]

On Mon, Oct 15, 2012 at 02:47:05PM +, Abel Luck wrote:
> intrigeri:
> > Hi,
> > 
> > Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) :
> >> As this is a modular kernel - is there a reason not to simply add
> >> a "enable firewire" widget?
> > 
> > There are several I can see:
> > 
> > * It is a UX failure every time someone has to go out of their way to
> >   have Tails work with their hardware.
> > * Every such widget we add to Tails Greeter makes the greeter worse
> >   for every Tails user: more cluttered, more complicated.
> > 
> > That's why I still prefer the "let's guess what the user wants"
> > approach: if they plug a device in the "X" slot, that's probably
> > because they want to use it, so let's keep the "X" bus enabled, and
> > disable it else.
> > 
> > OTOH, I understand your concern, and I now think the 5 minutes delay
> > that was suggested may be a bit too long. We did not specify exactly
> > when the 5 minutes countdown starts, anyway. Perhaps we could start an
> > initscript right after GDM, have it sleep 1 minute, and then disable
> > these dangerous buses if unused? (This gives a clear visual indication
> > of when the countdown starts.)
> 
> Regardless of the solution proposed above, would it be possible to have
> an alternate grub menu that disables these dangerous interfaces from the
> get go?

Please note that Tails is using SYSLINUX at the moment and not GRUB. 

> There could be an "Advanced" grub menu entry, that displays these
> alternative kernel-param boot options.
> 
> Surely, there should be *some* secure option where the window of attack
> is zero?

How would you label it so that it does not puzzle users who are using a
FireWire external disks, but never had to think about the word "FireWire"
before?

What would you write in the end-user documentation? Who would be using
such option?

I am afraid about the endless stream of "why are you not making it the
default?", like the one we already get regarding Javascript. Answers
would probably be even quite similar. I'm not having such option, but it
really needs to be done right.

-- 
Ague


pgp8l9z0LmDSa.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Faking htpdate user agent worth it?

[anonym]

14/10/12 14:28, intrigeri wrote:
> Hi,
> 
> Ague Mill wrote (01 Oct 2012 09:27:09 GMT) :
>> I think the overhead of not using '--head' and doing a full GET
>> would be marginal. It would make it at least a little bit harder to
>> distinguish from other requests.
> 
> Fully agreed: this would make Tails' htpdate harder to distinguish
> from the TBB at the level of a single request / access.log line,
> and only stand out in aggregate.

OTOH it becomes easier to fingerprint Tails users on their side of the
pipe, which arguably is worse. Three *full* fetches of known web sites
are *much* more distinguishable than three header fetches of known web
sites, so Tails' startup traffic flow then becomes a distinctive pattern
to look for. Think "Bayesian classifiers" which was all the rage a year
or two ago.

The fact that Tails' current htpdate should be (relatively) safe from
fingerprinting since it only fetches headers is already documented here:
contribute/design/Time_syncing/#index5h1.

Slightly off-topic: Reading the above design doc made me thinking about
how recent changes in Tails may have affected it. Since the introduction
of stream isolation (Tails 0.14~rc1), htpdate (and other Tails-specific
applications) uses a SocksPort with IsolateDestAddr, so no circuit
sharing occur between fetches. Will this make htpdate fingerprinting
even easier when combined with full fetches?

* *Without* circuit sharing I imagine that the eavesdropper only has to
  measure the traffic flow of a full fetche for each individual pool
  member and store this infor for future comparisions (when an IP
  address shows three of these flows, it's a Tails user with large
  probability).

* *With* circuit sharing the eavesdropper would need to measure the
  traffic flow of fetching all combinations of three pool members
  instead. Hmm. On second thought I suppose it's easy to take the
  individual measurements from the previous point and create all
  combinations of three from them...

Well, I don't feel convinced by my own argument for stream isolation
being an issue for htpdate + full fetches, but let me just throw this
thought out there for others to ponder upon to be sure.

However, I do get the impression that stream isolation => loss of
circuit sharing may make htpdate easier to fingerprint in general. Full
fetch or not, each boot resulting in three different circuits being used
simultaneously seem more distinguishable than each boot resulting in
just a single circuit being used. OTOH, I'm a bit unsure whether Tor
guarantees that simultaneous fetches must share the same circuit when
stream isolation isn't used. If there's no such guarantee, then we
obviously shouldn't base our assumptions on it.

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails: pcmcia / firewire / etc.

[Abel Luck]

intrigeri:
> Hi,
> 
> Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) :
>> As this is a modular kernel - is there a reason not to simply add
>> a "enable firewire" widget?
> 
> There are several I can see:
> 
> * It is a UX failure every time someone has to go out of their way to
>   have Tails work with their hardware.
> * Every such widget we add to Tails Greeter makes the greeter worse
>   for every Tails user: more cluttered, more complicated.
> 
> That's why I still prefer the "let's guess what the user wants"
> approach: if they plug a device in the "X" slot, that's probably
> because they want to use it, so let's keep the "X" bus enabled, and
> disable it else.
> 
> OTOH, I understand your concern, and I now think the 5 minutes delay
> that was suggested may be a bit too long. We did not specify exactly
> when the 5 minutes countdown starts, anyway. Perhaps we could start an
> initscript right after GDM, have it sleep 1 minute, and then disable
> these dangerous buses if unused? (This gives a clear visual indication
> of when the countdown starts.)

Regardless of the solution proposed above, would it be possible to have
an alternate grub menu that disables these dangerous interfaces from the
get go?

There could be an "Advanced" grub menu entry, that displays these
alternative kernel-param boot options.

Surely, there should be *some* secure option where the window of attack
is zero?

~abel




signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev