Am 12.09.2010 um 12:58 schrieb Sjors Gielen:
>
> Op 12 sep 2010, om 09:33 heeft Max Horn het volgende geschreven:
>
>> Here is one idea: Maybe we could insert our own custom chmod/chown scripts
>> into the PATH used for building packages, with suid flag set, so that they
>> can invoke the original chmod/chown with the appropriate rights. Of course
>> that punches a hole into the "non-root" approach, but a relatively small one
>> (as long as we don't do --b-a-n to prevent security holes, this is not a big
>> issue, anyway).
>> We could also try to avoid that hole by filtering the path arguments passed
>> to our chmod/chown/chgroup commands, to only accepts paths inside the build
>> dir (or even only in the install dir). For that, in turn, some care would
>> have to be taken to make sure callers can't "punch out" by using clever
>> combos of ".." and symlinks. That could be done by using "readlink -f PATH"
>> on each of the paths passed to the chmod util before matching it against the
>> /sw/src/fink.build/%n-%v-%r prefix (or whatever the build dir is set to).
>
> I see your point, but I worry whether this doesn't actually make it worse.
> It's quite a huge security risk.
I agree that it is a potential security risk, so it shouldn't be done lightly.
On the other hand, I believe that if engineered properly, it could be made
safe. Essentially, if those custom scripts/tools must not be available to
users other than fink-bld, as Daniel pointed out. If that is guaranteed, I see
no problems left.... or not?
> But if we do go with it: I'd propose not to make it suid root, but to make it
> hold a list of files to change ownership or mode; then after the build is
> done; instead of running a chown -R root:admin as Daniel said...
Nice idea. It would indeed be easier to write in a way that I would believe to
be truly safe!
But I am not sure it can be made to work in general? Just think of the case
where a tool first chowns a file, then moves it. We could of course try to
track *every* file perm modification, by also tracking mv and cp -p (and maybe
more?). That sounds like a lot of work, and possibly an open-ended task, too,
depending on whether we really can enumerate (and then "fake") all involved
tools.
It sounds a bit like a "fakeroot light" approach (see bottom of my email for
details on that).
Anyway: This problem would also affect the "suid chown" approach I proposed,
but in a different way: If a package tried to move/copy around already
"installed" files, it would also break (e.g. if a tool first chowns a dir to
another user, then tries to copy something into the chownd dir). The difference
is that the former breakage is "silent" (i.e. easily sneaks in without being
noticed), while the latter is "noisy" (it causes a build failure). I can
tolerate potentially noisy breakage, but silent breakage is an absolute no-go.
Still, in any case: The "chown dir then cp/mv file into it" pattern might spell
doom to "suid chown" if it occurs a lot (if it occurs super rarely, then the
few affected packages would not be off worse than they are now).
>
> Op 12 sep 2010, om 10:10 heeft Daniel Macks het volgende geschreven:
>
>> Currently
>> (approximately), --b-a-n switches to fink-bld for InstallScript and
>> related actions, then 'chown -R root:admin $builddir' so that it is
>> back to the normal state for live filesystem files. If we have chown'ed
>> files to (for example) games, that would wipe the ownership anyway.
>
> ... Just do a chown -R root:admin, *then* apply the changes in the list, and
> you will have a guarantee that things are fine.
Yeah, that would indeed be elegant!
Though note that the alternative is not very difficult either:
find $builddir -user fink-bld -exec chown root {} ;
find $builddir -group fink-bld -exec chgrp admin {} ;
> Something to watch for, though: If the new `chown` and `chmod` wrappers do an
> extensive check of the path to modify, then this check needs to be done just
> before making the actual change too, or there will be race conditions. But
> either way, I think having potential security risks is worse than having
> potential weird installation issues in the PostInstScript...
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!
> How does Debian solve this problem? They have non-root build machines, right?
Good question... Anybody know?
They used to have a tool called "fakeroot" for allowing non-root users to build
packages (we used to contemplate porting that to Mac OS X, but that's hard, as
the tool is system specific). But I don't know whether that (a) was ever used
for build machines (indeed, whether that is even possible, see below), and (b)
whether they still use it at all. Its homepage (or what I believe to be its
homepage) <http://fakeroot.alioth.debian.org/> looks as if it was last modified
in 2003. Then again, I googled a bit and Ubuntu also has a package for it which
seems to be actively maintained: <https://launchpad.net/fakeroot>...
*But* I am not even sure whether it can be used to build packages that contain
correct ownership info -- or whether it can only be used to build package as
non-root that are then installed as non-root (I highly suspect that the latter
is the case, but don't know for sure).
Besides fakeroot, there is fakeroot-ng (as I just learned), on
<http://fakeroot-ng.lingnu.com>. Both apps are highly system specific and thus
difficult to port to anything not Linux. We actually looked into porting this a
long time ago (see e.g.
<http://fink.cvs.sourceforge.net/fink/experimental/bcully/fakeroot.patch?revision=1.1&view=markup>;
for a more recent attempt, see
<http://lists.apple.com/archives/carbon-dev/2009/Oct/msg00092.html>).
Both work, roughly, by intercepting system calls and using that to track e.g.
file permission changes; thinks like "chown root:admin XYZ" are then not
actually performed, but still recorded; return values of e.g. stat() are then
tweaked so that the client program believes its changes were executed as
desired. Combining this with chroot allows building .debs as non-root.
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
