From: "Howland, Curtis" <[EMAIL PROTECTED]> >At some point you have to "trust". Unless you're ready to read every >line of code, every script, yourself every time you install anything, >trust is explicit.
I agree. Since essentially none of our users will have time to read much source code, the only achivable goal is to decrease the amount of code that has to be trusted. They'll have to trust at least the kernel, some tools involved in packaging things, and some basic operating system utilities. However, the present scheme requires me to also trust the packager of each package in /usr/games, for instance. That seems avoidable. >Reputation counts. I'm sure that if a maintainer was discovered to >have uploaded code with such things in it, that maintainer would >loose coolness points galore. But whose reputation? For example: at some point I'm going to get to the local Linux User's Group meeting and get my public key signed by a Debian developer. This person is going to look at my driver's license and then later tell GPG that the public key fingerprint that I will give him really belongs to the person named in the driver's license. This person probably won't have any training on identifying forged driver's licenses, and the gov't doesn't crypto-sign driver's licenses, so passing him a laminated forgery generated on my color printer would probably be fairly easy. If you have a debian developer acting under a false name, then there's really no reputation associated with package. Here's an example that really happened: When I first installed Debian, I installed the Crossfire server (this is part of a multiplayer game). Only later did I notice that the server was running as root. The server's code has a bunch of sprintf's into fixed-length buffers. I tried finding an exploit because I haven't found one before, but I didn't. In any case, we really don't need games packages to have the right to run servers as root. If we could make it so that only some packages need to install as root, and the rest are prevented from arbitrarily modifying the machine, then the intruder has to arrange to be in the root package group to do much harm. This could at least require more social interaction and more time than creating ordinary user-mode packages. I think we could make a more secure scheme with just one extra user, something like "debian-nobody", that user-mode packages would have while they are installing. We'd provide set-user-id-root utilities that can only be run by debian-nobody. They would enforce these rules: Installation scripts for user-mode packages can only put files in certain directories, and they can't overwrite existing files. At removal time, a removal script can only remove a file if it was created by that package at installation time. Packages that can't abide by these rules would be root-mode packages and get more scrutiny than ones that can obey the rules. On the other hand, this is all less important than checking the checksums on incoming .deb's, which we aren't doing yet. So maybe this is all premature. I don't know the required size of the developer group before you can expect to have a patient evil person in the group. Apparently we aren't there yet, and that's a good thing. -- Tim Freeman [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
