Lurking with PGP
If the possibility of a forged posting on the comp.os.linux.announce newsgroup doesn't worry you enough to make you want to install PGP, consider another situation. Suppose you see a newsgroup posting or e-mail message that looks like it is from Ted Ts'o (one of the main Linux developers), and which claims that:
A security hole has been found in Linux,
It is being exploited by crackers who are destroying the systems they crack into,
An attached kernel patch will solve the problem, and
You should install the patch on your system(s) as soon as possible.
Further suppose that the patch is beyond your comprehension. Do you install the patch? Let's assume that Ted is trustworthy (a pretty good assumption). How do you know that it is really Ted who made the posting or sent the message? Perhaps the patch really creates a security hole through which a cracker could attack, and a cracker is forging the message and pretending to be Ted in order to convince you to apply the patch.
You can know because Ted PGP-signed his patch, and because you have a copy of his public key. No one could sign it correctly without a copy of his private key, and Ted is a security expert who keeps his private key very safe.
In order to check a PGP-signed message, you need to have the public key. Where do you get the key? You want to get the real user's real key, not a fake one produced by a forger who is using the fake key to impersonate the sender.
Fundamentally, you need to get the key from a different source than the message. News and mail are notoriously insecure; anyone can fake an e-mail or news message, and anyone who wants to read this article to learn about PGP will probably not notice that the message is fake, and probably won't know how to tell the difference.
If someone is forging messages that are supposed to look like they come from someone else, and they are including PGP, they will also be attempting to propagate a fake key for the user as whom they are masquerading. This means that in an ideal world, you will collect public keys before you need to use them to verify a message. However, there's a good chance that you don't have the key yet when you want to read the message. Where do you look to find a key, and how do you know that it is correct?
Sometimes you can get a key from someone's home page on the Web. If you do that, you have to weigh the possibility that someone has broken security on that system and corrupted the key there. If you get the key well before you want to verify a suspicious message, chances are pretty good that the key you get will be good. The same goes for keys retrieved via finger. If you think you will ever want to verify a comp.os.linux.announce posting, get the key now. If you are paranoid, keep checking for the next few days to make sure there is no announcement that the key was forged or compromised.
One place to find lots of PGP keys is on BAL's PGP Public Key Server, at www-swiss.ai.mit.edu/~bal/pks-toplev.html. This web site has a large database of public keys, and the person you are looking for may have submitted the public key to the database. There's no security; anyone could post an update to anyone else's public key, even forgeries. You still have to verify the keys you get from BAL's server; it's only a convenient point of exchange.
None of these techniques ensure that the key you get is good. All security is a matter of degree, and this technique provides, for most purposes, a reasonable level of assurance that you have the right key. Don't bet the family fortune on it.
Essentially, PGP allows you to extend trust you already have. If you trust your brother to tell you the truth in person, and he has verified that your copy of his PGP public key is correct, then you can be rather sure that a message that is correctly signed with his private key really comes from him. You can be only as sure of that, however, as of his ability to keep his private key secret.
If your brother is sure that his copy of Joe's public key is correct, and you trust your brother to give you a good copy of Joe's public key, then you can be fairly sure that a message that is signed with Joe's public key really comes from Joe. This is a very useful notion, and PGP supports it.
To verify that he is positive that Joe's public key really belongs to Joe, your brother can sign the key with his own private key. If you are certain that your copy of your brother's public key is correct, and your brother has signed Joe's public key, then if you trust your brother's judgement in verifying keys you can be mostly sure that your copy of Joe's public key is correct. Now that you know Joe's key, if you trust his judgement, you can be reasonably confident of the veracity of public keys which he has signed.
PGP users have organized PGP-key-signing gatherings (parties, BOF (Birds of a Feather) sessions at conferences, whatever) in order to meet face to face and sign each other's keys. As people go to different gatherings in different places, it becomes easier and easier to say, “I trust my brother, and my brother has signed Joe's key, and Joe has signed Jean's key, so I can be pretty sure that this message signed with Jean's key is really from Jean.” This concept has become known as the “web of trust”.
Don't go off the deep end when it comes to the web of trust. PGP doesn't make people trustworthy. As Zimmermann says in the PGP manual, “Trust is not necessarily transferable; I have a friend who I trust not to lie. He's a gullible person who trusts the President not to lie. That doesn't mean I trust the President not to lie. This is just common sense.” If you don't trust someone about other things, there's no reason to trust their signatures of other people's keys. They may be duped or careless or lying themselves.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server