This can be a real security hole, at least when you are not aware of 
it (I have just discovered a working way to exploit it on one of my 
machines).

dpkg-buildpackage makes a semi-real "make install" into a sub 
directory of the debian/ directory in the source dir, and then tar's 
the installed files. The installed files have the real final 
permissions, which may include suid/sgid bits. The debian build 
programs do *NOT* protect the subdir, thus it may be entered by 
anyone on the system who has access to the source tree and he may 
execute the binaries therein. Since programs sometimes make 
assumptions about where they are installed, or which libraries they 
link at runtime, it is not safe to execute them from there.

Now you may say "don't build packages as root, use fakeroot instead". 
Well I have always used it, and somehow thought I'm safe, but I'm 
not: the permissions modes (like 4755) make it through to the real 
filesystem, only the owner/group is faked. Thus I'm left with 
binaries setuid *me* or setgid *my group* afterwards. That's only 
slightly better than root, since I'm also the admin and once my 
account is hijacked it's not far from being root.

It seems the only way around this (currently) is to compile packages 
in a directory with 0700 permissions.

I could think of two ways to improve this situation:
a) change fakeroot so it doesn't write the set[gu]id bits to disk 
(esp. if the faked owner/group differs from the real owner/group).
b) change the debian build process so it creates the temp folders 
with 0700 permissions.

Christian.

(BTW a somewhat similar problem (but not debian specific) exists with 
the perl CPAN module build process: -MCPAN is designed to work as 
root. It downloads the tarball, extracts it (with the user/group that 
the author packed them) as root, thus you are left with files 
belonging to random system users. -MCPAN doesn't take any precautions 
to protect the .cpan/build/ folder, thus with a bit luck some user on 
the system can modify the unpacked files before they are 
built/installed by root.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to