Tails

#5 Updated by tailshark 2017-06-28 23:11:06

I’ve been looking very closely at remastering official Tails ISOs with a Tresor-style kernel patch for over a year now. This thread interested me because of how close to my goals it hits… and I didn’t want to create a new thread since I don’t see a section dedicated to “Christmas wishlist”. :)

My approach would be different from the author’s though. Rather than depending on IOMMU or a chainloading mechanism (though I agree chainloading would be more modular) I’m personally going straight for kernel patches for my remastering. The idea is to encrypt userland (non-kernel) memory —AND— to patch the kernel’s primary crypto system to RE-ENCRYPT the hard disk keys floating in kernel memory with the TRESOR CPU keys. In other words, even if something is able to dump ring0’s dedicated memory (in ram) those disk keys are still useless on their own. This would allow existing disk keys to work as-is without needing to change or reencrypt any drives, without needing to map/remember UUIDs, etc… In the case of the standard (classic) Tresor patch it only tweaks the area of the kernel that goes to access pages of userland memory and reencrypts (in place) ones it’s leaving while decrypting (in place) ones it’s entering. So the classic patch isn’t a colossal change but there are no existing hooks for something nicer (like a kernel module) to insert itself into that area of the kernel code.

The problem here is that, as far as Tails integration goes, it completely violates their NIH (not invented here) policy once someone embarks on kernel modifications that are not part of upstream. So I’ve been keeping my mouth shut and working on it as a private project. I am totally open to sharing the work with the Tails community once I get it into shape and will be actively maintaining the work for my own personal usage …BUT… I don’t know that I’m completely motivated to try to navigate the politics of the kernel/Debian upstream.

I put this out here as a feeler primarily. If interested in the work let me know and I’ll publish my remastering once it’s ready.

#6 Updated by intrigeri 2017-06-29 07:22:26

> The problem here is that, as far as Tails integration goes, it completely violates their NIH (not invented here) policy once someone embarks on kernel modifications that are not part of upstream. So I’ve been keeping my mouth shut and working on it as a private project. I am totally open to sharing the work with the Tails community once I get it into shape and will be actively maintaining the work for my own personal usage …BUT… I don’t know that I’m completely motivated to try to navigate the politics of the kernel/Debian upstream.

Is the TRESOR project interested in having their patch in mainline Linux and make a real difference, or is it a research / PoC project that satisfies itself with an tiny userbase of enthusiasts users who build their own custom kernel (which could make sense during the initial phase of a project, even though TRESOR is not exactly a young project)? Has there been any attempt at upstreaming their code yet?

#8 Updated by mercedes508 2017-12-25 16:53:41

ping?

#10 Updated by cypherpunks 2018-06-04 04:52:23

intrigeri wrote:
> So this is a large project. We don’t have the resources to tackle it at this point, and IMO we have a number of other large projects with much higher priority. So my question is: do you personally intent to put whatever time+energy is needed to make this happen? Otherwise let’s close this ticket to avoid turning our Redmine into a Christmas shopping list :)

Yes, it is a large project. I have already done this for a test system of my own, but I doubt it would be acceptable by the Tails project as-is (it does not support external unencrypted drives, for example).

tailshark wrote:
> My approach would be different from the author’s though. Rather than depending on IOMMU or a chainloading mechanism (though I agree chainloading would be more modular) I’m personally going straight for kernel patches for my remastering. The idea is to encrypt userland (non-kernel) memory —AND— to patch the kernel’s primary crypto system to RE-ENCRYPT the hard disk keys floating in kernel memory with the TRESOR CPU keys. In other words, even if something is able to dump ring0’s dedicated memory (in ram) those disk keys are still useless on their own. This would allow existing disk keys to work as-is without needing to change or reencrypt any drives, without needing to map/remember UUIDs, etc… In the case of the standard (classic) Tresor patch it only tweaks the area of the kernel that goes to access pages of userland memory and reencrypts (in place) ones it’s leaving while decrypting (in place) ones it’s entering. So the classic patch isn’t a colossal change but there are no existing hooks for something nicer (like a kernel module) to insert itself into that area of the kernel code.

I’ve done something similar to this as well. It does not encrypt memory because that is… very, very slow. Really, absurdly slow (tests showed it take between 15 minutes and an hour to boot an equivalent Debian Live system in a virtual machine, compared to 30 to 45 seconds without the modifications with KVM and 5 minutes without). This is nice in theory, but really not very practical. It may be possible to encrypt individual processes with a little less overhead, though, in the way RamCrypt does. The Tor process would be an ideal target.

intrigeri wrote:
> Is the TRESOR project interested in having their patch in mainline Linux and make a real difference, or is it a research / PoC project that satisfies itself with an tiny userbase of enthusiasts users who build their own custom kernel (which could make sense during the initial phase of a project, even though TRESOR is not exactly a young project)? Has there been any attempt at upstreaming their code yet?

No they are not. There is absolutely no way TRESOR or anything even vaguely related would ever be accepted upstream. In fact, several of the core kernel developers are viscerally opposed to it. It was designed for research purposes, and as such still has a few issues (registers containing key material are pushed to memory during NMIs and SMIs. I modified the patch to account for that and a few other things on my local system). Doing that would be quite easy though, as the patches are actually really simple when you look at it. TreVisor would not be so easy though, but TRESOR would be.

mercedes508 wrote:
> closing it as none of the interested ones answered back since 7 months.

I’m back. While I don’t think TreVisor would be accepted into Tails due to requiring substantial in-house development, TRESOR seems to be a significantly more-practical alternative, albeit with a simpler threat model.

#11 Updated by cypherpunks 2018-06-04 04:58:05

Should I open a new ticket for TRESOR integration, since it seems pretty clear to me now that integrating TreVisor is a quixotic endeavor? I could maintain a kernel module compatible with the Debian kernel which does that myself, along with various (non-intrusive) improvements to TRESOR which make it more production-safe, but it would be necessary for it to be separate from upstream, since Debian is unlikely to take it and the Linux Foundation, even less.

The reason I’ve been gone so long is because, ever since grsecurity went private and Tails showed absolutely no interest in purchasing support from them (KSPP is a joke, don’t start that), I’ve sort of given up on improving the security of Tails. When your hard drive has several kernel-busting bugs lying around that only work on the Debian kernel because of how badly designed it is, you begin to lose motivation. I have considered developing my own commercial fork of Tails, but would need to look into that more before I begin.