Re: [Tails-dev] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls
On 2/12/16, intrigeri wrote: > Hi, > > Jurre van Bergen wrote (11 Feb 2016 16:46:47 GMT) : >> Forwarding e-mail. > > Thanks :) > >> Date:Thu, 11 Feb 2016 12:28:35 +0100 >> From:Cornelius Diekmann > >> A conservative change to the tails config would be to keep an RELATED >> rule but limit it to known good ICMP messages. > > Yes, this was proposed on the thread; in the email you're replying to > I explained why I didn't pick this option, mainly because no (pseudo-) > implementation thereof has been proposed nor discussed yet. I feel a bit sad to see this rehashed. Please just drop all packets on the floor? People who use Tails and expect it to keep them safely torified are likely still vulnerable to things we wrote in our paper (vpwned). Allowing users by default to make non-tor connections, except for specific pluggable transports or dhcp, will probably ensure that variations on the disclosed issues stay relevant. If a user wants to use a printer or touch the local subnet, why not make them jump through a (`sudo unsafe-network-unlock`) hoop? Why leave every other user vulnerable by default? All the best, Jacob ___ 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] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls
Jacob Appelbaum wrote (14 Feb 2016 13:04:58 GMT) : > I feel a bit sad to see this rehashed. Please just drop all packets on > the floor? > People who use Tails and expect it to keep them safely torified are > likely still vulnerable to things we wrote in our paper (vpwned). > Allowing users by default to make non-tor connections, except for > specific pluggable transports or dhcp, will probably ensure that > variations on the disclosed issues stay relevant. > If a user wants to use a printer or touch the local subnet, why not > make them jump through a (`sudo unsafe-network-unlock`) hoop? Why > leave every other user vulnerable by default? I think you're confusing this thread with another one, that is totally orthogonal as I see 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.
Re: [Tails-dev] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls
On 2/14/16, intrigeri wrote: > Jacob Appelbaum wrote (14 Feb 2016 13:04:58 GMT) : >> I feel a bit sad to see this rehashed. Please just drop all packets on >> the floor? > >> People who use Tails and expect it to keep them safely torified are >> likely still vulnerable to things we wrote in our paper (vpwned). >> Allowing users by default to make non-tor connections, except for >> specific pluggable transports or dhcp, will probably ensure that >> variations on the disclosed issues stay relevant. > >> If a user wants to use a printer or touch the local subnet, why not >> make them jump through a (`sudo unsafe-network-unlock`) hoop? Why >> leave every other user vulnerable by default? > > I think you're confusing this thread with another one, > that is totally orthogonal as I see it. > I was specifically replying to this bit: >> A conservative change to the tails config would be to keep an RELATED >> rule but limit it to known good ICMP messages. It seems odd to call that a conservative change, also. All the best, Jacob ___ 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] About the download and verification of test images
intrigeri: > sajolida wrote (13 Feb 2016 12:13:49 GMT) : >> Ok, see #7. Shall I write to phobos, weasel, someone else? > > https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure > says N/A in the Maintainers column ⇒ I would ask weasel (Cc Lunar, who > helps a bit on the rsync side IIRC). > > phobos has left the Tor project. Ok, so that's what I thought. I wrote them already. Then does it also make sense to explicitly not push RCs to the whole pool of mirrors? I understand that the work for us is to push them to the rsync server and that it's actually not more work for us to have them on all the mirrors. Still, it would be a small gain of disk space for these mirrors. But maybe it's not worth the trouble of adjusting our release process or the pool of mirror to handle these... >>> Minor implementation detail: last time I checked carefully, only one >>> of the two mirrors behind this hostname was serving our stuff, which >>> is why (last time I checked) only one of those was in our round-robin >>> pool of HTTP mirrors. If it's still the case, then we cannot do what >>> you propose. This situation may very well have changed, I dunno. > >> I'll check before writing to archive.torproject.org then. Now #11120. > > The title of that ticket doesn't reflect what I wrote above, so > I wonder if I conveyed what I meant clearly enough: it's not about > "how many servers are behind archive.torproject.org" (that is > trivially answered by a DNS query), but about whether all of them > _actually serve our stuff_. Sorry. I understood correctly and meant to do this but the title was clearly misleading. Fixed now and solved :) >>> sajolida wrote (13 Jan 2016 11:55:33 GMT) : Now I see that anonym reported #10915: "Consider publishing torrents for betas and RCs" which would work great to solve the basic download verification problem. I'm all for it. >>> >>> Indeed, this would be another way to improve security for the "set of >>> Tails users who know by heart how to install an ISO without any doc, >>> but don't know how to use the WoT, and are keen to try our test >>> images". And regardless, as we see on #10915 we have good reasons to >>> do so anyway. Let's do it. sajolida, will your team take it as part of >>> the question this thread is about, or shall we organize >>> things differently? > >> If I understand correctly, this would mean adjust the release process >> document to add instructions to create Torrents for release candidates >> as well, right? > > I would have said that it's about checking what needs to be done, > coordinating it and making it happen :) > > I've had a look to help with the 1st part. > > Our release process doc already makes us generate a Torrent and its > detached signature, even for RC:s (check for yourself: the "Generate > the OpenPGP signatures and Torrents" seems to have no condition > attached). It also makes us seed this Torrent unconditionally. Ack. > So what needs to be done is: > > * in the "Update the website and Git repository" section: don't skip >the Torrent publication steps when preparing a RC; also deal with >cleaning RC:s' Torrent files later; indeed anonym or I would be the >best placed to do that, although bertagaz should be able to do it too Ack → #11126. > * on our call for testing (non-existing yet) "template": link to the >Torrent, its signature, and the corresponding documentation; >I guess that you (sajolida) would be better placed to handle it. I created #9 for this and proposed a draft. We don't have templates (maybe we should) and are merely copying the previous one I think. ___ 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] Fallback download URL outside of DAVE [Was: Dynamically changing ISO URL in DAVE]
intrigeri: > [@u: I'd like to decide on a strategy by February 25, so if we decide > to go find a very specific kind of mirrors we have time to do this by > the end of March.] > > sajolida wrote (13 Feb 2016 12:49:46 GMT) : >> The only other issue I see that relates to my work on the assistant, is >> the fallback solution outside of DAVE so maybe that's off-topic here. > > Just a tiny bit :) Retitled this sub-thread accordingly. > >> From the blueprint I wonder whether it's really worth writing a version >> of the JavaScript that works outside of DAVE. > > Thanks for raising this topic! I was wondering too. > >> You're considering several >> cases outside of DAVE and BitTorrent: > >> A. Release candidates. We're discussing in another thread the >> possibility of only relying on archive.torproject.org >> for these. I think we need HTTPS there so your JavaScript >> outside of DAVE might not be enough to replace this here. > > Sounds like a pretty simple matter of programming to me. Our new > mirror pool design allows us to point to TLS-enabled (HTTPS) mirrors. > I guess it would be easy to give the JS function a boolean argument > that specifies whether non-TLS mirrors shall be used, and on calls for > testing we can use that to pick a mirror among the ones the > TLS-enabled ones only. Ok. > Also note that my secret plan is to leverage this new mirror pool > design to transition to TLS-enabled downloads only. With Let's Encrypt > around, plus us allowing mirrors to use whatever virtualhost name they > want, it looks like this could finally happen :) Very nice! >> B. People with no JavaScript, wget, etc. It seems like we need the >> minimal DNS pool if we want to support these anyway. > > Sure, we will need this pool anyway. > > But the less we rely on that DNS pool, the better: the less load we > put on it (i.e. the less users we send to it), the more reliable it > is, and the less daily maintenance effort is required. This is > especially true until we have recruited very fast and reliable mirrors > to put into this pool. > > Now, indeed it may be more worth our time to go after such new > mirrors, than writing code to workaround the lack thereof :) :) What would this be? A. Do stats on faster mirror as reported by check-mirrors. B. Do stats on mirrors with less incidents in the mirrors Git repo. or you are thinking about recruiting new mirrors we don't yet have in the pool? To do this I can dig check-mirrors reports from my trash (1069!) and compile some stats over the last two years. I guess that, as time goes by, we will still be able to silently modify the DNS pool for example to add fast and reliable mirrors from the JS pool or to remove flaky ones. But we should be able to do this very rarely compare to the maintenance work we do nowadays. >> C. Direct download link, as proposed on #11024. These people >> should anyway be able to do OpenPGP verification on their own so it >> won't be advertised very prominently and maybe the minimal DNS pool >> you are proposing for (B) could be reused here. Also, having a >> constant URL might be nice for these people to bookmark it for >> example. > > Right, and same answer as for B. > > Let's add to this: > > D. Users of web browsers that DAVE does not support > > ... which is similar to B and C the way I see it. and can't do BitTorrent, yes. These are badly treated as of now :( > So, all in all: I'm now tempted to invest time into looking for a few > very reliable and fast mirrors, and put aside the "dynamic mirror URL > picked with JS outside of DAVE" idea for now. We can always come back > to it, if the mirrors recruitment is not successful enough: we already > have code that basically does the job, so it shouldn't be a big deal > to switch back to this option at the last minute, if required. > > Thoughts, opinions? I'm fine with this. ___ 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] Mount VeraCrypt volumes
Dear Tails Developers, please have a look at attached message. Would you please include cryptsetup version 1.6.7 or above in the upcoming Tails to enable mounting of VeraCrypt volumes? Thank you so much for developing Tails! :) SecUpwN // The AIMSICD Privacy Project ANDROID APP: https://git.io/AIMSICD Original Message Subject: Re: Mount VeraCrypt volumes Local Time: February 14, 2016 6:43 pm UTC Time: February 14, 2016 6:43 PM From: tails-b...@boum.org To: secu...@protonmail.ch Hi, Sorry for the late reply. You should better get in touch with the dev team at tails-dev@boum.org for such feature request. Thanks. > please have a look at the following reply at > https://github.com/veracrypt/VeraCrypt/issues/42#issuecomment-180271421. In > short, the VeraCrypt developers would like you to update cryptsetup in Tails. > >> >It is better to ask them to include cryptsetup version 1.6.7 or above since >> >VeraCrypt support has been included since this version: >> >https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.7-ReleaseNotes > We'd be happy to see these things get adressed in the next Tails. > > Thank you and have a wonderful sunday!___ 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] Mount VeraCrypt volumes
On Sun, Feb 14, 2016 at 1:01 PM, SecUpwN wrote: > > Dear Tails Developers, > > please have a look at attached message. > > Would you please include cryptsetup version 1.6.7 or above in the upcoming > Tails to enable mounting of VeraCrypt volumes? > > Thank you so much for developing Tails! :) > > SecUpwN // The AIMSICD Privacy Project > ANDROID APP: https://git.io/AIMSICD > > > Original Message > Subject: Re: Mount VeraCrypt volumes > Local Time: February 14, 2016 6:43 pm > UTC Time: February 14, 2016 6:43 PM > From: tails-b...@boum.org > To: secu...@protonmail.ch > > > Hi, > > Sorry for the late reply. > > You should better get in touch with the dev team at tails-dev@boum.org > for such feature request. > > Thanks. > >> please have a look at the following reply at >> https://github.com/veracrypt/VeraCrypt/issues/42#issuecomment-180271421. In >> short, the VeraCrypt developers would like you to update cryptsetup in >> Tails. >> >>> >It is better to ask them to include cryptsetup version 1.6.7 or above >>> > since VeraCrypt support has been included since this version: >>> > https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.7-ReleaseNotes >> We'd be happy to see these things get adressed in the next Tails. >> >> Thank you and have a wonderful sunday! > > > > ___ > 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. I've updated https://labs.riseup.net/code/issues/8911 accordingly. I'll take a deeper look in the coming days. -- -Austin ___ 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] Tails contributors meeting: Thursday March 03
The next Tails contributors meeting is scheduled for: Thursday 03 March tails-dev on conference.riseup.net (XMPP) 9 pm in Paris 8 pm in London 3 pm in New-York 12 pm in San Francisco Everyone interested in contributing to Tails is welcome! Feel free to propose and prepare discussion topics. Either: - Raise them in this thread so that others can ask details and prepare the discussion too. - Update the blueprint of the agenda: https://tails.boum.org/blueprint/monthly_meeting/ - Make sure that the discussion tickets that you want to treat during the meeting are well detailed on Redmine. If you want to get involved but don't know yet how, please introduce yourself during the meeting, and be sure to tell us what you are interested in. The meeting might not be the most adequate time and place to properly introduce newcomers to the development process, but at least it should be a fine place to know each others, and schedule a better suited event. ___ 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.
