如果我在允许创建新文件的 unix 系统上有一个用户,那么是什么阻止我将可执行文件下载到该系统上,该系统已经 SUID'ed 到另一个系统上的 root?
设想:
- 我用我的用户 Karrax (box1) 登录了一个 shell
- 在我已经是 root 的另一个系统(box2)上,我在可执行文件上设置了 SUID root
- 然后我将文件传输/复制到 box1
是什么阻止了这个文件在我登录的第一个 shell 上以 root 身份运行?
如果我在允许创建新文件的 unix 系统上有一个用户,那么是什么阻止我将可执行文件下载到该系统上,该系统已经 SUID'ed 到另一个系统上的 root?
设想:
是什么阻止了这个文件在我登录的第一个 shell 上以 root 身份运行?
当您将文件复制到不同的文件系统时,幕后发生的事情是您创建一个新文件并复制内容。将文件移动到不同的文件系统是通过复制然后删除源来完成的。因此,您在复制文件时没有比在任何其他时间创建文件时更多的权限。
当您创建文件时,它属于您。许多 unix 变体限制将所有者 ( chown
)更改为 root。即使是那些允许文件所有者放弃它的人,也会在这样做时清除 setuid 和 setgid 位。chgrp
除非以 root 权限调用,否则组所有权更改 ( ) 也会清除 setxid 位。您需要拥有该文件或以 root 身份更改其权限。因此,您无法为无权运行程序的用户或组创建 setxid 文件。
setxid 文件注入的另一个向量是文件系统安装。大多数配置只允许在由 root 直接挂载的文件系统上设置 setxid 位(与Linux、Samba、FUSE 等/etc/fstab
带有选项的条目相反)。user
有时,例如使用 NFS 挂载,系统管理员需要确保使用该nosuid
选项挂载文件系统。
当您下载某人的 tarball 并将其解压缩时,您将接近此行为,如果 uid 为 7544,则“保留所有权/权限”如果您是 root,您将看到解压文件的 uid,如果您是非特权用户,则可能会出错。
更新:请忽略我之前被误导的答案,我在这里编辑了它以避免混淆人们。吉尔斯有一个更好的答案,我可以在这里合并或改写,但他值得称赞....
如果你真的想看看我之前的内容,你可以像往常一样通过点击编辑时间在编辑历史中找到它。