Re: [Freepto] [Tails-dev] (senza oggetto)

Nachricht löschen

Nachricht beantworten
Autor: Patrick Schleizer
Datum:  
To: freepto
Betreff: Re: [Freepto] [Tails-dev] (senza oggetto)
Hi!

intrigeri:
> Patrick Schleizer wrote (16 Sep 2014 01:02:28 GMT) :
>> intrigeri:
>>> Patrick Schleizer wrote (03 Jul 2014 14:55:57 GMT) :
>
>>> bootclockrandomization
>>>
>>> Randomizes clock when systems boots by adding a few seconds and
>> nanoseconds to enforce the design goal, that the host clock and
>> Gateway/Workstation clock should always slightly differ (even before
>> secure timesync succeeded!) to prevent time based fingerprinting /
>> linkablity issues. For better anonymity and privacy.
>
> This conflicts with any other mechanism that sets the time (e.g.
> GNOME time sync, ntp, etc.), right?


Depends on what you mean by you mean by conflicting. It randomizes the
clock only at boot, that's all, and other time keeping mechanisms are
free to adjust it from there. Having bootclockrandomization co-installed
with NTP is probably not very useful, indeed. Because NTP leaks the
local system clock. [1] But would that justify "Conflicts: ntp"?

> If so, creating (and maintaining!)
> the list of conflicting packages within the Debian archive seems to be
> a daunting task to me.


Creating the list could be simplfiied thanks to the "packagesearch"
package as well as the debtag "use::timekeeping"? Maintaining the list,
well, are new NTP like time keeping packages added to the Debian archive
every year?

> Also, note that:
>
>> NEW_TIME="$(( $OLD_UNIXTIME $PLUS_OR_MINUS $DELAY ))"
>
> ... is a bit misleading, as the time spend between when $OLD_UNIXTIME
> was computed and when you're doing that is implicitly added to the
> delay.


[ Could answer this: It's not a bug, it's a feature. "Extra
randomization based on system speed." ;) ]

Changelog: bootclockrandomization: Set OLD_UNIXTIME variable right
before calculation of NEW_UNIXTIME so calculation gets more accurate.
Thanks to intrigeri for pointing that out!
(https://mailman.boum.org/pipermail/tails-dev/2014-September/006983.html) [2]

> I would instead compute random numbers first, and then run
> `date --set', passing it shell command interpolation $(..) to get the
> current time.


I could do this as well, would make the calculation a bit more accurate
as well as the code a bit less readable (for me). Should this be an
important thing to do or required for Debian archive I can certainly
live with the latter. (More of a stylistic question also, I think.)

>> - tcp-timestamps-disable
>> - ipv4-forward-disable
>> - ipv6-disable
>
> Wow, I'm not sure I'd be interested in going *that* far into using
> Debian packages for everything. The overhead is huge just to create
> a one-liner file.


Not sure what you mean by overhead. The packaging work is mostly a copy
and past task of an existing similar package because it's mostly just
moving files around and "generic packaging" [4].

What I also find nice, that design documentation can be in the vicinity
of the code itself. For example the package description of
tcp-timestamps-disable. [5] You'll notice it's taken from Tails design
with appropriate attribution and licensing [6], I hope.

> As I see it, the main use of moving this kind of
> stuff into Debian packages is that all interested distros can share
> a single source tree for a given feature.


Yes. And more.

- source code got easier to understand:

As far as Whonix is concerned, I have the feeling that this kind of
modularity helps other coders to now better grasp what the heck Whonix
is actually doing and how compared to the past, where there where just
three giant folders (whonix_shared(|gateway|workstation)/etc/... and so
forth). More people working on Whonix now. Statistics: +1 working on
Whonix KVM support and other stuff; +1 working on Whonix Qubes support;
+1 coding Whonix Qubes support; +1 working on AppArmor and coding other
stuff

- Easier extensible:

Since separate functionality is now conceptually encapsulated into
separate abstraction layers (different packages), extension / rewrite /
audit got simpler.

- More porting / modding friendly:

Got now a much easier time explaining how one could port Whonix or
certain functionality to rpm, other base distributions, desktop
environments, etc. Much easier to document what of Whonix functionality
is missing in latest stable if one wouldn't use KDE, but Gnome (ex:
open-link-confirmation would be missing). And if one disagrees for
example about the use of the "ipv4-forward-disable", or wants to do
something different, they can do a custom build omitting that package.

> Do you expect that specific line to need change in
> the future?


Dunno.

I had in mind maybe adding postinst/postrm (un)applying these settings
after install into a running system. (Because at the moment they assume
to be installed before the system gets actually booted for the first
time or rebooted or the user applying them after installation.)

> (A middle-ground could be to either pack a bunch of similar tweaks
> into a single package, or to use Puppet recipes.)
>
>> - poweroff-passwordless
>
> For *all* users, really?


Yes. Probably non-ideal. Now changed to user "user". [3] Thanks for
mentioning!

>> - power-savings-disable-in-vms
>
> I've no idea where exactly, but this one would be worth
> upstreaming somehow.


It's also quite a simple package. What about just a separate package
power-savings-disable-in-vms as is? Would be a good start?

>> - pkg-manager-longer-timeouts
>
> I'm curious, as I've never seen this needed in Tails. Did you see it
> happen on Whonix?


Yes. (I would speculate, that updating and installing packages is
something that Whonix users are more likely to do than Tails users.)

>> Since packages that contain only config files or worse, only a single
>> config file are not allowed, this will be much fewer.
>
> Indeed. I think a higher-level view is needed, to pack enough related
> stuff together in a way that makes sense for the Debian archive.


No idea. I think they don't like config file packages anyhow. And the
other packages are already standalone enough. Not sure.

Cheers,
Patrick

[1] https://www.ietf.org/rfc/rfc5905.txt
    Origin Timestamp (org): Time at the client when the request departed
for the server, in NTP timestamp format.
[2]
https://github.com/Whonix/bootclockrandomization/commit/fa7a507abc9afeb43a8613e9854ccf2fb5414b7e
[3]
https://github.com/Whonix/poweroff-passwordless/commit/519f779422db9f9cfd8890894df545184ad581ad
[4] https://github.com/Whonix/tcp-timestamps-disable#generic-packaging
[5]
https://github.com/Whonix/tcp-timestamps-disable/blob/master/debian/control#L19
[6]
https://github.com/Whonix/tcp-timestamps-disable/blob/master/debian/copyright#L23