Joey Hess <[EMAIL PROTECTED]> wrote: > Martin Stjernholm wrote: > > Section 4.4 item 2 in the Debian Policy Manual implies that /usr/doc > > should be made accessible by a web server. It's not mentioned there > > that it would introduce a security weakness if access to those files > > isn't restricted to localhost. Almost every package puts files under > > /usr/doc, which, if access is unrestricted, makes it possible for > > anyone on the network to do a very detailed scan of the installed > > software on the computer, including version information in most cases. > > This sort of info is a great help for an attacker to choose an > > appropriate method to get into the system. > > Interestingly, I brought this up when we formulated the policy, and was > informed that I was just worrying about "security through obscurity" and it > wouldn't do any good.
Strictly speaking, that's true. Otoh, making this info so easily accessible is sort of like betting that every remotely accessible piece of software on a Debian system doesn't contain a security glitch. The loosers in this case are all the users that doesn't keep an eye on the Debian mirrors, CERT, bugtraq and other forums, because this makes it very easy to scan a large number of computers for known vulnerabilities and also hide that traffic in perfectly normal http accesses. E.g. if someone scans my subnet on the imap and pop ports, some people will probably notice and alert the admins to track down this clown. If (s)he scans on the http port, there's a lot less chance someone will be reading their access log thoroughly enough to notice that /doc is accessed. The cracker has got the same information to target vulnerable systems without stirring things up so much. I can also imagine scenarios with relatively relaxed firewall configurations where this would help an attacker to get information about installed software on computers behind the firewall. Another thing is that questionable software in the contrib section or from third parties also is likely to put things under /usr/doc, and thereby "announce" their presence in a way that's probably unintended by both the package maintainer and the user. To conclude, it's obvious that this is a help for a cracker. That being the case, it's a matter of judgement whether the provided service outweights the lowered security level. It's my strong belief that choices like this should be made by the user and not stipulated by a policy. (And in this case the same service can be provided in a more secure way, so there's no reason not to do so.) /Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
