Making DO_POSIX_CP configurable

[Denys Vlasenko]

On Tuesday 11 September 2007 14:53, Ralf Friedl wrote:
> Hi Denys
> 
> Can you point to real security problems from the use of cp with POSIX 
> semantics?

User comes to you and says "I accidentally deleted my most important
directory. I know that you make daily backups. Can you restore
it from backup?"

You do

cp -a /backup/home/user/dir /home/user

But user has crafted it so that backup contains
dir/many_more_dirs/innocuous_file, and he also
created a symlink

ln -s /etc/passwd /home/user/dir/many_more_dirs/innocuous_file

Now imagine the effect of the above cp command.

> I know, the target of the copy operation could be a symbolic link to 
> some other file that would be overwritten. This would require the 
> attacker to have write permissions to the target directory and would 
> require cp to be used without the -i option. Normally, only /tmp is 
> world writable, and there is not much reason to copy files from 
> elsewhere to /tmp.

The attacker don't write file himself. He tricks root into doing it.

> As most systems come with a POSIX compatible cp program, I think it 
> would be widely known if that was a serious security risk.

How do you realistically imagine admin making safe recursive cp
into user-owned directories?

GNU coreutils have cp --remove-destination. I think people
will forget to use it until it's too late.

I want to achieve a solution which is both reasonably secure
and convenient. POSIX is insecure. busybox 1.7.0
is a bit inconvenient. Current svn is better - it detects
"cp file device_node".

> If you really think it is a security risk to write to the user specified 
> file, that would also be the case for every other program that writes to 
> a file.

But programs run by root typically don't open *other user's* files for writing.
They open e.g. /var/log/something. See the difference?

> Especially, by first unlinking the file, you break the following 
> assumptions in contrast to POSIX Semantic:
> - If the target file is a special file (block, character or pipe), the 
> special file is replaced with a regular file.
> - The owner and permissions of the target file are not preserved.
> - properties like acl oder user_xattr of the target file are not preserved.
> - hard links of the target file are not preserved.

I see that for "cp file1 file2" it is a problem,
but for "cp -r dir1 dir2" it is exactly what you want. right?

We can differentiate on that, and current svn does.
If you have proposals how to improve more, I'm all ears.

For your convenience, I attached current svn's copy_file.c.
Curretly it has this:

        if (S_ISREG(source_stat.st_mode)) {
...
                /* POSIX way is a security problem versus symlink attacks,
                 * we do it only for dest's which are device nodes,
                 * and only for non-recursive, non-interactive cp. NB: it is still racy
                 * for "cp file /home/bad_user/device_node" case
                 * (user can rm device_node and create link to /etc/passwd) */

                if (DO_POSIX_CP
                 || (dest_exists && !(flags & (FILEUTILS_RECUR|FILEUTILS_INTERACTIVE))
                     && (S_ISBLK(dest_stat.st_mode) || S_ISCHR(dest_stat.st_mode)))
                ) {
                        dst_fd = open(dest, O_WRONLY|O_CREAT|O_TRUNC, source_stat.st_mode);
                } else  /* safe way: */
                        dst_fd = open(dest, O_WRONLY|O_CREAT|O_EXCL, source_stat.st_mode);
                if (dst_fd == -1) {
                        ovr = ask_and_unlink(dest, flags);

DO_POSIX_CP is currently hardcoded to 0, and serves a a documentation
"what would POSIX cp do".
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy_file.c
Type: text/x-csrc
Size: 10670 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20070911/e67116af/attachment-0002.c