Thinking again about what I wrote, I disagree with myself ;)
Am 12.09.2010 um 14:51 schrieb Max Horn: [...] > > Of course, any approach should only be done if it can't be avoided by > non-root users. > > OK, I'll try to compare both approaches (if done properly), the suid-chown > and the deleyed-chown approach, as well as what Fink currently does, under > the following assumptions: > * The suid-chown would be owned by fink-bld and have flags 600, so only > fink-bld can execute it. It would only modify files in the build dir. > * The delayed-chown tool would be the same; the delayed logging would not > change the fact that the evil user could taint a file in the build dir. > > In all three scenarios (suid-chown, delayed-chown, and current --b-a-n code), > if users can execute stuff as fink-bld, they can do the following > 1) Log onto the victim's machine > 2) Wait for a Fink package to be built (or rather, let a script do that and > the rest for you ;) > 3) Once a Fink build starts, insert a suid executable (say a shell) with mode > 777 into the build dir > 4a) If this is sudo-chown execute, it right away and become root; > 4b) If this is not, wait for the .deb to be completed, and installed; then > become root. > > In conclusion, the suid-chown approach is worse (and always will be), as it > could cause a "bang" even if the package is not going to be installed. This > is import for e.g. a build server in build farm! Actually, on second thought, all three approaches have equivalent security: For all of them there is a slight time window where a chown has happened, and the file is sitting on the HD... So consider this attack approach: chmod the bad binary, and all its parent directories, to be 777 accessible (and of course make your bad binary suid). Then, at some point chown is executed to set the binary (and everything above it) to be owned by root:admin. After that, you have a brief moment where you can run this binary. The time this is the case can be quite considerable for a big package (where building the .deb takes substantial time), and an attacker can easily extend this time by creating lots of directories / huge files in the builddir. In conclusion, it seems to me that if done right, all three approaches have equivalent security, and crucial depend on "fink-bld" being "safe". In theory, taking over fink-bld should not be easier than taking over root, so I am quite hopeful... :) Bye, Max ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
