Forget securing the yum.conf per se with e.g. gpg. If a cracker has rooted on a client and can write to it, you've already lost the war. Forget about securing include references, as well -- why would they make yum less secure than the primary repositories (except by their very existence in the sense that the more repositories you use, the more vulnerable you are overall). > > I think would go a long way towards making it more secure in a network > > environment. I don't think yum will ever be secure in a network environment, because network environments are complex, and historically weaknesses can be and have been discovered at many levels (any one of which would suffice to compromise yum or damn nearly anything else). TCP spoofing, buffer overwrite attacks on unavoidable services (e.g. apache or an ftp server or ssh itself), man-in-the-middle attacks, snooping -- the network is a dangerous place. With that understood, there are three general places to be aware of when considering yum security. One of them MIGHT be improvable inside the yum itself, the other two are largely a matter of macro design and operation and outside of yum's ability to affect. They are: a) host authentication. One wishes to be certain that the hosts the yum client attempts to update from are the ones actually given in their yum.conf (either directly or via an include). This can in principle be compromised locally (e.g. downed server, spoofing laptop on the server's IP) or global (man-in-the-middle on a routed connection). Host authentication would be a lovely thing to have on all networking connections. Alas, it is nontrivial and somewhat "expensive" to arrange, and currently outside of the purview of yum itself. I suppose one could integrate ssh_known_hosts as a yum feature, adding an ssh dependency and/or requiring that sysadmins rigorously support/maintain /etc/ssh/ssh_known_hosts* or add the key(s) to yum.conf in order to use this feature. Even this requires one to worry about insertions in the distribution chain -- you have to hope or try to arrange that the ssh_know_hosts key(s) that you distribute to the clients are themselves not altered, so you have to trust or check by hand your original install(s), if nothing else. b) server defenses. The way yum works now, if your server is ever cracked, so is every yum-client on your network, one day later. Defending the server means defending it against ALL possible spoofs, buffer-overwrites, piggybacks. yum cannot really help with this, either client-side or server-side. So if your server (ANY server of ANY repository in yum.conf or its includes, as Seth noted) is ever cracked, you'll just have to die at the whim of the cracker. c) server pipeline. The server gets its packages from e.g. mirrors and so forth up the line (unless its maintainer builds from src rpm's, and even then THEY come from up the line back to a master repository). A weak link anywhere in this chain (really tree) cracks every yum client downhill from the cracked tree node. gpg checking of packages and so forth is all well and good, but I don't see why a cracker wouldn't just consistently distribute false gpg keys as well as backdoor packages. At some point you have to trust your supply tree or go back to the host-authenticated original root (which one HOPES remains uncracked) to get your gpg keys, and then what can you do, gpg-check the gpg keys you get? Quid custodes custode, sort of. There is a catch 22 here that has long puzzled network security designers. At some point there is ALWAYS a level where an exploitable bug or successful crack compromises everything. In most network designs there are many such points. We all just live with it. b) isn't within the yum purview at all -- how can yum ensure that somebody runs a server securely? It cannot. At best one can come up with references to documents on how to set up a reasonably secure server, watch it carefully, and hope that it never gets cracked or that if it does you notice before any harm is done. There are some methodologies for doing this sort of thing that can help, or at least can slow down a cracker attempting to insert their own rpm's into the repository (keeping the repository in a RO filesystem, possibly on another system altogether, for example, to decouple the server being cracked from the corruption of the base repository files). Similarly, what can one do about c)? If Seth has his manic break from overwork and drops a trojan into the duke repository, everybody who mirrors from Duke is dead, at least until somebody notices. Ditto if the server gets cracked -- no matter how careful and good you are, there is always a chance that somebody will find a buffer overwrite attack and write and use the exploit BEFORE it becomes common knowledge and a patch is made available. Eternal vigilance is the price of freedom. The crackers always win, eventually (Murphy's law). Keep good backups. Be prepared to use them. (some useful mottos of successful network security). Anyway, I personally think that these three are the places where the yum concept is "weak" as far as security is concerned. Most of these weaknesses aren't yum's; they are inherited weaknesses of the network itself, or the risks inherent in any sort of central distribution model. The only thing that might be worth investigating for implementation in yum itself is a) -- I can imagine a scenario where one inserts the public ssh key of yum servers into a yum.conf so that yum can do a quick handshake right before starting to download files to be certain that the host it thinks it is contacting really is that host. Keeping that server secure beyond that, as well as finding a reliable and trustworthy tree back to a reliable repository root, is up to you, and in the fullness of time likely to fail. Just don't waste energy worrying about keeping ANYTHING secure on the clients at the yum level -- yum now is secure enough at that level AFAICT, unless the host is already rooted. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
