Re: [Tails-dev] OpenSSL exploit fixed in TAILS 1.1?
Hi, plasticpic...@safe-mail.net wrote (27 Jul 2014 22:33:27 GMT) : > What version does TAILS 1.1 use? 1.0.1e-2+deb7u11 Feel free to run `dpkg -s openssl' yourself next time :) And then: https://security-tracker.debian.org/tracker/source-package/openssl 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.
[Tails-dev] OpenSSL exploit fixed in TAILS 1.1?
Did you upgrade OpenSSL yet? According to this[2], there's an exploit[1] against the version included with TAILS 1.0.1. What version does TAILS 1.1 use? [1] version 0.9.8o-4squeeze15 [2] https://www.openssl.org/news/secadv_20140605.txt ___ 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] What to do about I2P in Tails?
Hi, Jacob wrote: > I disagree in practice - if someone can pop a shell as the Amnesia > user, they can jump to the i2psvc by using the sudo rule and then > attacking I2P. That concern seems to point toward a different > solution. Furthermore, it suggests that an actual I2P user should not > be so easy to deanonymize. That won't come from the firewall > protection, I guess. If someone can run code as the 'amnesia' user your are lost anyway because he then controls input/output and therefore can do anything the real user can do. HW42 signature.asc Description: PGP 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] What to do about I2P in Tails?
Hi, First, thanks to everybody that worked on that i2p security issue. > * if I2P folks or anyone are ready to put quite some energy into > implementing a good security design for I2P-in-Tails, say, in time > for Tails 1.2, then it would be sad to drop I2P entirely for Tails > 1.1.1. We could change things so that I2P is functional only if > some option is passed on the kernel command-line; most potential > deeper counter-measures would probably be too invasive for > a point-release, but perhaps a few baby-steps can be walked in > time for the freeze (August 12); > > * otherwise, then I think we should seriously consider applying your > patch that entirely removes I2P. > I agree with that proposal. 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] [review'n'merge:1.1.1] bugfix/7618-gnome-help
On Sun, 27 Jul 2014 18:57:19 +0200 intrigeri wrote: > bugfix/7618-gnome-help fixes #7618 by installing gnome-user-guide. > That's a regression against Tails/Squeeze, so candidate for 1.1.1 > => please review'n'merge into stable and devel. > I'm taking it. ___ 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] [review'n'merge:1.1.1] feature/torbutton-1.6.11.1 (#7662, #6377)
Hi, > 1. anyone else could give this stuff a try; merged into experimental, > so *future* autobuilt ISO from that branch should have it: > http://nightly.tails.boum.org/build_Tails_ISO_experimental/ > I just triggered a Jenkins build, so a new ISO should be available > in ~25 minutes there. > > 2. Alan, bertagaz or sajolida could do the review'n'merge. > > Thanks in advance! > I'm taking it. ___ 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] [review'n'merge:1.1.1] bugfix/7636-printers-configuration
> bugfix/7636-printers-configuration fixes #7636 by installing the > missing cups-pk-helper package. Regression against Tails/Squeeze > => candidate for 1.1.1. Please merge into stable and devel. > As usual, details can be found on the ticket. > > (yeah, so much for disabling APT recommends etc..) > I'm taking it. ___ 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] What to do about I2P in Tails?
Hi, Jacob Appelbaum wrote (27 Jul 2014 14:33:38 GMT) : > On 7/27/14, Kill Your TV wrote: >> 'router console access': How many on Tails on I2P just visit I2P >> internal sites? How many look at or change settings here? Should this be >> disabled by default? > Yes, please disable it, if that is possible. Or perhaps make a web > view or something similar with it? Just my 2 cents: the console is useful for learning when one I2P is ready to be used. I'm told one has to explain that on #tails often enough, so maybe removing the only possible way to know if one should wait more or what would increase user support load. >> greeter or boot option: Seems like a reasonable compromise. I suppose >> could also allow the "I2P-specific" rules to be set if-and-only-if this >> option is specified. I'm glad we agree on this. 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] What to do about I2P in Tails?
On Sun, 27 Jul 2014 10:02:18 + (UTC) intrigeri wrote: > Hi, > > > On 7/26/14, sajol...@pimienta.org wrote: > >> Regarding the "when", if we decide to do a first temporary step by > >> having an "i2p" boot option instead of an option in the Greeter, > >> then we don't have to wait for the new Greeter... It feels a bit > >> like going backward regarding our plans on the Greeter but we've > >> been doing that for truecrypt forever and the doc is ready... > > Agreed, this looks like a good short-term plan, thanks! > > >> That could be ready for Tails 1.1.1, no? > > Yes. I think all it takes is adapting the doc + writing a live-config > hook that adds enable the needed credentials in sudoers, and makes the > I2P launcher visible. Anyone willing to give it a try? I'd be happy to > provide guidance and advice. Looking at config/chroot_local-includes/lib/live/config/2030-install-truecrypt it seems like it would be pretty easy to do. The question I'd have is, what would be an acceptable way to handling this? Without the boot parameter: - the wrapper (normally located at /usr/sbin/wrapper) could have some sort of _disabled suffix and it'd be stashed away, perhaps somewhere under /usr/share/amnesia with the permissions set to 000. - the 'start I2P' menu entry and associated scripts would be removed. - perhaps /usr/share/i2p would exist in a tarball somewhere under /usr/share/amnesia. With the boot parameter, all of this would be undone: - the menu entry would be re-added. - the java service wrapper would have the standard 755 permissions restored and it'd be moved into place - the tarball could be extracted to /usr/share/i2p and the start script would be put in place. Does any of this mesh with what you (collectively) had in mind? -- GPG ID: 0x5BF72F42D0952C5A Fingerprint: BD12 65FD 4954 C40A EBCB F5D7 5BF7 2F42 D095 2C5A signature.asc Description: PGP 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] What to do about I2P in Tails?
On Sun, 27 Jul 2014 14:33:45 + (UTC) Jacob Appelbaum wrote: > On 7/27/14, Kill Your TV wrote: > > On Fri, 25 Jul 2014 11:08:19 + (UTC) > > intrigeri wrote: > > > >> Note: what follows is *not* about finding a solution to the last > >> de-anonymization vulnerability found in I2P 0.9.13. I trust the I2P > >> team will do a proper job at it. > > > > A new release is out that resolves this recent XSS and a few other > > issues, but it has had very, very little testing. Perhaps there are > > other problems lurking which haven't been reported yet; people are > > certainly giving I2P more attention *now*. > > Is it possible to disable the I2P console entirely until it has been > audited? Yes, this is very easy to do. > > (Exodus reported *multiple* > > 0days incl RCE affecting Tails. See also > > http://www.twitlonger.com/show/n_1s2jibg. Are these others in I2P? > > Tor? Something else? Will these other 0 days be disclosed or are > > they to be sold?) > > > > I have a similar concern. I think that this suggests that we need to > get our act together and audit audit audit. We should also work to > mitigate these kinds of bugs - assuming that we've missed something as > we have probably missed something. :( I agree wholeheartedly. > > WRT to the last I2P release: I do know that the filtering is a > > little too strict and broke retrieving torrent metainfo, so I think > > that there will be a point release relatively soon (Perhaps the > > I2P-users on Tails don't bother with this feature?). > > Will the Debian packages be updated sometime soon? I (occasionally) cherry-pick what I think are important but very low-risk fixes for the debs. If the router console is disabled within Tails then the problem I mentioned here would not be applicable. I think that any potential I2P point release would solely address functionality or security of the console itself. Thus far, I've only found breakage in the I2P-contained torrent client; on the bright side, it shows the filtering is working. The point release for any problems caused by overly strict XSS filtering--or any other problems reported--is planned to be done by Aug 11 or thereabouts. > > I still haven't had a chance to play 'catch-up' with the posts, > > Redmine, and/or IRC to give the level of detail that they deserve, > > but a few quick things: > > > > apparmor: This was in my plans prior to this bug but of course its > > priority has been raised. > > Wouldn't any policy that blocks the latest RCE also block the way that > I2P actually functions? I need to familiarize myself with how apparmor works before I can make an informed comment on this. > > 'router console access': How many on Tails on I2P just visit I2P > > internal sites? How many look at or change settings here? Should > > this be disabled by default? > > Yes, please disable it, if that is possible. Or perhaps make a web > view or something similar with it? Instead of opening the 'console' perhaps an informative static HTML page could be opened instead? Perhaps with the same "in console" information but without the ability to edit any settings. Anyone that wants to do anything fancier would be able to use the administrative password and edit the configs to manually enable it. The actual disabling of the console's starting is straight-forward. > > greeter or boot option: Seems like a reasonable compromise. I > > suppose could also allow the "I2P-specific" rules to be set > > if-and-only-if this option is specified. > > I think it would be good to privilege separate administration of I2P > (eg: console) from usage of I2P (eg: touching the network). > > > > > More will be forthcoming. > > Sounds good. I look forward to hearing more and I'm happy to help. > What do you think about routing all I2P traffic over Tor? That seems > like something that may happen as a stop gap. Thoughts on that are > really needed. It'll "work". Liberté was shipping with I2P routed over Tor. Whonix recommends that users wishing to run I2P install it on the workstation, effectively routing everything over Tor. I don't know what the impact on the network (=I2P & Tor) would be. Speculating, I'm not sure that it'd be /that/ bad for I2P due to I2P on Tails being configured to run in "hidden mode" (outside of I2P lingo, this essentially means that the router address isn't published I2P's netdb). I do not have any further insight on the topic of I2P-over-Tor at this time. I'll have to come back to this. -- GPG ID: 0x5BF72F42D0952C5A Fingerprint: BD12 65FD 4954 C40A EBCB F5D7 5BF7 2F42 D095 2C5A signature.asc Description: PGP 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] Replacing TrueCrypt with cryptsetup 1.6 + documentation?
Hi, > > I'd rather do it faster, since we've been announcing it for a year, > > but I can live with your proposed timing too. > > Other thoughts, feelings, opinions? > I probably do it faster, but the proposed timing doesn't seem me bad either. As/if the people taking care of user support think it's better I would listen to them. 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.
[Tails-dev] [review'n'merge:1.1.1] bugfix/7636-printers-configuration
Hi, bugfix/7636-printers-configuration fixes #7636 by installing the missing cups-pk-helper package. Regression against Tails/Squeeze => candidate for 1.1.1. Please merge into stable and devel. As usual, details can be found on the ticket. (yeah, so much for disabling APT recommends etc..) 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] [review'n'merge:1.1.1] bugfix/7618-gnome-help
Hi, bugfix/7618-gnome-help fixes #7618 by installing gnome-user-guide. That's a regression against Tails/Squeeze, so candidate for 1.1.1 => please review'n'merge into stable and devel. 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] [review'n'merge:1.1.1] feature/torbutton-1.6.11.1 (#7662, #6377)
Hi,
the Torbutton update was unfortunately missed in the 1.1 dev cycle.
Time to fix this! Done in feature/torbutton-1.6.11.1. An ISO built
from this branch (+ feature/linux-3.14-2) passes all features in our
automated test suite and the bits of our manual test suite that are
about the browser. And, the good news is that it seems to fix #6377
("Web browser window size is not set to a multiple of 200x100"),
finally.
Again, anonym is not available for reviewing and merging before the
freeze, and I'd rather not merge my own stuff whenever possible, so it
would be good if:
1. anyone else could give this stuff a try; merged into experimental,
so *future* autobuilt ISO from that branch should have it:
http://nightly.tails.boum.org/build_Tails_ISO_experimental/
I just triggered a Jenkins build, so a new ISO should be available
in ~25 minutes there.
2. Alan, bertagaz or sajolida could do the review'n'merge.
Thanks in advance!
No commit on the branch, only Git changes are in our torbutton repo,
so the only merge needed is at the APT level. After merging, please
mark the two relevant tickets (see subject) as "Fix committed".
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] Risks of enabled/disabled TCP timestamps?
On 7/27/14, intrigeri wrote: > Hi, > > I was a bit sad that the TCP timestamps thing went nowhere, after the > energy we've put into discussing it, so I've built an ISO with the > corresponding branch merged in, and successfully run the automated > test suite on it. So, at least we now know it doesn't break too much > stuff in obvious ways. Good! Ok. Great! > > But that's not enough to merge this branch: > > intrigeri wrote (07 Jan 2014 23:12:31 GMT) : I'll come back to you and Jacob for the design doc phrasing, as I'm still not convinced we can put statements as bold as "tracking the clock down to the millisecond" in there, without thinking a bit about how an attacker is affected by the network lag between the time a TCP timestamp was created, and the time when they get to see the packet. > I mean, I'm weak at stats and all and you probably know better, but learning that "some unknown time ago, the system clock was T with a millisecond precision" does not really give me the current system clock with a millisecond precision, does it? > >>> This still needs some input. > >> Now known as #6581. > Ok. I'll comment on #6581 shortly. > This is still waiting for some input from those who are confident that > disabling TCP timestamps buys us much, and feel able to phrase it in > a way that's suitable for our design doc. Once we have that phrasing, > I volunteer to integrate it into the design doc and propose a branch. > > Any taker? Yes, I'm on it. 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] What to do about I2P in Tails?
On 7/27/14, Kill Your TV wrote: > On Fri, 25 Jul 2014 11:08:19 + (UTC) > intrigeri wrote: > >> Note: what follows is *not* about finding a solution to the last >> de-anonymization vulnerability found in I2P 0.9.13. I trust the I2P >> team will do a proper job at it. > > A new release is out that resolves this recent XSS and a few other > issues, but it has had very, very little testing. Perhaps there are > other problems lurking which haven't been reported yet; people are > certainly giving I2P more attention *now*. Is it possible to disable the I2P console entirely until it has been audited? > (Exodus reported *multiple* > 0days incl RCE affecting Tails. See also > http://www.twitlonger.com/show/n_1s2jibg. Are these others in I2P? Tor? > Something else? Will these other 0 days be disclosed or are they > to be sold?) > I have a similar concern. I think that this suggests that we need to get our act together and audit audit audit. We should also work to mitigate these kinds of bugs - assuming that we've missed something as we have probably missed something. :( > WRT to the last I2P release: I do know that the filtering is a little > too strict and broke retrieving torrent metainfo, so I think that there > will be a point release relatively soon (Perhaps the I2P-users on Tails > don't bother with this feature?). Will the Debian packages be updated sometime soon? > > I still haven't had a chance to play 'catch-up' with the posts, > Redmine, and/or IRC to give the level of detail that they deserve, > but a few quick things: > > apparmor: This was in my plans prior to this bug but of course its > priority has been raised. Wouldn't any policy that blocks the latest RCE also block the way that I2P actually functions? > > 'router console access': How many on Tails on I2P just visit I2P > internal sites? How many look at or change settings here? Should this be > disabled by default? Yes, please disable it, if that is possible. Or perhaps make a web view or something similar with it? > > greeter or boot option: Seems like a reasonable compromise. I suppose > could also allow the "I2P-specific" rules to be set if-and-only-if this > option is specified. I think it would be good to privilege separate administration of I2P (eg: console) from usage of I2P (eg: touching the network). > > More will be forthcoming. Sounds good. I look forward to hearing more and I'm happy to help. What do you think about routing all I2P traffic over Tor? That seems like something that may happen as a stop gap. Thoughts on that are really needed. 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] What to do about I2P in Tails?
On 7/27/14, intrigeri wrote: > Hi, > > [Re-adding Kill Your TV in the loop, again. kytv, you might want to go > read Jake's message in the list archive.] > > Jacob Appelbaum wrote (27 Jul 2014 02:13:43 GMT) : >> On 7/26/14, intrigeri wrote: >>> Jacob Appelbaum wrote (25 Jul 2014 11:56:05 GMT) : A compromose of i2p is game over on Tails from an anonymity perspective. >>> >>> This is not so obvious to me: I2P activity could possibly be >>> de-anonymized, without being trivially linkable to the torified >>> activity. > >> I think that seems incorrect. If a user visits a hostile web page >> served to a Tor exit... wouldn't they be able to tag that user? I >> think so. > > I'm sorry I don't get what you mean here. Could you please elaborate? I mean - if someone serves you an i2p site in an iframe over an evil exit, what happens? Is there any difference? Can you do something nasty to them? Can you correleate other streams/circuits in any way? I think the answer is no with total isolation in theory but in practice, I wonder if if this is correct? Can an attacker hold a socket open or do something tricky with i2p that would be hard to do with a normal browser? > >>> E.g. we could forbid I2P to talk to anything it should not talk to >>> (the Tor ports spring to mind, but obviously a whitelist approach >>> would be better; and BTW, symetrically, the debian-tor user should >>> only need to talk to the Internet, and to proxies on the LAN if >>> configured to use one). > >> I'm not sure that I understand the I2P protocol well enough to know >> how to define such a boundary. What should it talk to? What shouldn't >> it talk to? > > I think we could allow the i2psvc user to talk to any host on the > Internet, but *not* to local services (apart of those that it really > needs to talk to) nor to the LAN. > Ok. That sounds interesting! >> How shall we scope the audit? What do you have in mind? > > Everything that relies on privilege separation (see sudo > configuration) could be worth looking it. In particular, I'm thinking > of the incremental upgrades security design and implementation. > I'm happy to look at the sudo rules but I don't know very much about the incremental upgrades. If you want to talk about it, I'm certainly open to looking into it. The system is ready for i2p to run and as a result, it has a lot of permissive behavior that is not strictly required. >>> >>> I see the firewall rules that grant i2psvc full access to the network, >>> the FoxyProxy configuration, and the fact the amnesia user can talk to >>> I2P in many ways. Does "a lot of permissive behavior" include anything >>> else I've missed? >>> > >> I'm not sure? The sudo rules ( /etc/sudoers.d/zzz_i2p ) seem >> rather... excessive but perhaps that is what you meant about "the >> amnesia user can talk to I2P in many ways" - I'm not sure? > > No, I was only mentioning the firewall rules that allow the amnesia > user to talk to various local I2P services, and asking for what you > were meaning by "a lot of permissive behavior" exactly. Ah, OK. Understood. > > In passing, good news: if we go for "users have to opt-in for I2P in > the Greeter, or -- first step -- on the kernel command-line", then we > can drop this sudo rule entirely, and have I2P start automatically in > some other way, when opted-in for. > Sure. That sounds fine. Though when I2P does start - we'd isolate it with Tor? If so, I think this is a fine design but perhaps not the best thing for the I2P world. :( I would say that we should disable the i2p rules in the firewall unless a user positively affirms that they want to run i2p. As it stands now - there is a full user that is able to talk to the internet, regardless of the state of i2p. >>> >>> I'm not sure why escalating privileges to i2psvc would be any easier >>> than escalating to debian-tor (especially given the latter is running >>> stuff and talking to the network already anyway). Still, I agree this >>> would be a good security-in-depth mid-term goal. > >> What about the recent I2P bug? Seems much easier unless you've got >> some Tor 0day up your sleeve? :-) > > It seems we're not understanding each other on that one. Let me > clarify what I meant: > > If I2P is running, then yes, escalating to i2psvc may be easier than > escalating to debian-tor. But then, we do need these firewall rules, > so "disabling the i2psvc firewall rules unless a user positively > affirms that they want to run i2p" won't help in this case. Hrm. If I2P is running because the user launched it (eg: at the greeter), I agree. If I2P is running because of an attacker, I wouldn't agree. Then the firewall *would* help stop such an attack. It is reasonable defense in depth. > > If I2P is not running, then even bugs in I2P can't help escalating to > the i2psvc user, while bugs in a few areas can help escalate to > debian-tor. So, I'm not convinced that "disabling the i2psvc firewall > rules unless a us
Re: [Tails-dev] What to do about I2P in Tails?
On 7/27/14, intrigeri wrote: > Hi, > >> On 7/26/14, sajol...@pimienta.org wrote: >>> Regarding the "when", if we decide to do a first temporary step by >>> having an "i2p" boot option instead of an option in the Greeter, then we >>> don't have to wait for the new Greeter... It feels a bit like going >>> backward regarding our plans on the Greeter but we've been doing that >>> for truecrypt forever and the doc is ready... > > Agreed, this looks like a good short-term plan, thanks! > I think I've said it previously but I also agree. >>> That could be ready for Tails 1.1.1, no? > > Yes. I think all it takes is adapting the doc + writing a live-config > hook that adds enable the needed credentials in sudoers, and makes the > I2P launcher visible. Anyone willing to give it a try? I'd be happy to > provide guidance and advice. I'd be happy to test it, once I manage to get the ISO build working ( eg: #7661 ). > > Jacob Appelbaum wrote (27 Jul 2014 01:57:23 GMT) : >> I wonder though if that also means that the firewall would be locked >> down by default? > > I'm still not convince this buys us much (escalating privs to a user > that has no running service, in order to benefit from its special > firewall exceptions, doesn't seem so easy), *but*: if someone does the > additional work, and if the changes are not too risky and invasive for > a point-release, then it does seem possible, yes :) > If we remove the i2p sudo rule, I'd probably agree that it doesn't buy us too much. My concern is people jumping between users after the system is fully booted. 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] What to do about I2P in Tails?
On Fri, 25 Jul 2014 11:08:19 + (UTC) intrigeri wrote: > Note: what follows is *not* about finding a solution to the last > de-anonymization vulnerability found in I2P 0.9.13. I trust the I2P > team will do a proper job at it. A new release is out that resolves this recent XSS and a few other issues, but it has had very, very little testing. Perhaps there are other problems lurking which haven't been reported yet; people are certainly giving I2P more attention *now*. (Exodus reported *multiple* 0days incl RCE affecting Tails. See also http://www.twitlonger.com/show/n_1s2jibg. Are these others in I2P? Tor? Something else? Will these other 0 days be disclosed or are they to be sold?) WRT to the last I2P release: I do know that the filtering is a little too strict and broke retrieving torrent metainfo, so I think that there will be a point release relatively soon (Perhaps the I2P-users on Tails don't bother with this feature?). I still haven't had a chance to play 'catch-up' with the posts, Redmine, and/or IRC to give the level of detail that they deserve, but a few quick things: apparmor: This was in my plans prior to this bug but of course its priority has been raised. 'router console access': How many on Tails on I2P just visit I2P internal sites? How many look at or change settings here? Should this be disabled by default? greeter or boot option: Seems like a reasonable compromise. I suppose could also allow the "I2P-specific" rules to be set if-and-only-if this option is specified. More will be forthcoming. signature.asc Description: PGP 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] Risks of enabled/disabled TCP timestamps?
Hi, I was a bit sad that the TCP timestamps thing went nowhere, after the energy we've put into discussing it, so I've built an ISO with the corresponding branch merged in, and successfully run the automated test suite on it. So, at least we now know it doesn't break too much stuff in obvious ways. Good! But that's not enough to merge this branch: intrigeri wrote (07 Jan 2014 23:12:31 GMT) : >>> I'll come back to you and Jacob for the design doc phrasing, as I'm >>> still not convinced we can put statements as bold as "tracking the >>> clock down to the millisecond" in there, without thinking a bit about >>> how an attacker is affected by the network lag between the time a TCP >>> timestamp was created, and the time when they get to see the packet. >>> I mean, I'm weak at stats and all and you probably know better, but >>> learning that "some unknown time ago, the system clock was T with >>> a millisecond precision" does not really give me the current system >>> clock with a millisecond precision, does it? >> This still needs some input. > Now known as #6581. This is still waiting for some input from those who are confident that disabling TCP timestamps buys us much, and feel able to phrase it in a way that's suitable for our design doc. Once we have that phrasing, I volunteer to integrate it into the design doc and propose a branch. Any taker? 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] HTML5 + Canvas/font user tracing
Hi, Liste wrote (27 Jul 2014 11:27:36 GMT) : > There is a function in HTML to biuld bitmap images via HTML5 canvas element. > Every computer renders the images differently and this can use to define > an hash/id to deanonimize users. I believe this is addressed by the Tor Browser patches + Torbutton. Did you actually check that two different Tails sessions return identifying information? If yes, then can you reproduce this in the TBB? If yes again, then please report this to the Tor bug tracker, as that's not something we'll work on by ourselves. See also recent activity upstream on this front: * https://trac.torproject.org/projects/tor/ticket/11949 * https://trac.torproject.org/projects/tor/ticket/12682 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] What to do about I2P in Tails?
Hi, [Re-adding Kill Your TV in the loop, again. kytv, you might want to go read Jake's message in the list archive.] Jacob Appelbaum wrote (27 Jul 2014 02:13:43 GMT) : > On 7/26/14, intrigeri wrote: >> Jacob Appelbaum wrote (25 Jul 2014 11:56:05 GMT) : >>> A compromose of i2p is game over on Tails from an anonymity >>> perspective. >> >> This is not so obvious to me: I2P activity could possibly be >> de-anonymized, without being trivially linkable to the torified >> activity. > I think that seems incorrect. If a user visits a hostile web page > served to a Tor exit... wouldn't they be able to tag that user? I > think so. I'm sorry I don't get what you mean here. Could you please elaborate? >> E.g. we could forbid I2P to talk to anything it should not talk to >> (the Tor ports spring to mind, but obviously a whitelist approach >> would be better; and BTW, symetrically, the debian-tor user should >> only need to talk to the Internet, and to proxies on the LAN if >> configured to use one). > I'm not sure that I understand the I2P protocol well enough to know > how to define such a boundary. What should it talk to? What shouldn't > it talk to? I think we could allow the i2psvc user to talk to any host on the Internet, but *not* to local services (apart of those that it really needs to talk to) nor to the LAN. > How shall we scope the audit? What do you have in mind? Everything that relies on privilege separation (see sudo configuration) could be worth looking it. In particular, I'm thinking of the incremental upgrades security design and implementation. >>> The system is ready for i2p to run and >>> as a result, it has a lot of permissive behavior that is not strictly >>> required. >> >> I see the firewall rules that grant i2psvc full access to the network, >> the FoxyProxy configuration, and the fact the amnesia user can talk to >> I2P in many ways. Does "a lot of permissive behavior" include anything >> else I've missed? >> > I'm not sure? The sudo rules ( /etc/sudoers.d/zzz_i2p ) seem > rather... excessive but perhaps that is what you meant about "the > amnesia user can talk to I2P in many ways" - I'm not sure? No, I was only mentioning the firewall rules that allow the amnesia user to talk to various local I2P services, and asking for what you were meaning by "a lot of permissive behavior" exactly. In passing, good news: if we go for "users have to opt-in for I2P in the Greeter, or -- first step -- on the kernel command-line", then we can drop this sudo rule entirely, and have I2P start automatically in some other way, when opted-in for. >>> I would say that we should disable the i2p rules in the firewall >>> unless a user positively affirms that they want to run i2p. As it >>> stands now - there is a full user that is able to talk to the >>> internet, regardless of the state of i2p. >> >> I'm not sure why escalating privileges to i2psvc would be any easier >> than escalating to debian-tor (especially given the latter is running >> stuff and talking to the network already anyway). Still, I agree this >> would be a good security-in-depth mid-term goal. > What about the recent I2P bug? Seems much easier unless you've got > some Tor 0day up your sleeve? :-) It seems we're not understanding each other on that one. Let me clarify what I meant: If I2P is running, then yes, escalating to i2psvc may be easier than escalating to debian-tor. But then, we do need these firewall rules, so "disabling the i2psvc firewall rules unless a user positively affirms that they want to run i2p" won't help in this case. If I2P is not running, then even bugs in I2P can't help escalating to the i2psvc user, while bugs in a few areas can help escalate to debian-tor. So, I'm not convinced that "disabling the i2psvc firewall rules unless a user positively affirms that they want to run i2p" would help much here either. So, in both cases, I fail to see what this approach brings us in practice. I hope I was clearer. I'm not trying to convince you, but to try to make sure we're talking of the same thing, so that we can better understand each other :) But anyway, again: it seems to be a good security-in-depth mid-term goal, and I'd be happy to take good patches that implement it. >>> Code execution in i2p as detailed on the Exodus blog would not be >>> stopped by Torification of i2p. The impact of such a bug would not >>> be completely minimized either - arbitrary code on the system can >>> still read out unique identifiers. >> >> Sure. This is why I raised the sandboxing topic :) > Does I2P still function when sandboxed in a way that would have > stopped that RCE bug? I would not say "have stopped", but "have mitigated", and then my answer would be "yes, most likely" -- although I've never tried to write AppArmor confinement profiles for Java apps, so I might be wrong. Sandboxing can make it harder, for anyone who can exploit such an RCE bug, and is able to run whatever they want as the i2psvc user, to take advan
[Tails-dev] HTML5 + Canvas/font user tracing
There is a function in HTML to biuld bitmap images via HTML5 canvas element. Every computer renders the images differently and this can use to define an hash/id to deanonimize users. The AddThis advertising agency using this feature For example... in youporn! Some years ago... I was build a javascript that identificate via hash an user: Some characters are displayed into a SPAN element, coosing font-family, size and unicode charaters. It can deanonimize user. In a windows or linux machine you can get ad unique in Intenret and in Tor (the same id). A solution can be to change by a pixer (+1 or -1) the font kerning randomly. ___ 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] What to do about I2P in Tails?
Hi, > On 7/26/14, sajol...@pimienta.org wrote: >> Regarding the "when", if we decide to do a first temporary step by >> having an "i2p" boot option instead of an option in the Greeter, then we >> don't have to wait for the new Greeter... It feels a bit like going >> backward regarding our plans on the Greeter but we've been doing that >> for truecrypt forever and the doc is ready... Agreed, this looks like a good short-term plan, thanks! >> That could be ready for Tails 1.1.1, no? Yes. I think all it takes is adapting the doc + writing a live-config hook that adds enable the needed credentials in sudoers, and makes the I2P launcher visible. Anyone willing to give it a try? I'd be happy to provide guidance and advice. Jacob Appelbaum wrote (27 Jul 2014 01:57:23 GMT) : > I wonder though if that also means that the firewall would be locked > down by default? I'm still not convince this buys us much (escalating privs to a user that has no running service, in order to benefit from its special firewall exceptions, doesn't seem so easy), *but*: if someone does the additional work, and if the changes are not too risky and invasive for a point-release, then it does seem possible, yes :) 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] [review'n'merge:1.1] feature/vagrant-wheezy-basebox (#7133, #6736)
coderman wrote (27 Jul 2014 01:00:14 GMT) : > is there an anon account for the tails wiki? No, there isn't. We can't cope with the spam it would induce. > for ubuntu 14.04 all that was necessary was: > apt-get install virtualbox vagrant rake torsocks tor apt-cacher-ng > python-vm-builder ruby apache2 qemu-kvm virt-what lxc lxctl fakeroot > faketime zip unzip subversion python-pip git make lxc, python-pip, really? I don't think we use those, so I'm curious. 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.
