If I have a user on a unix system where Im allowed to create new files, what prevents me from downloading an executable file onto that system which is already SUID'ed to root on a different system?
Scenario:
What prevents this file from running as root on the first shell I logged into?
When you copy a file to a different filesystem, what's going on under the hood is that a you create a new file and copy the contents. Moving a file to a different filesystem is done by copying then removing the source. So you have no more privileges when copying a file than at any other time you're creating a file.
When you create a file, it belongs to you. Many unix variants restrict changing the owner (chown) to root. Even those that allow the owner of a file to give it away clear the setuid and setgid bits when doing so. Group ownership changes (chgrp) also clear away the setxid bits unless invoked with root privileges. And you need to own the file or be root to change its permissions. So you can't create a setxid file for a user or group you don't have permission to run programs as.
A different vector for setxid file injection is filesystem mounting. Most configurations only allow the setxid bits on filesystems directly mounted by root (as opposed /etc/fstab entries with the user option on Linux, Samba, FUSE, …). Sometimes, for example with NFS mounts, it's up to the system administrator to ensure that filesystems are mounted with the nosuid option.
UPDATE: please ignore my previous misguided answer, which I've edited out here to avoid confusing folks. Gilles has a much better answer, which I could incorporate here or rephrase, but he deserves the credit....
If you really want to see what I had before, you can as always find it in the edit history by clicking on the time of edit.
You get close to this behavior when you download someone's tarball and extract it, 'preserving ownership/permissions' if the uid is 7544 you will see that uid for the files you untar if you are root, likely errors if your a non privileged user.
