19/06/14 18:33, intrigeri wrote:
> anonym wrote (19 Jun 2014 14:11:48 GMT) :
>>> commit b7f5054339ead7257eb49b973f24679534b3cf9f
>
>> Just a comment: This will not work with Tails <1.1 fed to --old-iso
>> since the test suite has been updated for Wheezy...
>
> Right. I was aware of it, but I wanted to start with adding a check
> (untested yet) that ensures we don't see regressions on that front in
> the future. Anyway, that's merely an additional test, that should
> (hopefully) not break anything else. Good enough?
Yes, I just wanted to make that clear.
>> This seems safer and quite simple, even though the duplication (syslinux
>> both inside the squashfs and on the image's root fs) is a bit unfortunate.
>
>> In the future we could avoid that and use the in-squashfs syslinux
>> binary without root privileges by employing stuff like fuseiso (in
>> Debian), squashfuse [0] (not in Debian, but see [1]), and fakechroot (in
>> Debian) instead of a real chroot for running the syslinux binary.
>
>> Beyond eliminating the duplication of syslinux, we'd get the "mechanism
>> to run post-upgrade scripts" you mention in comment 4 of #7345 [2],
>> which may come in handy in the future.
>
> It certainly would be interesting to look deeper into this some day.
https://labs.riseup.net/code/issues/7422
>>> I'll also have to test all other installation and upgrade scenarios,
>>> to make sure I didn't break anything else.
>
>> If you would enumerate these I can perhaps help a bit on Sunday,
>> depending on how much other review work there's for me then.
>
> I want to test clone'n'upgrade, clone'n'install, and a "real" IUK
> upgrade. All these from 1.1~betaN and 1.0.1 + the new liveusb-creator.
> Help is warmly welcome.
I'll see what I can do on Sunday.
> I'd like to also add to the design document a minimal discussion of
> the security impact of these changes: basically, anyone who can feed
> an arbitrary IUK can run arbitrary code as the tails-install-iuk user
> (we don't care, the same adversary can plant a persistent rootkit
> anyway, but then it made me think and file #7410, that I'd like to fix
> at the same time); and anyone who can feed an arbitrary ISO into
> liveusb-creator can run arbitrary code as the user running
> liveusb-creator (no big deal either). In both cases, no big deal, but
> I'd like to document *why* it's no big deal, so that it's easier for
> others to review my reasoning.
Indeed, please do this.
>> I'm confused. Isn't the purpose of this bugfix branch to allow the 1.0.1
>> -> 1.1 upgrade using "Upgrade from ISO" (even if it requires some
>> additional steps *this* time)? If so I definitely think we should
>> instruct users to upgrade liveusb-creator. Or do you just want to have a
>> fix for when this happens next time?
>
> My intent was to fix for real the underlying, deeper problem that
> causes #7345. I wanted to investigate the feasability of this
> solution. Now it seems to be proven, so we can actually discuss
> whether we want to suggest anyone to use this solution *this* time, or
> just merge, add to known issues in the 1.1 release notes, and be happy
> that the problem won't show up anymore. Cc'ing sajolida to get
> his opinion.
I see. Still, the instruction's won't be too complex, right? It'll be
something like:
1. Boot Tails 1.0.1
2. Enable admin password
3. Start a root shell
4. apt-get update && apt-get install liveusb-creator syslinux
5. Proceed normally
Right?
If we choose to not document this path we still have to make it *very*
clear that "upgrade from ISO" is not supported, probably very early on,
not just as a footnote in the known issues section.
Cheers!
