| |||||||||||
Numerous Debian Project systems compromisedNumerous Debian Project systems compromisedPosted Nov 22, 2003 4:28 UTC (Sat) by IkeTo (subscriber, #2122)In reply to: Numerous Debian Project systems compromised by eludias Parent article: Numerous Debian Project systems compromised
- 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.
(Log in to post comments)
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.
|
|||||||||||