We did a brief security review of the Redhat update (rhn) applications and code. Everything previously mentioned in the previous posts is what we saw-- it uses https and gpg, the combination of which is quite powerful. However, the code itself, as I recall much of which is written in Python (in the 7.x system we reviewed), is not at all pretty. It's not cleanly implemented and in my opinion Redhat should go back and rewrite a great deal of it.
>From an architectural standpoint, we have at least one major concern as it relates to automatic (autonomous updates). But before I comment on that, I do want to make it clear my overall opinion is that the Redhat update toolset offers tremendous overall benefits. Even with all of its risks, it provides an extremely well-done and easy-to-use way for administrators to keep-up with updates, one of the biggest problems in security on the Internet today. At the same time, it is a tremendously risky single point of failure that folks managing sensitive high-impact servers must give serious thought to and perhaps reconfigure. >From a reconfiguration standpoint, I advise clients to disable the rhn agent (rhnsd) and instead suggest applying those updates in a controlled fashion while logged-into the system, either downloaded manually after an md5sum/checksum validation or through the up2date -l followed by an up2date -u if you are comfortable with it. The problem with rhnsd is that it is a process always running, and its power to update every aspect of the software is quite extreme. While components it uses (e.g. OpenSSL) have received considerable review, not all of its components have received the level of peer-review I think it warrants. If there is a vulnerabilty in it anywhere, the "Redhat Network" of servers, which would represent a good percentage of the Internet, will tumble to the ground. There are several risk areas relative to compromise, one being that Redhat servers are hacked considerably (down to their private keys) after which malicious software is propagated to all Redhat network servers. Admittedly the alternative, patches we apply manually can be compromised, but it happens with a human being in the middle checking things in some way in accordance with some kind of known organizational policy and procedures you have in-place for your Linux servers. Regards, Eric ---------------------------------- Mission Critical Security Planner: When hackers won't take no for an answer http://www.amazon.com/exec/obidos/ASIN/0471211656
