Re: [Tails-dev] Allowing all people with Redmine "Contributor" status to edit ticket description?
Hi, > Is it fine with you folks if I give the right to these people to edit > ticket descriptions? I'll go ahead in a few days unless there > are objections. I agree. People who have the Contributor status currently have somehow requested it or entered in contact with us, so I'm fine with this. Cheers! ___ 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] Physical Ethernet Adapter
Hi, Spencer wrote (09 Feb 2016 18:21:15 GMT) : > Trying to use ethernet adapter on device with no ethernet port. > Ethernet is supported on 2.0, it seems, with a device that has an ethernet > port. > Ethernet adapter is for linux kernel. > Tried, what I understood, from #10522 and #9012 but didn't get very far. I'm sorry but there's nothing we can do with this little info. Please send a complete bug report, that should include all the info our frontdesk people will need to help you debug the problem: https://tails.boum.org/doc/first_steps/bug_reporting/ Note that this mailing-list is not suitable for usage questions. 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.
Re: [Tails-dev] #10972 Port tails to arm platforms
Hi, Tails wrote (31 Jan 2016 17:59:43 GMT) : >>> > But isn't there a tails test repro, where I can upload arm packages to >>> > test? I'm sorry, I think I don't understand what you mean to test, exactly. >>> > BUT isn't there anybody who has a more pwoerfull test environment? >> I could provide you with a Debian VM if you want! > Thanks & good to know, could be a way if I don't find a suitable "place" > ... anyhow if possible I would prefer an environment I can access > physically. It's not built/made up over night. What do you want to do with this "test environment"? How should it be specified? 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.
Re: [Tails-dev] Static Tor guards across restarts of Tails
Hi, sajolida wrote (13 Jan 2016 11:38:11 GMT) : > Jesse V: > Hi Jesse, thanks for brainstorming on this. Yay, thanks a lot! >> However, what if Tails prompted the user for a passphase or a series of >> words that was then used to select the Tor guards? If the user types in >> a string X, then we can seed a PRNG with the hash of X, then use the >> PRNG to select a set of Tor guard nodes. It's probably possible to >> define the guards by communicating with Tor's control port, or you could >> also write them directly into Tor's state file before starting Tor. >> >> For example, if the user types in "correct horse battery staple", >> then we can run this through SHA-256, producing >> 73fe04e5a7a16dbe16492a8773036db1646d87e22337b1c64aae0afab788b626 >> This hash then initializes the Mersenne Twister PRNG, which then >> scrambles the list of Tor relays with the Guard flag. The first three >> nodes are then written for Tor to use. I'm sure there's a way to weigh >> the selection by consensus weight in the normal Tor fashion, but this >> should basically work. >> >> I think it's important that a hash is used in order to mask any >> identifiable words that are in the initial seed. It also has the >> advantage of avoiding some of the (potential) problems with certain >> seeds of Mersenne Twister, so I think this is a good idea in general. >> >> What do you guys think? Has this been proposed before? > This looks like what has been considered in the second bullet point of > "Discarded ideas" on this blueprint. Note that if I understand the > blueprint correctly, it has been "discarded" as a good option for the > entropy pool but not for the persistent Tor state. Well, no, this is not what we meant on the blueprint. Let me explain. What has been discarded is "requesting user input once, both to parameterize Entry Guard selection, and for seeding the entropy pool". The key word here is "both", as explained later in this bullet point. However, we did not reject the idea of making Entry Guard selction a function of some user input, quite the contrary: the "Third iteration (low-priority)" section has provision to do so, "for people who don't use persistence". As stated on the blueprint, this idea is an early draft. It may be flawed or suboptimal, and Jesse V's idea might be very useful to improve this 3rd iteration of our plan. I'm very happy if people work on refining this 3rd iteration. Personally, I'll try to focus on getting the 1st and 2nd iterations implemented before I dive too deeply into the 3rd one. Jesse: you might be interested in reading the criticism that Patrick Schleizer posted on this list, about our proposal for the 1st iteration, though. I would love to get some help on this! The corresponding thread is "Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)". I haven't had time to put much thought into it lately, and it seems that Patrick has a) one major concern about us OS integrators tweaking the Entry Guard selection _at all_, that I happen to disagree with; b) at least one possible attack scenario that is worth analyzing to see if/how it affects our proposed design. I won't elaborate more here, since we have an ongoing dedicated thread on this topic :) > So, maybe you're option would be good as a fallback for when there is no > persistent storage. This looks like what I'm pointing to above :) 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.
Re: [Tails-dev] vpwned + greeter
Jurre van Bergen wrote (11 Feb 2016 00:20:58 GMT) : > On 02/11/2016 12:06 AM, intrigeri wrote: >> Anyone wants to try out Subgraph Application Firewall (fw-daemon) in >> the context of Tails? > Let's see if I can do something here. I'll document a long the way. Woohoo! I suggest starting with a very rough approach (instructions to set it up manually from inside a running Tails), to evaluate how hard it could be to use the thing in our context. I guess you'll need to enable the GNOME Shell extension to make it work. Then someone more at ease with Tails source tree can look into integration, packaging, etc. further down the road, or help you do it. 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] Allowing all people with Redmine "Contributor" status to edit ticket description?
Hi, currently, most of us have the "Contributor" role in Redmine, and have thus fairly limited credentials. E.g. until a few days ago they could not add watchers, and they still cannot edit a ticket's description. Note that the power associated with a given Redmine user role are global on this Redmine instance, and thus shared with other projects, so we can't just take over what "Contributor" means. I will then create a new user role called "TailsContributor", based on the "Contributor" one, that will give us more flexibility to give more permissions to our contributors, as we wish. Is it fine with you folks if I give the right to these people to edit ticket descriptions? I'll go ahead in a few days unless there are objections. 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] Check out Zello
It's a free push-to-talk app and I'd like to try it with you. My Zello username is fohad...@gmail.com. Click http://i.zello.com/ICBIGG to accept my invitation. ___ 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] Check out Zello
It's a free push-to-talk app and I'd like to try it with you. My Zello username is fohad...@gmail.com. Click http://i.zello.com/DGUTOP to accept my invitation. Sent from my symphony___ 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] Hacking Team looking at Tails
Hi, intrigeri wrote (13 Jul 2015 08:24:36 GMT) : >> o Infecting USB device which appears to be a bootable disk (Antonio + >> Giovanni)§ It will drop (release) the scout, then it will run >> a wipe. > Seems to be the same, but from a running and already infected > non-Tails OS, when a Tails USB stick is plugged in it. That's more > concerning. We should check if we're communicating clearly enough > that: > * the OS used to install or upgrade a Tails device can corrupt it > * plugging one's Tails device in an untrusted OS is dangerous I don't think this has been checked. This thread teaches us that such targetted attacks against Tails are not theoretical, so I think we should warn our users against it ⇒ I've created https://labs.riseup.net/code/issues/11102 so it's tracked somewhat better than in our inboxes. 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.
Re: [Tails-dev] vpwned + greeter
On 02/11/2016 12:06 AM, intrigeri wrote: > Anyone wants to try out Subgraph Application Firewall (fw-daemon) in > the context of Tails? Let's see if I can do something here. I'll document a long the way. Best, Jurre ___ 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] vpwned + greeter
Hi, [given this is an old thread, I'll be quoting more widely than usual.] anonym wrote (02 Dec 2014 13:10:53 GMT) : > I think there arguments both for and against allowing post-session > security decisions (and I'm trying to be a bit more general here): > * Pro 1: if people are frequently frustrated by some security decision, > they will train a tendency to always pick the less secure option without > thinking. Having to reboot to redo the decision is frustrating. Allowing > it to happen during the session removes that frustration, and may make > the user more happy to pick the default, more secure option. > * Pro 2: with post-session decisions, the insecure option can be enabled > temporarily, only when needed, reducing the duration of exposure. At > least it is much less frustrating compared to yet another reboot. (This > doesn't make sense in some cases, like compromised hardware with DMA > access, which presumably would run it's attack immediately.) > * Con 1: if the Live user account is compromised during the session, the > attacker can make these decisions, potentially deepening the compromise > further. > * Con 2: at least some things are much harder to implement in such a > dynamic way (allowing/disallowing LAN ports is easy, though). I'm curious how it is "easy" to implement this with good UX. > I'm sure there are more pros and cons, and I think we need to identify > these and weigh them against each other. As for the feature in question, > I think "Pro 1" and "Pro 2" are individually stronger than "Con 1", and > "Con 2" doesn't even apply. It seems to me this call for something like https://github.com/subgraph/fw-daemon ... that now has some Debian packaging: https://github.com/subgraph/fw-daemon/tree/debian See https://mailman.boum.org/pipermail/tails-dev/2015-December/009959.html for more pointers on this topic. I wonder if we should go directly this way, or if it's still worth getting ourselves safer (but static) defaults, as suggested a year ago: https://mailman.boum.org/pipermail/tails-dev/2015-January/007820.html + the Gobby idea: https://mailman.boum.org/pipermail/tails-dev/2015-January/007824.html (the captive portal idea from this last mail makes me think we should simply give the Unsafe Browser full access to the LAN) Anyone wants to try out Subgraph Application Firewall (fw-daemon) in the context of Tails? 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.
Re: [Tails-dev] Reducing attack surface of kernel and tightening firewall/sysctls
Hi,
intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>> I see this thread has been quiet for a bit more than a month.
>> Maybe it's time for someone to sum up whatever consensus was reached,
>> and whatever disagreement may still be remaining?
>> Jake, maybe?
> Ping?
OK, OK, here we go :)
Thank you all for your contribution!
I have compiled everything that everybody seemed to agree in this
thread, into a Git branch (feature/various-firewall-hardening).
I'll build it and run our automated test suite on it.
There's one question below, mainly for Oliver-Tobias, but anyone else
is free to have a look.
Anyone who participated in this thread, please consider checking my
summary below. This is _not_ my area of expertise, and it may very
well be that I got something wrong from your discussion, which is why
I was asking for someone else to sum it up a year ago.
Thanks in advance!
Note that all patches pasted below are entirely untested.
Regarding the firewall rules, I think the agreement that was reached
is:
--- a/config/chroot_local-includes/etc/ferm/ferm.conf
+++ b/config/chroot_local-includes/etc/ferm/ferm.conf
@@ -15,7 +15,7 @@ domain ip {
policy DROP;
# Established incoming connections are accepted.
-mod state state (RELATED ESTABLISHED) ACCEPT;
+mod state state (ESTABLISHED) ACCEPT;
# Traffic on the loopback interface is accepted.
interface lo ACCEPT;
@@ -25,7 +25,7 @@ domain ip {
policy DROP;
# Established outgoing connections are accepted.
-mod state state (RELATED ESTABLISHED) ACCEPT;
+mod state state (ESTABLISHED) ACCEPT;
# White-list access to local resources
outerface lo {
So far, so good. Except one problem was raised about this change, i.e.
the potential for breaking stuff if a link along the way has a small
MTU. On this we have two messages from Oliver-Tobias:
Oliver-Tobias Ripka wrote (04 Dec 2014 01:06:11 GMT):
> there are some cases where TCP also depends on
> ICMP. What comes to mind is PATH MTU discovery. As TCP always has the DF
> bit set it, packets might get rejected by routers on the path that only
> allow for a small MTU. This results in an ICMP destination
> unreachable/fragmentation needed(DU/FN) message that has the "next hop mtu"
> value set.
> [...]
> The bottom line is that we should test if this theory above actually
> results in problems when sending large packets in these circumstances.
> Possible solutions would be to tweak the sysctls to allow the Kernel to
> determine an efficient MTU via black hole router detection and MTU
> probing.
If I understand correctly this means settig net.ipv4.tcp_mtu_probing=1.
Right?
I've tested this 9 months ago and at least it didn't break our
automated tests (https://labs.riseup.net/code/issues/9268#note-10).
> Another solution would be to explicitly allow this specific
> type of ICMP packet from the outside.
I'll go with the 1st solution for now, since if I got it right what
you meant, I have put time into understanding it meanwhile, and have
an implementation ready and tested. As opposed to this 2nd option,
which has no code yet, let alone tested code :)
> Maybe this may also be considered not to be an issue because small MTUs
> are not so common (mostly only if you are somewhere behind a Tunnel,
> VPN, 6in4,4in6...).
Oliver-Tobias Ripka wrote (09 Dec 2014 22:40:32 GMT):
> For the potential PATH MTU problem I saw Tor using fixed sizes segments
> that are quite small (about 500bytes). Thus PATH MTU should not be a
> problem besides extreme cases of network misconfiguration.
> Actually it might be a good idea to block these messages because if the
> network stack reacted to these ICMP messages it might allow a remote
> attacker to artificially lower the MTU of the segments sent. This may
> potentially make it easier to deanonymize a Tor user, I guess. Not sure
> if Tor can protect against this kind of attack as this may happen on
> the Kernel layer.
> You asked how to test it. Well I currently don't have a real router
> which I can configure to provide such a low MTU. But using software
> tools it is possible to simulate this: 1. route Tails through a Linux box
> with low MTU on the WAN interface. (Linux should send ICMP DF) 2. route
> Tails through Linux box with iptables rule dropping large packets and
> scapy script sniffing an sending ICMP DF for each large packet.
Note that we had a discussion about MTU earlier, that suggested that
current Tails might not be supporting low MTU already:
https://labs.riseup.net/code/issues/9268.
So my take on this is that we should not bother too much about low
MTU, that seem uncommon and possibly already broken; and still, enable
MTU probing (Packetization Layer Path MTU Discovery, RFC 4821) as done
in our bugfix/9268-deal-with-smaller-MTU branch, in case it may help.
IMO this should
Re: [Tails-dev] minimalist/anonymity-preserving DHCP clients
Hi, Jake, Daniel: any status update on this front? Re-reading this sub-thread while killing some old email backlog made me curious! 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] Physical Ethernet Adapter
Hi, > > intrigeri: > I'm sorry but there's nothing we can do > with this little info. > Word. > > bug report > No need (: > > usage questions. > It's a development question. I figured there was documentation; searched crickets. My apologies. Wordlife, Spencer ___ 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.
