360 for Linux 与 setuid
时间:2015-01-04 22:40 来源:linux.it.net.cn 作者:IT
前言
今日，国内著名安全类软件 360 正式进军 Linux 平台，目前已提供 Debian/Ubuntu/Deepin 以及中标麒麟的预编译二进制。而包括我在内的吃螃蟹者都不同程度地注意到了 360 for Linux 的二进制在正常状况下被设置了 setuid 位。即 4755 权限。如 http://www.v2ex.com/t/158380#reply27 以及 http://tieba.baidu.com/p/3499343332
图： 360 for Linux 的权限位
如图所示，这是我在 VirtualBox OSE 中安装的 Lubuntu 14.10 中的 360 for Linux 安装后的权限位， ls 已经将其标红并且显示权限位为 -rwsr-xr-x (4755) 。下面就 setuid 以及其作用展开一些推论。
什么是 setuid 以及相关的安全隐患
setuid 以及 setgid 是 UNIX 环境下的特殊权限位。当作用于可执行文件时，该权限位将导致无论以何用户启动，该可执行文件将拥有其所有者的权限。如 /usr/bin/sudo 的拥有者为 root 且权限为 4755, 那么即使一个非 root 用户执行了 sudo, 其依然会拥有 root 的权限，如读取 /etc/shadow 文件 (-r————, root:root) 的权限。对于用户而言，其最直接的意义在于合法的无密码提权。这使得一般使用该特性的程序都被小心设计以免不测。因为如果设计不当，攻击者可能可以在不需要任何密码的情况下轻松夺取对目标系统的最高权限。基于同样的原因，包括 Linux 在内的部分操作系统会忽略设置在脚本文件上的 setuid/setgid 位。对于普通用户而言，一个被 setuid/setgid 了的恶意可执行文件将能够在不盗取密码的情况下破坏整个系统（尤其是当类似 TOMOYO Linux 的强制访问控制系统没有正确设置时）。因而一般情况下开发者以及系统管理员都会谨慎处理这一特殊权限。如在 Debian 中，可以通过对 man 程序设置 setuid 位来加快 man-db 索引但是由于可能带来的安全隐患该选项必须在安装过程中由用户启用。
360 for Linux 对 setuid 应用的利弊分析
setuid 位最直接的用处是允许 360 for Linux 在不被用户注意的情况下以 root 权限允许。一方面，这将免除用户每次开机都要输入密码的麻烦；另一方面，由于用户无法察觉，该程序可能在有意无意之中对系统造成无法修复的破坏或者成为其他恶意软件入侵系统的跳板（比如 Windows 上的 Sony BMG CD 反拷贝程序由于设计不良就成为了其他恶意软件的跳板）。同时，如果该程序留有（可能存在）的后门，用户也无法从 UNIX 权限系统得到应有的保护。
图：部分使用了 setuid 的程序。这些程序并非全部都需要该权限位，部分程序可以改用 PolicyKit 来实现提权。
PolicyKit 与无密码提权一些想法
图： GNOME PackageKit 使用 PolicyKit 进行有密码提权以删除软件包
图： Windows UAC 对需要 Administrator 权限的 Acronis True Image 进行提权前提示用户输入凭据
我们必须承认，无密码提权在一定程度上方便了用户，但与此同时这种行为也埋下了安全隐患。比如在 AOSC OS2 时代， AnthonOS 默认 sudo 可以进行无密码提权但是这一设定以及因为潜在的安全风险被禁止了。
在很多时候，密码是给用户知情权与选择权。用户知道一个程序要提权并且用户也有选择去拒绝他所不信任的提权请求。同时，如果用户如果对某个先前的决定反悔或发现其为误操作，此时也可以阻止该行为的继续以避免损失。
360 这种行为则涉嫌向用户隐瞒自身的提权行为。这也许只是为了方便用户，也有可能有其他企图。
而如果只是为了避免在 Windows Vista 时代的尴尬，也就是每次开机都出现授权弹窗，也不一定需要使用 setuid 这一有严重安全隐患的方法。 PolicyKit 提供了一套将程序分离为以特权权限运行和以非特权权限运行的两部分并且进行互相沟通的机制。比如 GNOME PackageKit 本身以非特权运行，其通过 PolicyKit 发起需要特权的请求并由 PolicyKit 决定是否需要用户参与提权。而在 Windows 平台上，Avira 旗下的安全产品的主界面并不需要以特权启动，而仅在更改设定或关闭/开启监控时通过 UAC 进行提权，避免了开机时弹出交互式授权对话框的尴尬。
结语
综上所述， 360 for Linux 使用 setuid 可能有其原因。但是鉴于 setuid 本身巨大的隐患，建议用户现阶段慎重使用该软件。我本人也呼吁现在与或即将与奇虎有合作的厂商对 360 for Linux 本身进行全面的安全审计以防被居心叵测者利用或者可能存在后门。与此同时，我本人也建议 360 for Linux 使用标准的 PolicyKit 架构，实现特权部分与非特权部分的分离，并且给用户适当的提示以满足其知情权和选择权。
(责任编辑：IT)
前言今日，国内著名安全类软件 360 正式进军 Linux 平台，目前已提供 Debian/Ubuntu/Deepin 以及中标麒麟的预编译二进制。而包括我在内的吃螃蟹者都不同程度地注意到了 360 for Linux 的二进制在正常状况下被设置了 setuid 位。即 4755 权限。如 http://www.v2ex.com/t/158380#reply27 以及 http://tieba.baidu.com/p/3499343332
图： 360 for Linux 的权限位 如图所示，这是我在 VirtualBox OSE 中安装的 Lubuntu 14.10 中的 360 for Linux 安装后的权限位， ls 已经将其标红并且显示权限位为 -rwsr-xr-x (4755) 。下面就 setuid 以及其作用展开一些推论。 什么是 setuid 以及相关的安全隐患setuid 以及 setgid 是 UNIX 环境下的特殊权限位。当作用于可执行文件时，该权限位将导致无论以何用户启动，该可执行文件将拥有其所有者的权限。如 /usr/bin/sudo 的拥有者为 root 且权限为 4755, 那么即使一个非 root 用户执行了 sudo, 其依然会拥有 root 的权限，如读取 /etc/shadow 文件 (-r————, root:root) 的权限。对于用户而言，其最直接的意义在于合法的无密码提权。这使得一般使用该特性的程序都被小心设计以免不测。因为如果设计不当，攻击者可能可以在不需要任何密码的情况下轻松夺取对目标系统的最高权限。基于同样的原因，包括 Linux 在内的部分操作系统会忽略设置在脚本文件上的 setuid/setgid 位。对于普通用户而言，一个被 setuid/setgid 了的恶意可执行文件将能够在不盗取密码的情况下破坏整个系统（尤其是当类似 TOMOYO Linux 的强制访问控制系统没有正确设置时）。因而一般情况下开发者以及系统管理员都会谨慎处理这一特殊权限。如在 Debian 中，可以通过对 man 程序设置 setuid 位来加快 man-db 索引但是由于可能带来的安全隐患该选项必须在安装过程中由用户启用。 360 for Linux 对 setuid 应用的利弊分析setuid 位最直接的用处是允许 360 for Linux 在不被用户注意的情况下以 root 权限允许。一方面，这将免除用户每次开机都要输入密码的麻烦；另一方面，由于用户无法察觉，该程序可能在有意无意之中对系统造成无法修复的破坏或者成为其他恶意软件入侵系统的跳板（比如 Windows 上的 Sony BMG CD 反拷贝程序由于设计不良就成为了其他恶意软件的跳板）。同时，如果该程序留有（可能存在）的后门，用户也无法从 UNIX 权限系统得到应有的保护。
图：部分使用了 setuid 的程序。这些程序并非全部都需要该权限位，部分程序可以改用 PolicyKit 来实现提权。 PolicyKit 与无密码提权一些想法
图： GNOME PackageKit 使用 PolicyKit 进行有密码提权以删除软件包
图： Windows UAC 对需要 Administrator 权限的 Acronis True Image 进行提权前提示用户输入凭据 我们必须承认，无密码提权在一定程度上方便了用户，但与此同时这种行为也埋下了安全隐患。比如在 AOSC OS2 时代， AnthonOS 默认 sudo 可以进行无密码提权但是这一设定以及因为潜在的安全风险被禁止了。 在很多时候，密码是给用户知情权与选择权。用户知道一个程序要提权并且用户也有选择去拒绝他所不信任的提权请求。同时，如果用户如果对某个先前的决定反悔或发现其为误操作，此时也可以阻止该行为的继续以避免损失。 360 这种行为则涉嫌向用户隐瞒自身的提权行为。这也许只是为了方便用户，也有可能有其他企图。 而如果只是为了避免在 Windows Vista 时代的尴尬，也就是每次开机都出现授权弹窗，也不一定需要使用 setuid 这一有严重安全隐患的方法。 PolicyKit 提供了一套将程序分离为以特权权限运行和以非特权权限运行的两部分并且进行互相沟通的机制。比如 GNOME PackageKit 本身以非特权运行，其通过 PolicyKit 发起需要特权的请求并由 PolicyKit 决定是否需要用户参与提权。而在 Windows 平台上，Avira 旗下的安全产品的主界面并不需要以特权启动，而仅在更改设定或关闭/开启监控时通过 UAC 进行提权，避免了开机时弹出交互式授权对话框的尴尬。 结语综上所述， 360 for Linux 使用 setuid 可能有其原因。但是鉴于 setuid 本身巨大的隐患，建议用户现阶段慎重使用该软件。我本人也呼吁现在与或即将与奇虎有合作的厂商对 360 for Linux 本身进行全面的安全审计以防被居心叵测者利用或者可能存在后门。与此同时，我本人也建议 360 for Linux 使用标准的 PolicyKit 架构，实现特权部分与非特权部分的分离，并且给用户适当的提示以满足其知情权和选择权。 (责任编辑：IT) |