| |||||||||||
Numerous Debian Project systems compromisedNumerous Debian Project systems compromisedPosted Nov 21, 2003 17:02 UTC (Fri) by Wummel (subscriber, #7591)In reply to: Numerous Debian Project systems compromised by maceto Parent article: Numerous Debian Project systems compromised
Maceto wrote: Due to this big responsibility/power, a new person who wants to become a Debian developer needs not only identity and skill checks, you need now also an existing Debian developer as advocate.
(Log in to post comments)
Numerous Debian Project systems compromised Posted Nov 21, 2003 17:29 UTC (Fri) by eludias (subscriber, #4058) [Link] I would advocate a number of enhancements to the Debian process (and other distro's):- It has become time to have packages which you can install without having root privileges while running the install and deinstall scripts. Only a select number of packages would need them anyway. The only thing you need root priviliges for in a 'normal' package is for extracting your files, which is something which is checkable and containable.
Numerous Debian Project systems compromised Posted Nov 22, 2003 4:28 UTC (Sat) by IkeTo (subscriber, #2122) [Link] - It has become time to have packages which you can install without having root privileges while running the install and deinstall scripts. Only a select number of packages would need them anyway. The only thing you need root priviliges for in a 'normal' package is for extracting your files, which is something which is checkable and containable. You have no idea of what a package actually does. Most packages must be installed as root. E.g., libraries must install to one of the standard places or they won't be used at all and programs using them will vomit with a message saying library not found. Many packages needs to be able to write to /etc and /usr/share so that they can install the configuration files and data files. Many needs to run daemon processes. If an individual user needs to install something, he can get the package, unpack it himself, put the binary into somewhere he wants, and hope it work. But most likely, it won't. It is more likely than not that at the end one needs a re-compile to change the locations where configuration and data files are to be found. Of course, binary packages are meant to be compiled, and so it means that it is not something that is supposed to be done by the package anyway. - A network of 'package checkers' should exist, which compile Debian packages on their own and compare the compiled version with compiled versions on the servers. This should be distributed, so everyone who wanted to donate some CPU cycles and bandwith would be able to do so. Some kind of background task like SETI@home which would check a random package per day per computer or so. This would not help against source-code comprises, but it helps against trojaned binaries without knowing how it was trojaned. Did you even try to compile two programs in two individually configured computers and compare them? If you did so, you should know that they won't be the same: anything from compiler version to compiler configuration to library version to date of compile will make the actual binary file different. Trojaned binaries can already be checked by using the MD5 checksum now. Your approach would actually help, in the case that the compilation process in the Debian Developer is compromised so that sane source file produces binary files with a trajon horse. But then, if the Debian developer's computer is compromised, I think nothing can be guaranteed anyway.
Numerous Debian Project systems compromised Posted Nov 22, 2003 9:44 UTC (Sat) by NAR (subscriber, #1313) [Link] You have no idea of what a package actually does. Most packages must be installed as root.I do have an a idea what a package actually does, altough my experience is with Solaris packages - however, the ideas are the same. In Solaris, the installation of a package goes through 5 distinct phases:
On Solaris, the checkinstall phase runs as nobody user. It sounds a good idea that the other phases should run also as nobody, however, it caused us some problems - the above mentioned "security daemon" accepts connections only from specific users, so there are a lots of "su" commands in our install code and we couldn't place all of our checks into the checkinstall phase :-( I think that in this case one size does not fit all - for some packages it might be feasible that only the actual copying runs as root (e.g. if the package installs under /usr). For some packages even this might not bee needed (I saw a system where a "program installer" user had write rights on /usr/local - he only installed programs from source, but this technique might be applied to binary packages). But there are packages where more phases should run as root.
Numerous Debian Project systems compromised Posted Nov 21, 2003 19:00 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Unfortunately, based on similar problems at the FSF, it is quite possible that this is a "inside job" (that one of the 1200+ people with developer access might have done the crack). Having people vouch for each other doesn't prevent this. There was a guy I knew once that I would have trusted with my life, and then I found out that he stole checks from another friend who trusted him to house-sit, forged the signature and stole a significant amount of money. Having a bad seed in the Debian Project is a scary thought: all these folks can upload packages, and each package is installed as root and can therefore do pretty much whatever it wants. The Debian policies concerning digital signatures probably deter most temptations in this area, because the bad guy's signature would be attached to the bad code. Still, it's worrying.
Numerous Debian Project systems compromised Posted Nov 21, 2003 23:19 UTC (Fri) by Ross (subscriber, #4065) [Link] This is interesting. I would like to know what mechanism was used toeither gain unauthorized remote access to the system or to escalate from an authorized level of access to an unauthorized one. Is it something that can prevented by better hardening of the servers? I also wonder if there is any connection with the recent modification of I think we can better protect ourselves in the future if we understand
Numerous Debian Project systems compromised Posted Nov 22, 2003 16:49 UTC (Sat) by ccchips (guest, #3222) [Link] This is interesting. I have posted comments before on this site in which I mention the word "betrayal."It doesn't hurt the cause if people around the world, especially those who don't know the technical ins and outs of computers, could understand the nature of this beast in our field. People who advocate more liberal drug laws are familiar with it since day one. There was a time, in the 1970's, when it actually became quite fashionable to spurn informants and people who betrayed one's trust. In our industry, however, we are currently at a point where we are still quite able to identify, and *expose*, people who are willing to sell out to the likes of Microsoft and SCO by engaging in clearly criminal behavior. It was said earlier that bringing in law-enforcement could mean that the servers would be impounded, but there must be some better way to do it. People who violate the law by breaking into the property of others should be punished, and that's that.
|
|||||||||||