[Tails-dev] Detecting hidden partitions?
So, when it comes to detecting hidden partitions, is it as simple as doing $(fdisk -l | grep -i hidden)? I realize is a simple difference and has no real effect, but I'm not sure how to properly detect this 'feature'. Thanks, Austin signature.asc Description: OpenPGP digital 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] Tails on compromised hardware
Michael English: > We should add a warning about using different operating systems > alongside Tails. Rootkits can be embedded in the SPI flash by a > malicious operating system and persist across boots. Tails users should > have a dedicated Tails computer possibly with the hard drive removed to > limit persistent storage. Has someone checked the warning page recently? We worked on it 6 months ago, and it starts with "Tails does not protect against compromised hardware", then "Tails can be compromised if installed or plugged in untrusted systems" and "Tails does not protect against BIOS or firmware attacks". So I think you're all proposing to add things that are already there, no? https://tails.boum.org/doc/about/warning/index.en.html 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] Tails Hardware
Hey, Michael English wrote (11 Mar 2016 16:17:09 GMT) : > Instead of a list of all compatible systems which requires substantial > maintenance, we should document an ideal laptop configuration. We can > prove security benefits of Lenovo ThinkPad X200 laptops running > Libreboot with Intel ME disabled. I can provide more details later, but > first I would like to get your opinion on the general idea. I think I lack some background info to have an informed opinion, so: Who would be the target audience for such documentation / hardware? What steps has a non-technical user to go through in order to get a X200 with Libreboot and no Intel ME? 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] [RFC] Dropping requirement for OpenPGP communication with HTTP mirror operators?
intrigeri:
> We'll soon be in a position to add more servers to the pool of HTTP
> mirrors that server our ISO images and IUKs. Before I publish the
> corresponding call for help, and get in touch with operators of
> potential fast mirrors (#11079), I'd like to make sure we get the
> requirements right.
>
> So far, we (or was it perhaps just me?) have insisted on having a way
> to communicate using OpenPGP with each operator of a HTTP mirror in
> our pool. I'm starting to question this. [In case anyone here didn't
> get that memo: yes, it often takes me years to change my mind.]
>
> This requirement has one clear disadvantage: it excludes some fast
> mirrors, e.g. lots of those that are run in universities (I have to
> trust people who are more in touch with operators of such candidate
> mirrors, on this one, as I have personally no idea). Also, on our side
> it adds to the burden of maintaining our pool of mirrors: maintaining
> a keyring isn't easy, and it gets quite hard if one wants to try to do
> it seriously.
>
> We are in the process of dropping at least another requirement of ours
> (the need for a dedicated hostname) that might have been a blocker, so
> I think it's time to check our list of requirements.
>
> I think the main advantages of requiring OpenPGP -enabled
> communication with mirror operators are:
>
> * We can authenticate requests sent to us by mirror operators: e.g.
>"please remove my mirror from the pool", that could otherwise be
>used to degrade our pool of mirrors, just by spoofing the sender
>address.
>
>- Are we seriously checking the OpenPGP signature on such requests?
> I used to do it, and used to require a good trust path for key
> updates, but I am under the impression that this might all have
> been handled in a more flexible way recently. sajolida?
I'm definitely not. It's been a while since I gave up on bugging mirror
operators for their key if they don't provide me one themselves or ask
for a trust path on key updates. I gave up on this because I was never
really convinced that the advantages ("preventing artificial degradation
of the pool") outweighs the disadvantages (sending additional email just
for that, asking people to do obscure OpenPGP rituals that often fail,
dealing with mismatching key ids, do manual trust path verifications,
sending and monitoring Schleuder commands, raising the bar for new
mirrors, etc.).
>- Perhaps we would notice if too many mirrors were removed (this
> calls for a monitoring check, I guess), and perhaps mirror
> operators would notice if they don't get the traffic they expect?
> IOW, perhaps we have other ways to avoid such attacks from being
> effective enough to be attractive in the first place.
I saw the scenario "please remove my mirror from the pool" mentioned
several times in this thread and almost be the foundation of all this
and I don't think it. Until now we've been managing the pool manually
and we would have noticed and reacted if the pool was being seriously
degraded.
Also, this can be dealt with without OpenPGP signature: we can ask
operators to put a token file with some random number on their server
when requesting to be removed (as we've done some times I think). Having
a template answer for this would make it a breeze to enforce.
> * Mirror operators can authenticate instructions we send them, e.g.
>"please add this option to your nginx configuration". Without this,
>anyone can quite trivially DoS our pool of HTTP mirrors, until
>someone notices. The thing is, we have no idea if the operators of
>our mirrors check this, i.e. whether they would notice if some
>email apparently coming from us was not signed.
This is about *us* sending authenticated email and doesn't require
having the keys of the mirror operators. I'm all for continuing doing
this (supposing that this comes for free from Schleuder though I didn't
check).
___
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] [RFC] WhisperBack for frontdesk
intrigeri: > sajolida wrote (30 Nov 2015 17:56:42 GMT) : >> On our roadmap for 2016 we put some minor improvements to WhisperBack >> regarding languages (#9799) and OpenPGP keys (#9800). We started working >> on this with Alan [...] > > \o/ Thanks for answering my RFC :) >> [...] but I'm actually more interested in feedback from tails-dev regarding >> the privacy issues we're raising in the blueprint. > > Meta: I've found it hard to understand what is the actual set of > proposals, given vague phrasing such as "we could" and "we can > decide". So I've initially assumed the blueprint was the result of > a brainstorming session, rather than as a concrete proposal, and > started commented on what inspired me. And then, after spending > a while on it I realized that there actually was a concrete > proposal... at the end of the page :-( So, I've added a table of > contents to the page, in the hope it helps avoid anyone else facing > the same problem I did. Sorry for that. I used non-affirmative phrasing as we were of course not sure whether what we were writing was the proper solution. > Regarding languages: I wonder if the email Subject header is the best > way to convey the information you want to pass around. Let me > elaborate on another idea. If custom headers were used (say, > X-Tails-Report-Language and X-Tails-Languages-Understood-By-User), > then: Good idea! > * any proper email client can filter incoming reports just as well; It's possible in Thunderbird but a bit more complicated than the headers that are available by default. It will require a bit of documentation not nothing complicated. > * the privacy concern you raised for the "When answering the report" >case disappears (as long as Schleuder is not configured to let >these X-Tails-* headers through). That's a good idea! > The advantage is that the "not to flag in the email headers, the > language of reports that are sent along with an OpenPGP key" > workaround is not needed ⇒ better filtering of incoming reports, > simpler implementation in WhisperBack, and more consistent workflow > for frontdesk. > > The disadvantage is, of course, that any email in the thread after the > initial reply will lack these headers. So, depending on how email > filtering is done exactly, these threads may be broken (for example, > the initial report might be sent into some language-specific folder, > while the follow-ups won't be). I tried and couldn't find how to do this in Thunderbird. If a filter moves the first mail of a thread to a folder based on some headers, then I don't know how to get the next emails in the same thread moved to the same folder if they don't match the filter themselves. > I'm pretty sure that using more > powerful email filtering techniques than send-to-folder would solve > this problem. Are you referring to any specific technique that could be used in Tails by our current user support crew? > Anyway, I see that there are plans to move away from a pure > email -based workflow, to a proper request tracking system that shall > be chosen this year, so I'd like to avoid putting too much effort into > implementation details that are bound to a particular technical > solution, that may be obsolete in a year or so. So perhaps we should > discuss the problem at hand in more abstract terms than email headers. > Ideally such a request tracker will understand metadata encoded in the > (encrypted) email body, and be able to expose said metadata in a way > that's useful for frontdesk members. Sure. Then the limitations expressed above regarding Thunderbird for example could be obsolete in such a system. > Regarding the "OpenPGP checks" section: I think that looking up a key > on the keyserver network is not an easy problem. One issue is that it > adds quite some implementation complexity, and the history of > unaddressed privacy issues in WhisperBack does not make me wish to see > it grow bigger than needed. Thanks for sharing your concerns. I didn't had them in mind. > But even ignoring that, as I see it: > > a) either the user is reporting a bug from a system wher they use >OpenPGP => their key is in the local keyring, no need to look it >up; Sure. That's case "1) Look for a key in the keyring of the user". > b) or, the user is reporting a bug from a system where they don't use >OpenPGP, but they have an OpenPGP key on another system => how do >we make sure they properly validate the key found on the >keyservers? The problem you are raising here is valid but note that it's already the case currently as we ask them for "a key ID, a link to your key, or the key as a public key block" with no guarantee that they are in possession of the corresponding private key material. And this was not stated as a goal in our RFC nor in the request from frontdesk (maybe it should). The objective here is to make the work of frontdesk easier, without lowering the security level. >Even assuming they have a
[Tails-dev] Tails on compromised hardware
We should add a warning about using different operating systems alongside Tails. Rootkits can be embedded in the SPI flash by a malicious operating system and persist across boots. Tails users should have a dedicated Tails computer possibly with the hard drive removed to limit persistent storage. ___ 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 on compromised hardware
In https://github.com/rootkovska/x86_harmful/blob/master/x86_harmful.md Joanna Rutkowska remarked that: > Tails has long been (falsely) advertised as being capable of > providing security even on a previously compromised laptop^[E.g. a > laptop which used to run e.g. Windows OS that got subsequently > compromised.], as long as the adversary has not been allowed to > tamper with the hardware ... Tails still has a remark like this in the Warning page: https://tails.boum.org/doc/about/warning/index.en.html#index1h1 > If the computer has been compromised by someone having physical > access to it and who installed untrusted pieces of hardware (like a > keylogger), then it might be unsafe to use Tails. I am not sure how best to phrase this, but would suggest the following patch: --- a/wiki/src/doc/about/warning.mdwn +++ b/wiki/src/doc/about/warning.mdwn @@ -13,9 +13,10 @@ make a good use of it. Tails does not protect against compromised hardware === -If the computer has been compromised by someone having physical access -to it and who installed untrusted pieces of hardware (like a -keylogger), then it might be unsafe to use Tails. +If the computer has been compromised by someone who installed +untrusted pieces of hardware (like a keylogger), or was able to +compromise low-level firmware or the BIOS, then it might be unsafe +to use Tails. 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] meeting notes
segfault: > emmapeel: >> emmapeel: >>> here you go! >>> >>> please add things you find missing... >> >> maybe i was not clear enough on the subject... please review the >> attachment and merge or correct... > > I corrected the part about the pinentry decision. To Emma: 1. Your patch has trailing whitespaces which raised warning when applying. Please activate Git colors on your setup to prevent this in the future. 2. Your markdown was broken in many ways. Did you build the page to check the formatting? 3. I removed some lines from ticketbot. To segfault: Your modified version of the patch was broken because you removed more lines than it had originally. But I merged it, fixed it, and it's live! Thanks! https://tails.boum.org/contribute/meetings/201603/ ___ 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] 2.2 tails-signing-key differs from version before
Dear Tails-Developers, I use tails since version 1.8 and I repeatedly downloaded the tails-signing-key for verification. Now I recognized that the tails-signing-key with version 2.2 differs from all the keys I download before. The 2.2 key seems to be much bigger (about 221kB). As I did not find any remark about that within the 2.2 release notes I just want to let you know about that. Don't know if this is important. Greetings and many thanks for your work ehbe ___ 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.
