1 === _marx_ changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Ubuntu User Days | Current Session: Trusted Software, Where to find it, and why ~~ Presented by paultag || Please ask questions in #ubuntu-classroom-chat || Ubuntu User Days Survey: http://www.surveymonkey.com/s/WQWHJQY
   2 [23:00] <pleia2> This session is about Trusted Software, Where to find it, and Why presented by paultag
   3 [23:00] <pleia2> Paul has nearly 10 years of Linux experience. He has spent most of that time giving back to the community by helping users as a member of the Ubuntu Beginners Team and through his role as team contact for the Ohio LoCo.
   4 [23:00] <pleia2> Today, Paul will share some of the knowledge that he has acquired, and teach us about trusted software.
   5 [23:00] <pleia2> paultag: the floor is yours :)
   6 [23:00] <paultag> :)
   7 [23:00] <paultag> Howdy ya'll :)
   8 [23:01] <paultag> First of all, I would like to give a HUGE shout-out to jcastro. I'm humbled that I was mentioned in his bit about the Ohio LoCo. Wicked session, I loved it. Hopefully I can be just as clear for ya'll today :)
   9 [23:01] <paultag> I am doing this session with a mild direction, and as a result, I would love any questions that are asked
  10 [23:01] <paultag> Try to ignore the Spam, I'll be sure to get to you ASA
  11 [23:01] <paultag> ASAP, better yet!
  12 [23:01] <paultag> First, let's start with the most obvious. Why?
  13 [23:02] <paultag> Let's review for a moment an insecure software model. Both Microsoft Windows and Apple OSX have insecure models as it stands today. The idea of getting new software is to “hunt” on the Internet for a while, until you find an advertisement ridden website with a .exe or .dmg download
  14 [23:02] <paultag> This model is to get Software A authored by entity X from entity Y.
  15 [23:02] <paultag> Euch.
  16 [23:03] <paultag> At this point, it is not hard to compromise the software package. It is not hard to inject malicious code, such as worms or viruses, given the code is hosted by an untrusted authority Y.
  17 [23:03] <paultag> There was just a whole lot thrown at you right there, any questions about X or Y ?
  18 [23:04] <paultag> Let's take a real world example. Let's say that Intel puts out a driver for their graphics card chipset. This driver installer gets picked up by N number of sites, and a fraction of N make it to the front page of Google from a search of that device.
  19 [23:05] <paultag> The problem here is that user-uploaded content depends on the trustworthiness of the author. This is quite an issue because there is no “circle of trust” system. Anyone can post items for download. Even simple “voting” systems will compromise some machines, and can be cheated with fake votes through automated means.
  20 [23:05] <paultag> <patchwork_> QUESTION- When authority Y provides a MD5 checksum, how can I check the downloaded package?
  21 [23:06] <paultag> You may check the checksum with the `md5` command. This is a good way to ensure the software can be trusted, and is authentic.
  22 [23:06] <paultag> The issue with that is that you are still forced to check MD5 hashes, and we have better ways of doing it -- let me get into that now
  23 [23:07] <paultag> With Debian or Ubuntu GNU/Linux, we use a system called a repository. ( Other distros like Red Hat etc also have these systems as well ) Packages are put into this repository, and signed. This is what the Software Store, apt-get, aptitude and synapic all use as a backend. Not only is is really easy to install software ( no more installer hunts! ), but it is trusted.
  24 [23:08] <paultag> The reason why it is trusted is because all the software in that central authority is approved and placed into the system through a review process
  25 [23:08] <paultag> This creates a "circle of trust" with the packages and their uploaders
  26 [23:08] <paultag> However, one might ask -- Why is this system trusted?
  27 [23:09] <paultag> Well, the Repository is maintained by Ubuntu contributors and Debian Developers worldwide. To get into this tight-knight community, it pre-requires a lot of hard work and an intensive peer-review process.
  28 [23:10] <paultag> Packages uploaded are subject to review, and meticulous book-keeping is maintained on what has been changed from the upstream version. ( Upstream is simply where the code came from, in our case ( Ubuntu ) it's Debian, and in Debian's case it's the original maintainers
  29 [23:10] <paultag> Let's use as example the “Fluxbox” package ( I love fluxbox )
  30 [23:11] <paultag> It is developed at fluxbox.org by a few developers. They are trusted explicitly, as they are the official version of the software.
  31 [23:11] <paultag> Any changes ( for better or worse ) are the definitive changes. ( and might I say, canonical! )
  32 [23:11] <paultag> Sorry, I'll lay off the puns ;)
  33 [23:12] <paultag> That software is then imported to Debain, where it is maintained by Dmitry Oboukhov.
  34 [23:12] <paultag> Dmitry is a trusted member of the Debian project, and his changes are documented clearly, and verified by using MD5 checksums, and changelogs. One should be able to go back and examine exactly what was changed when, and why. Changes are linked to bugs, and undocumented changes are looked down upon very heavily.
  35 [23:13] <paultag> Are there any questions about this so far? I just rapid fired a lot at you right now
  36 [23:13] <paultag> Changes upstream are currently four patches. Two to correct documentation spelling errors, one to attempt to fix a critical bug, and the last to fix a small bit of bash in a dash script.
  37 [23:15] <paultag> You can examine each patch, and view it's author. Two are mine, one is Dmitry's and one is from another Debian collaborator
  38 [23:15] <paultag> the patch is also clearly in it's own file, allowing one to easily see what it is doing to the pristine version of the software
  39 [23:16] <paultag> This maintains trust, and never touches the original tar
  40 [23:16] <paultag> Also included in the modifications from Debian is a theme. It will add a new theme called “Debian”, and a debian themed background.
  41 [23:16] <paultag> This is also in it's own directory, and clearly documented
  42 [23:16] <paultag> Ubuntu changes go through this same process, except the maintainer is a community of developers known as the “MOTU” or “Masters of the Universe”.
  43 [23:17] <paultag> All of these changes are clearly documented and logged, again
  44 [23:18] <paultag> The changes also pass through two trusted authorities, Debian and Ubuntu. As we are able to control exactly what goes into the packages, we can ensure that the packages are safe, and changes made are not malicious.
  45 [23:18] <paultag> Are there any questions as to this chain so far, and any questions about trusting any of the parties?
  46 [23:19] <paultag> OK, I'll move on
  47 [23:19] <paultag> What happens when a package is not in the repository?
  48 [23:20] <paultag> Now we run into the same problem as before. Hunt for a dpkg, and install it by hand from a ( potentially ) untrusted third party.
  49 [23:20] <paultag> This is, of course, unacceptable
  50 [23:20] <paultag> AndreMorro[BR]> paultag,  we search a pre-compiled orrrr go to the source
  51 [23:20] <paultag> Yes AndreMorro[BR], you can do that. You have to be sure that the pre-compiled is trusted though
  52 [23:21] <paultag> If you are running Ubuntu, you have a chance of finding it in debian unstable, or a backport, if your release is old. In both of these cases, you can trust the source, either Deb or Ubuntu.
  53 [23:21] <paultag> jcastro touched on that a bit
  54 [23:22] <paultag> In the case where the software is either so new, unknown to the community, or just plain not in the repositories, there are last lines of defense before going dpkg hunting. There is rarely a case where one should be installing a dpkg they wgot from the internet, or downloaded in a browser
  55 [23:22] <paultag> P.S. wgot is my new past tense of wget :)
  56 [23:23] <paultag> One key skill is to learn how to install software from source, as AndreMorro[BR] mentioned
  57 [23:23] <paultag> This can be very intimidating to the new and even power user, but when done right, it can be a relatively tolerable process.
  58 [23:24] <paultag> That, however is a bit outside the scope of what I am presenting now, I won't teach you how to compile for this session – just be aware that compiling from scratch is always more advisable then hunting for a dpkg from any site
  59 [23:24] <paultag> <arand> QUESTION Are there any measures to stop a malicious deb package you happen to stumble upon, or would it be able to do pretty much anything it wishes to a system should it be installed.
  60 [23:24] <paultag> What a fantastic question
  61 [23:25] <paultag> If it is the case of finding it inside the repos for Ubuntu or Debian, the changes are right there, and it is not hard to find the member who did that.
  62 [23:25] <paultag> This can lead to any number of things, including getting kicked out of the community
  63 [23:25] <paultag> If it is a dpkg on a third party site, there is not much you can do. Report it to the site that is hosing it, and comment on it if you can
  64 [23:26] <paultag> That is the trouble with the software model that most are used to in Windows and OSX
  65 [23:26] <paultag> <Out_Cold> question: are all ubuntu source packages (including multiverse/universe) trusted and tested by devs?
  66 [23:27] <paultag> Out_Cold, Yes, every package is either tested and packaged by Debian maintainers, or if it Ubuntu changed, the MOTU and Ubuntu testers
  67 [23:27] <paultag> Out_Cold, every last bit in the repos has been placed there by an Ubuntu or Debian developer
  68 [23:28] <paultag> Well, what happens now. It's not in the repos, it's not been backported, a new version is not found upstream, sister distros such as Mint don't have it. What can I, as an educated hacker do?
  69 [23:28] <paultag> <AndreMorro[BR]> QUESTION - supose I found a pre-compiled somewhere over the internet, before installing it is there any ways to protect my system??
  70 [23:29] <paultag> AndreMorro[BR], This is a tough one. I wish I could say all developers are honest and hard working. I can't say that. There is a lot out there that even the most seasoned vet could look at and think "Oh that does X" but really does harmful think Y
  71 [23:30] <paultag> I would first research the package a bit, figure out what it is, and who wrote it. If you can't find much I would be very hesitant to try it. If you would like to try it and ensure that it won't destroy your system, perhaps a virtual box might help
  72 [23:31] <paultag> OK, so back a few lines -- Well, what happens now. It's not in the repos, it's not been backported, a new version is not found upstream, sister distros such as Mint don't have it. What can I, as an educated hacker do?
  73 [23:32] <paultag> Always look for trusted sources. Look for reputable sources. Try getdeb. Check for RPM packages in red hat, fedora or centos
  74 [23:32] <paultag> Using `alien` is not always the best, but is always better then installing an untrusted dpkg.
  75 [23:33] <paultag> If left to no other option, download the untrusted deb file and ask your local guru to take a look at it. You can check the file without installing it. using `ar` to extract it, one can examine what it is doing before it does it
  76 [23:33] <paultag> This, however, is also very advanced work.
  77 [23:34] <paultag> Always beware. Gnome-Look had an incident where a malicious user uploaded a “screensaver” that was actually a virus.
  78 [23:34] <paultag> <SuperEngineer> QUESTION a lot of mentions of ?backported? please explain
  79 [23:34] <paultag> Sure thing. A backport is when a new package ( such as Firefox 3.6 ) being built for an old version of a distro
  80 [23:35] <paultag> There is a whole repo just for Backports on outdated releases
  81 [23:35] <paultag> <AndreMorro[BR]> QUESTION - ar is used to extract .deb ?
  82 [23:35] <paultag> Yes, one can extract a deb running `ar x package.deb`
  83 [23:35] <paultag> and there are two tar.gz files in there that the advanced user can pick apart
  84 [23:35] <paultag> <strycore> you can use fileroller to extract .deb (it uses ar internaly yes)
  85 [23:35] <paultag> Yes, you can. Great note.
  86 [23:36] <paultag>  Novice packagers can do serious damage. There is this one package that looks inocent enough, but when I took a look at the pre/post install, it did very dangerous things, such as changing the mod of global files to 777 ( not good ), and playing with the ownership of kernel modules.
  87 [23:36] <paultag> It was done to install his code, but many parts of traditional good practice were violated, and could have caused serious issues.
  88 [23:37] <paultag> I won't give it the justice of a mention in here, for the off chance someone might install it :)
  89 [23:37] <paultag> <Out_Cold> question: when finding source files that come with a .diff file what do you do with the diff?
  90 [23:38] <paultag> a diff is a text file that represents changes that wish to be distributed against the software
  91 [23:39] <paultag> So, if we were to both use package A, and I wished to create feature X, I could edit the package A and then difference ( or diff ) the two directories
  92 [23:39] <paultag> Then I could save those changes as a "diff", and distribute them to others who want feature X
  93 [23:39] <paultag> Treat a diff as you would anything else. It's code, and one can produce a patch to do malicious things
  94 [23:40] <paultag> you may apply them using the "patch" command
  95 [23:40] <paultag> debian / ubuntu uses a few different systems within the dpkg, but they all do the same thing
  96 [23:41] <paultag> Now, I threw a lot at you with regards to how one should trust software in the Repos. Any questions as to why?
  97 [23:41] <paultag> OK. Well I'll add a bit more on to the "Circle of Trust"
  98 [23:42] <paultag> The developers for Ubuntu have PGP keys. PGP keys are one of the few ways that trust can be demonstrated in an ad-hoc community
  99 [23:42] <paultag> ( and Debian )
 100 [23:43] <paultag> When I say Ubuntu, treat it as both Ubuntu and Debian :)
 101 [23:43] <paultag> One maintains their key, and uses it to "sign" documents. Each signature is unique, generated off the content of the file, and their private key
 102 [23:44] <paultag> If you trust the holder of the key, then you can therefore trust the content, if the signature + content matches their key
 103 [23:44] <paultag> But, it would be very hard for one to go, and say "I trust developer Joe" and "I trust developer Sue"
 104 [23:44] <paultag> so, developers will meet up in person, pull out photo ID, and verify that the key is a match to who they are
 105 [23:45] <paultag> they then sign each other's key, and if you trust Joe, then you can therefore trust Sue, because Joe trusts Sue ( and you trust Joe )
 106 [23:46] <paultag> This is done throughout the whole community, and eventually we have a trusted, and very particular ring of trust
 107 [23:46] <paultag> Now, it would be silly to even expect a new user to know a single developer, so what then?
 108 [23:46] <paultag> They can trust the Repo, because they trust Ubuntu enough to install it.
 109 [23:47] <paultag> <Out_Cold> QUESTION pgp keys can be duplicated can they not?
 110 [23:47] <paultag> Out_Cold, yes, one can copy a key, but it has no effect on security
 111 [23:47] <paultag> There are two halfs to the key, a public half and a private half
 112 [23:48] <paultag> the public half is in keyserver.ubuntu.com ( among others ), and the private key exists only on the developer's machine
 113 [23:48] <paultag> <Out_Cold> would that not allow one to compromise a dev's account?
 114 [23:49] <paultag> Knowing the public key only allows one to encrypt for them, and verify their signatures. It is mathematically imposable to use a public key to sign a document
 115 [23:49] <paultag> So, in the repos there is a package. For debian it's debian-keyring
 116 [23:50] <paultag> The description on apt-get says it all ---
 117 [23:50] <paultag> Description: GnuPG (and obsolete PGP) keys of Debian Developers
 118 [23:50] <paultag>  The Debian project wants developers to digitally sign the announcements of
 119 [23:50] <paultag>  their packages with GnuPG, to protect against forgeries.  This package contains
 120 [23:50] <paultag>  keyrings of GnuPG and (deprecated) PGP keys of developers.
 121 [23:50] <paultag> So, by installing Ubuntu or Debian, you install a set of trusted keys to the car, as it were
 122 [23:51] <paultag> This also allows you to ensure _every_ last bit of code is verified by a developer that is trusted by the community
 123 [23:51] <paultag> apt does this automagicly, if you were to remove the -keyring package, and install something like "firefox", it would give you an error and warning that it could not verify the code
 124 [23:52] <paultag> Are there any questions on how the keyring works, and how that is used to ensure trusted software?
 125 [23:52] <paultag> <tcpip4000> ...it's mathematically possible but in practice is very difficult
 126 [23:52] <paultag> tcpip4000, Yes, you are right. You can brute force anything.
 127 [23:53] <paultag> tcpip4000, The numbers to do that though would require more computation power then we have right now to break, and that key can be "untrusted" very easily
 128 [23:53] <paultag> I'm a CS major, I treat large numbers as infinity :)
 129 [23:54] <paultag> <tcpip4000> QUESTION: how is identify and handle a breach in the circle of trust?
 130 [23:54] <paultag> It's hard. Anyone can upload to the build daemons, but it throws out anything that is not signed by the right person. If the code is signed by a trusted developer, and uploaded, it will get built, and placed into the tree it was uploaded into
 131 [23:55] <paultag> The way to catch it would be to have someone notice, and report it. In general the QA team reviews this stuff in Debian, and Ubuntu is very peer-reviewed.
 132 [23:55] <paultag> It could get into the repo ( in the case of breaking someone's hand until they gave up a password ), but that would be identified pretty quick.
 133 [23:56] <paultag> Also, in Debian there is usually more then one developer on a package, and they would look to see what changed, if nothing else then just curiosity
 134 [23:56] <paultag> Any other questions about the key system used to ensure trust?
 135 [23:57] <paultag> Any questions at all?
 136 [23:57] <paultag> Ah, there it is
 137 [23:57] <paultag> <nulled> does ubuntu use sha or md5?
 138 [23:58] <paultag> nulled, we keep MD5 sums on files ( dpkg does this ). There is a theoretical security risk with MD5, but due to the fact we have a lot ensuring uploads are trusted, it is really a "make sure you are honest" kinda thing.
 139 [23:59] <paultag> MD5 sums are also a tad quicker IIRC, and that helps build the code
 140 [23:59] <paultag> <nulled> i noticed it takes longer and longer to read in packages due to the amoount of them.. is apt going to get efficiency enchanced?
 141 [00:00] <paultag> nulled, I would ask the upstream maintainers in Debian. I'm not sure. I know the system is getting better through use of hacks, such as compressing the package lists etc, but not too much in the way of changing the protocol
 142 [00:01] <paultag> nulled, the repo is over HTTP, so I think a change to the protocol would be needed as well. I would not count on it in the near future, but heck, it's still faster then YUM, eh?
 143 [00:01] <paultag> <tcpip4000> question: is there any functionality that checksums the current installed packages (files) to verify their integrity?
 144 [00:01] <paultag> tcpip4000, Yes :) -- it even tracks that stuff on upgrade as well. Some of the older hackers might recall an apt-get upgrade asking about their  menu.lst
 145 [00:02] <paultag> It will verify on install to make sure nothing was corrupted, and it will also track going forward
 146 [00:02] <paultag> it won't kludge old stuff :)
 147 [00:02] <paultag> I know we are a bit over-time here, just waiting for some stuff to get lined up. I'll be taking questions :)
 148 [00:02] <cjohnston> Okie.....
 149 [00:02] <cjohnston> I think we may be ready
 150 [00:03] <cjohnston> Thank you paultag
 151 [00:03] <paultag> OK, cool
 152 [00:03] <paultag> sure thanks guys :)