> After a bit of looking (I was very concerned after reading the first > post) it seems this feature is primarily focused on providing > information to satisfy an external "trusted system y/n" type query by > matching a known kernel image hash which is expected by the requestor. Which is potentially a very dangerous thing, because all of a sudden you create an environment which encourages third party tools to do this and to claim DMCA violations against anyone who so much as peeks at what their box is doing. Note the 'trusted' is not 'by the user' in most of these cases it is 'by big media companies who go around removing Linux from their platform and suing people who put it back'. Also it's not 'trusted' as in secure it's trusted as in 'the same as before'. One of the problems of deploying it to create a secure setup is the two are not quite the same thing and it is very very hard to manage the difference well. Which isn't to say it doesn't have uses but to be useful to an end user you need a setup where the end user holds the signing keys not Fedora or big media. It also has some interesting licensing issues if you don't do this - in particular the GPL says 1. The "source code" for a work means the preferred form of the work for making modifications to it. Which would appear to mean 'with the keys so I can re-sign it' 2. The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. Which would appear to imply any keys needed GPL 3 covers all sorts of other stuff, so any mix of TC and GPLv3 ends up horribly messy because the user must be able to modify the material and there are anti DMCA provisions thankfully. 3. It's been stated by several kernel developers that they believe and intend the GPLv2 to be read to include such keys. In fact some kernel files contain the following note * For the avoidance of doubt the "preferred form" of this code is one which * is in an open non patent encumbered format. Where cryptographic key signing * forms part of the process of creating an executable the information * including keys needed to generate an equivalently functional executable * are deemed to be part of the source code. Yes we saw this coming years ago, along with some of the fascinating papers by some vendors, academics and others on how to use crypto between proprietary apps on an open source OS and firmware below it to do stuff out of OS control. > If this is the way things are, this feature can be implemented unnoticed > by the user, hence the lack of major discussion on the user list. On the Which is deeply unfortunate because it has good and bad stuff users ought to know about. > PS: I have questions about this feature, but at this point they are > mostly on the level of "how is it guaranteed to be secure without a > third-party check against the hardware". The answer must be pretty A sequence of things measuring signing and trusting each other all in terms of a set of master keys you don't control. Remember though this is actually all about "was the same as before" (aka "no unauthorized changes"). If you think about it you do the same with a web browser and https://. There are root keys whose private key is utterly secure (except when they get stolen) and whose public keys are in the browser. From this you can build a chain of signatures and sign things in order to authenticate a connection to a fair level of certainty. These root keys also mean done carefully you can virtualise key sharing and do migrations without compromising the system. Roughly speaking there are two elements that are "useful". One is the TPM provides a place to put secrets and do crypto. It's basically a crude smartcard on the motherboard. So for example a corporate setup could put VPN related keys there and anything changing the trusted build would not be able to read them. Unfortunately of course that means upgrades, config changes etc either break the keys or can't be measured properly. You can use the tpm without TC more generally as somewhere safer to dump password protected keys and its a pity gnome-keyring doesn't seem to do this, at least on my box. Maybe I need to install other bits to make it do so but it's not obvious. The second more interesting one is to create virtual machines that are secure from the rest of the OS so that for example a proprietary media player could run its own secure VM where Linux and the administrator and user cannot get at it, and can access and record secrets and the like which the machine owner has no control over. TC PR people like to use a banking app as an example of why it is "good", anti TC people like to give examples like the old Sony CD rootkit stuff as why it is bad if the bad guys might start hiding stuff under the OS this way. The TC setups are actually valuable to system owners in some cases, particularly in things like call centres and hotel front desks where the system owners want to crack down on their users doing stuff they shouldn't. They can also be useful for other things. Consider for example a trusted environment which boots and performs security checks/virus scans on the rest of the system. If you the end user control that and the keys then its actually quite handy because a compromise can't modify those measured paths without being caught when running the tests. TC is a bit like a rifle. There are lots of evil things you can do with it, but there are some good ones, and above all what matters is that you are on the trigger (key owning) end of the discussion. Alan -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
