Trusted Software, Where to find it, and why

Session Logs

   1 [00:01] <pleia2> Next up we have ptagliamonte who will be talking about Trusted Software!
   2 [00:01] <paultag> over here pleia2 :)
   3 [00:01] <pleia2> Paul Tagliamonte is a member of the Ubuntu Beginners team, and loves the Red Sox more then life it's self. His 10 years as an GNU/Linux user will aid in presenting material in a digestible manner for new users. Quoting maco about paultag "and on the 19th day, paultag created elephants, then mated them with sheep to make snuffleupagus". Could not have said it better myself.
   4 [00:02] <paultag> Shalom, Aloha and Hallo! I'm Paul Tagliamonte. I've spent a few years working with the Ubuntu Beginners team, as well as the Ohio Team, and the LoCo Council. Shoutout to everyone from my LoCo, any LoCo, and all my Beginners Team buddies! love you guys!
   5 [00:02] <paultag> Well, geez I love bragging, but let me move on to the few little qualifications I have to make, but let me keep the boring stuff to a minimum. Pay attention now, so you understand where I'm coming from later! ( This ain't no airplane safety talk! )
   6 [00:03] <paultag> I'm here to talk about trusted software, and why it matters. This is really important for anyone switching from OSX or Windows, and ( I think ) pretty interesting to anyone who runs a Debian or Debian Derived system ( such as Ubuntu! ).
   7 [00:03] <paultag> I had a *ton* of slides, but I lost them Thursday night. They were all done up with the new Ubuntu font, and pretty colors in the GIMP. They were almost as good as Jono. Sorry all you lernid users, guess you will just have to read :)
   8 [00:04] <paultag> My target audience is really aimed at the new user who has a small to medium degree of technical background who wishes to learn more about the Ubuntu software ecosystem. If you are a GNU/Linux hotshot, chances are most of this is a bit of a review. You can go and get yourself some tea while I start off :)
   9 [00:04] <paultag> I'd like to preface what I have to say with the following bit:
  10 [00:04] <paultag>  {*} I'm not Ubuntu MOTU ( Ubuntu Package Maintainer )
  11 [00:04] <paultag>  {*} I'm not Debian Developer or Maintainer. I do, however work on the `fluxbox` package with two other guys. That hardly counts, though.
  12 [00:04] <paultag>  {*} I'm not a security professional
  13 [00:05] <paultag>  {*} I'm doing this to help new users understand the why of what we do, not an in-depth technical review of what we do
  14 [00:05] <paultag> Stuff that I present could be wrong. The issues, however, won't be the concepts. If you ask me a technical question, I will answer it to the best of my ability, but I do not want to assert that I know everything there is to know about Debian packaging. That, of course, is wildly false :)
  15 [00:06] <paultag> Some things to know:
  16 [00:06] <paultag> Ubuntu comes from Debian. We sync our packages every six months, and we largely pull from Debian. We give lots back, but they are our "Upstream". Ubuntu users, therefore, can trust Debian developers, and repositories.
  17 [00:06] <paultag> Keep this in mind for the next 50 minutes :)
  18 [00:07] <paultag> So, I'd like to start off with a quote from the philosopher Frank Zappa ( Don't laugh, he rocks! ) --
  19 [00:07] <paultag>  "Without deviation from the norm, progress is not possible"
  20 [00:07] <paultag> Ubuntu and Debian are only here because one of us hackers ( not crackers! ) thought "Humm, well this way seems better, let's try it out!". After a few applications of the evolutionary theory, the best ideas stuck around.
  21 [00:07] <paultag> Darwin would surely be proud.  :)
  22 [00:08] <paultag> One of these radical changes was a bit of software called "dpkg"
  23 [00:08] <paultag> dpkg let users install pre-compiled packages, cutting out the need for a C(++ perhaps?) compiler, and hours of time to build the system up. After all, building from source is a tad painful ( don't think the Gentoo guys have figured that out yet! )
  24 [00:09] <paultag> This, however had already been done before. What made dpkg different were it's new features. It tracked files in the filesystem, maintained dependencies, and "just worked".
  25 [00:09] <paultag> After a bit more time had passed, the system we use today was perfected. `apt` was born. Huzzah!
  26 [00:10] <paultag> So, what makes the apt system so great?
  27 [00:10] <paultag> Trust. Trust is what ties together the whole system.
  28 [00:10] <paultag> No, not take-it-on-faith-this-site-does-not-look-sketchy-i'll-just-install-it trust, but real trust.
  29 [00:11] <paultag> Let's face it. Most crackers and black-hats are pretty damn good at what they do. If they can get you comfortable with exploiting your own system, they know a thing or two. If they are good enough to know how to keep the infection process subtle, chances are they will have the exploit be subtle.
  30 [00:11] <paultag> It's not often that a computer virus will go through and destroy the box bit-by-bit, or have lots of pop-ups, that hack has been dying out for years. More often then not, it's more effective to use your computer as part of a bot net.
  31 [00:12] <paultag> It's like the difference between spray painting a wall to show off how cool you are versus running a pyramid scheme from inside the building. One pisses people off, and the second makes you money while you piss people off.
  32 [00:14] <paultag> So, even if you had installed that shady bit of software, it might work just fine -- but also be "hacked".
  33 [00:14] <paultag> When you install something on Windows, there is this natural process that one goes through. The first step is identifying what you want. Bob here is currently in the market to talk with Carroll. Carroll says "Just skype me!". If Bob can't find the Skype website, Bob googles "Skype", and clicks on the first site that looks like it might have the .exe on it.
  34 [00:15] <paultag> Bob finds the .exe from Thiston, our Third Party, and installs it.
  35 [00:15] <paultag> Everyone still with my using my A-B-C / Third Party setup? Good? Good.
  36 [00:16] <paultag> See, Bob trusts Skype, but Bob sure as heck does not trust Thiston. In fact, Thiston may or may not have injected malicious code into the Skype packge to be installed. Bob does not know, after all, he just wants to talk with Carroll.
  37 [00:16] <paultag> Well wait a minute! When did it become OK to just install anything from anywhere!?
  38 [00:16] <paultag> Back to trust, and Ubuntu.
  39 [00:17] <paultag> With Ubuntu you type "sudo apt-get install skype". I'm not here to flaunt how much we've cut out of the google'ing process, or even how easy you all know it is, rather, just start to point something out. All the software comes from these big blobs called "Repositories".
  40 [00:19] <paultag> They are similar to the app store for an iPhone or Android
  41 [00:19] <paultag> I can hear you all asking already "Well, fine. What's the difference between a website full of software and your special little website-repository-thing full of software?"
  42 === Sodlig is now known as ech0tk
  43 [00:19] <paultag> One key thing. Trust. I know I keep coming back to this, but that's how it works. Not just anyone can upload to the repository. A select group of highly trained and marginally insane folks known as the MOTU in Ubuntu, and Debian Developers in Debian have access to the packages.
  44 [00:21] <paultag> [19:21] <rogerdg> What does MOTU stand for?
  45 [00:21] <paultag> [19:21] <maco> Masters of the Universe ( Thanks, Maco! )
  46 [00:21] <paultag> The process for getting a package into Debian is actually quite difficult, from the outside. It requires an intensive review, and quite a bit of "book keeping". Each package is evaluated on it's suitability to be placed in the archives. License issues are evaluated ( DFSG, or Debian Free Software Guidelines for Debian, and a slightly more liberal approach for Ubuntu ), as well as a review of the source code.
  47 [00:22] <paultag> If the package is eligible for upload into the repositories, an enterprising dev-head in the Debian community ( or Ubuntu community requesting to upload to Debian ( being our upstream, and all ) ) will package the software with lots of data on where it came from, who it came from, how it can be distributed, as well as what it does.
  48 [00:23] <paultag> This template file will be uploaded for review, and sponsored. If the person doing the packaging is a Debian Developer, they are considered part of the project it's self, and may upload a package once they see that it's suitable.
  49 [00:23] <paultag> Let's stop here for a second --
  50 [00:23] <paultag> Why can we trust a Debian Developer?
  51 [00:24] <paultag> [19:23] <regi> If a software or a software update is added to the debian repository, is it also automatically included in ubuntu?
  52 [00:24] <paultag> regi: Yup, every 6 months we sync with Debian
  53 [00:24] <paultag> Before I can answer that, I need to answer another question -- How can we trust a Debian Developer.
  54 [00:25] <paultag> The answer is a system called "GPG" or "GnuPG". ( Thanks, dad for talking this out with me last week!! ) It's a F/OSS ( Free / Open Source Software ) implementation of the PGP library. In nerd speak, it uses a symmetric key pair to assert identity. One side is public ( anyone and everyone can have a copy without it causing security concerns ) and the second is private ( super-top-secret ).
  55 [00:26] <paultag> When you take your private key and "touch" a document, it leaves a "fingerprint" on it. This "fingerprint" is totally unique to your key, and can not be duplicated or forged ( by use of a one-way hashing function ).
  56 [00:27] <paultag> In addition, this key can be "touched" by other people, leaving their fingerprint on your key. When you "touch" someone else's key, it shows that you know them. This is called signing a key.
  57 [00:27] <paultag> DD is a Debian Developer, by the way ( If I ever use that term, thanks jledbetter )
  58 [00:28] <paultag> In order to become a Debian Developer, you must have a key signature by an existing Debian Developer. To have your key signed, you must meet up in real live, and present your ID and key signature. This is a one-way relationship ( saying "Alice trusts Bob" does not say "Bob trusts Alice" ), however, most key signs are reciprocated.
  59 [00:29] <paultag> This builds up something known as a "Ring of Trust". This ring means that every single developer can trust the origin of anything signed by another developer.
  60 [00:30] <paultag> Since the Debian Project is nothing but the collection of Debian Developers, the Debian project can trust the origin of any file by another developer.
  61 [00:31] <paultag> There is something called the "Strong set" which is a huge network that is very very tight
  62 [00:32] <paultag> So, why can we trust a developer?
  63 [00:32] <paultag> If we trust the project, and the project trusts the developer, then we trust the developer. It's as easy as that.
  64 [00:33] <paultag> Well, what if this vetting process is compromised, after all, GPG signatures only verify identity, not trust
  65 [00:33] <paultag> <maco> [the strong set] is the largest set of pgp keys on public servers that are all able to reach each other
  66 [00:33] <paultag> You can read a bit more about it http://pgp.cs.uu.nl/plot/ <-- ( thanks again maco! )
  67 [00:34] <paultag> Anyway, back on track --
  68 [00:34] <paultag> Back It takes about two years of quality work before you can even be considered for Debian Developer status. Before you could even start to think about compromising the system, you have to spend a considerable time and effort. This will deter most people.
  69 [00:35] <paultag> This does not, however, exclude the possibility. If a Debian Developer is found to be compromising the integrity of the package, they will be removed from the project. Keep in mind that the Ubuntu ecosystem is identical.
  70 [00:36] <paultag> So, we can ensure that this big repository is safe, and reviewed. So, when we install from this repository, we can ensure our system is safe. After all, if we trust the OS to run on the PC, we can surely trust software they provide as safe.
  71 [00:36] <paultag> So, let's get back to basics. Some stuff that goes on that makes this system tick:
  72 [00:37] <paultag> Hash-sums. No one in any of the systems can escape verifying the checksum of the file. When the upstream .tar.gz file ( source package ) gets imported, it's hash checksum is computed, and logged. Under *NO* conditions should the Debian developer or Ubuntu MOTU modify the .tar.gz without explaining why it was changed, in detail.
  73 [00:38] <paultag> The only sitution that this is done is dfsg compliance. dfsg changes are usually just removing stuff, but when a maintainer does this, it is verified as to exactly what was changed. a
  74 [00:38] <paultag> After this, the dsc is created ( any patches are contained in the dsc upload files, and easily viewed as to what each does ) and "touched" by the developer.
  75 [00:39] <paultag> What this all means is that all changes are documented and attributed to the developer who made them. Any changes to their changes will cause a checksum failure, and an invalid package.
  76 [00:39] <paultag> This means that we can be totally sure as to where a file came from, and audit the authenticity of any and all packages.
  77 [00:39] <paultag> Can't do that with a .exe or .dmg!
  78 [00:40] <paultag> When you download and install a .exe from any site other then it's author's, you are exposing your machine to a potental security risk.
  79 [00:40] <paultag> Similarly, installing .deb files from just anywhere is just as bad. After all, because it's not trusted by your operating system, it's not trusted by you!
  80 [00:40] <paultag> When you install a package, it installs as root. This means that there is zero ( read: *NO* ) security protection or limits. Since there are package scripts that can run before and / or after install or removal, the script can run any code *at* *all*.
  81 [00:41] <paultag> This is useful for installing a new system service, but quite the opposite for installing a security backdoor.
  82 [00:42] <paultag> So, what happens when you need to install some software, but it's not in the Ubuntu repository?
  83 [00:43] <paultag> There are a few things you can do here. The first course of action is to check sister and parent distros for the package in question. First, check upstream. Look to Debian Testing or Debian Unstable. It's true that we are not Debian, but installing a package from upstream is a lot better then some of the other ways to get the software. This can lead to issues, but again, these issues are a whole lot better to deal with rather then rooting 
  84 [00:43] <paultag> After all, it's not hard to put sshd as a dependency on a package ( that does not need it ) and set the root password in the pre/post install script!
  85 [00:44] <paultag> If all this fails, look to downstream. Check Mint, or any other Ubuntu branches. If it's a reputable distro, it might be compatable, and again, worth a shot.
  86 [00:45] <paultag> Lastly, look to "stranger" distros. Check out Red Hat, CentOS, Fedora, Slackware -- and try and massage the package into your system with `alien`. This can ( and will ) cause problems with long-term use, but it's OK for a quick-and-simple one-shot.
  87 [00:46] <paultag> [19:46] <benhosmer> I'd never heard of 'alien' is this debian specific command?
  88 [00:47] <paultag> benhosmer: it's a command that converts 'alien' packages into Debian packages. It's not debian specific as such, because it can work both ways
  89 [00:47] <paultag> [19:46] <Lrpbpb> not sure if it is relevant, but where do ppa come into all of this?
  90 [00:47] <paultag> Lrpbpb: PPAs are a bit better, but they still have untrusted software. Always trust the author of a PPA!
  91 [00:48] <paultag> PPA stands for Personal Package Archive
  92 [00:48] <paultag> ( Just FYI )
  93 [00:48] <paultag> [19:48] <benhosmer> so alien is a 'nix command?
  94 [00:48] <paultag> benhosmer: first of all it's *n[u|i]x, it's linUx ;)
  95 [00:49] <paultag> benhosmer: second of all, it should work on most GNU platforms
  96 [00:49] <paultag> Worst comes to wost, and it's nowhere to be found. Well, uh oh. Contact the author. Developers love hearing from users.
  97 [00:49] <paultag> See if the author would be willing to try and get the package into Debian. There is lots out there about how to get the software into the ecosystem.
  98 [00:50] <paultag> Failing all this, you can try to install from source. Installing from source is always dangerous, and can be overwhelming. I'd rather not get into the process in this session, it's something entirely out of the scope of this session.
  99 [00:50] <paultag> [19:50] <ddecator> you can also file a "needs packaging" bug if you really want
 100 [00:50] <paultag> You sure can, thanks Dray :)
 101 [00:50] <ClassBot> There are are 10 minutes remaining in the current session.
 102 [00:50] <paultag> You can use some tools like `checkinstall` to make things easier. These tools let you follow the normal procedure of installing from source, and also keeping it in a deb format. These deps should really be not be distributed. There is a reason the process is the way it is, if you know what I mean. :)
 103 [00:51] <paultag> Let me finish up my last little bit and I'll get to questions
 104 [00:51] <paultag> Another big no-no is using wget to download a script, and run it. Running wgot files is very dangerous, even more so when the files are of unknown origin. Something like the alsa script from the alsa website it's self is OK, but a script off someone's personal website for software they are not involved in is a big no-no.
 105 [00:51] <paultag> If you are forced to do this, please have someone look over the file. It's far too easy to compromise a machine with a shell script. About 7 months ago, someone posted a hack as a screensaver and infected a few machines because people ran malicious commands unwittingly. Try and avoid the "Look something shiny" effect with software
 106 [00:52] <paultag> take your time installing it, rushing anything is bad
 107 [00:52] <paultag> OK, I have 10 minutes left, so, I'm going to open the remaining bit of this period to questions. I know what I just rattled off was a whole lot, and there is a lot of stuff that I glanced over that really is key to what we are talking about. I'd love to clarify any questions you might have :)
 108 [00:54] <paultag> [19:53] <suprengr> QUESTION: a popular non-trusted add-on is Ubuntuzilla - why?
 109 [00:54] <paultag> [19:54] <suprengr> ...as in why do people think its safe
 110 [00:54] <paultag> Well, it is :)
 111 [00:55] <paultag> there is a peer review going on
 112 [00:55] <paultag> if there is a site where there is this huge dump of software, and people say "Wow, that's great" and it's Open Source, it can gain a reputation
 113 [00:55] <ClassBot> There are are 5 minutes remaining in the current session.
 114 [00:55] <paultag> since the site is trusted by your web-browser ( Firefox ) you can depend on it not destroying your box
 115 [00:55] <paultag> if you just download it from hacksite.info, it would be an issue
 116 [00:55] <paultag> [19:54] <Lrpbpb> QUESTION: is there any way of knowing IF the system has been compromised?
 117 [00:56] <paultag> Great question!
 118 [00:56] <paultag> It really depends on how it was comprimised. There is a lot of peer-review going on, so people who check over new changes are really the first line of defense
 119 [00:57] <paultag> If it's a slick change that's made it in deep, it's very very hard to discover. We are lucky, however, that most professionals use GNU/Linux in their infrastructure and verify their system's integrity
 120 [00:57] <paultag> [19:57] <maco> Lrpbpb: chkrootkit is a good start
 121 [00:57] <paultag> [19:57] <maco> Lrpbpb: also, debsums
 122 [00:57] <paultag> Yeah, these are great ways to manage the system. Debsums will check the dpkg database on each file
 123 [00:58] <paultag> and it will even be less prone to failure due to defers in the dpkg system
 124 [00:58] <paultag> ( if two packages provide the same file, debsums will know it's only going to be the one that's actually in there, and won't throw a false positive )
 125 [00:59] <paultag> But the main, and best method is to always be wary of how the system is running
 126 [00:59] <paultag> report any issues you find, after all, we can't ESP bug reports just yet
 127 [00:59] <paultag> Any other questions in the last 20 seconds?
 128 [01:00] <pleia2> thanks paultag!
 129 [01:00] <paultag> Thanks guys!
 130 [01:00] <paultag> sure thing pleia2

UserDays/07102010/Trusted Software, Where to find it, and why (last edited 2010-07-11 00:03:05 by alderaan)