From: Wybo Dekker <wybo@...4all.nl>
Date: 2012-07-27T07:16:16+09:00
Subject: Re: rubyzip gem overwrites write-protected root-owned file

On 2012-07-26 22:17, Chad Perrin wrote:
> On Thu, Jul 26, 2012 at 07:21:19PM +0900, Wybo Dekker wrote:
>> On 2012-07-24 16:44, Quintus wrote:
>>> Am 24.07.2012 14:44, schrieb Wybo Dekker:
>>>> I'm playing with the rubyzip gem, and found, with this little script:
>>>>
>>>> require 'rubygems'
>>>> require 'zip/zip'
>>>> Zip::ZipFile.open('test.zip', Zip::ZipFile::CREATE) do |zipfile|
>>>>     zipfile.add('rgb.txt','/etc/X11/rgb.txt')
>>>> end
>>>>
>>>> that 'test.zip' is written without any warning, even if it exists, is
>>>> root-owned and write-protected. Is that a bug?
>>>
>>> If you can overwrite a root-owned file not writable by neither a group
>>> you’re in nor for others (i.e. something like rw------- root:root), then
>>> you have a serious security problem (which has nothing to do with Ruby).
>>> Check your system settings (and you’re sure you don’t run this as root?).
>>
>> Well, if I try to add a file using the system zip, I am not allowed to
>> do so:
>>
>> $ zip test.zip /etc/passwd
>> zip I/O error: Permission denied
>> zip error: Could not create output file (test.zip)
>>
>> So what I think happens is that Rubyzip, instead of adding a file to the
>> zip, as requested, creates a new zip, deletes the old one (which is
>> allowed in a directory which I own) and the renames the new zip to the
>> old filename, thus effectively removing the old zip's ownership and
>> permissions.
>> I think that is not how it should work...
> 
> There is something *seriously* wrong with your system if a program run as
> a nonprivileged user is able to overwrite files owned by root for which
> root is the only user that has write permissions.  Unless the Ruby
> program in question, or your Ruby interpreter itself, has the suid bit
> set, it seems the problem is with the system somehow, because this is a
> clear violation of privilege separation.  There is no way a mere bug in a
> program run as a nonprivileged user should allow it to violate system
> privilege separation.

I don't agree.
First, look at http://www.tuxfiles.org/linuxhelp/filepermissions.html,
which says:
Write permission. On a regular file, this means you can modify the file,
aka write new data to the file. In the case of a directory, the write
permission means you can add, remove, and rename files in the directory.
This means that if a file has the write permission bit, you are allowed
to modify the file's contents, but you're allowed to rename or delete
the file only if the permissions of the file's directory allow you to do so.

Second, see
http://www.faqforge.com/linux/how-to-prevent-that-a-user-deletes-a-file-owned-by-root-in-its-home-directory/

Third, go to your own home directory, or better: start  a linux live cd,
and try the following:

echo test >t
chmod 0 t
sudo chown root.root t
ls -l t
rm -f t

Your root-owned write-protected t will have disappeared without any
warning. Note that, without the -f option for rm, you get a warning:
rm: remove write-protected regular file `t'?
and you need to type y to remove the file.

-- 
Wybo