主页 / ubuntu / 问题 / 523956
Accepted
Davide
Asked: 2014-09-15 08:11:02 +0800 CST

来自计算机安全课程的 ACL 练习

  • 772

您发现此文件位于系统上：

[user@localhost]$ ls -la executable -rwsr-xr-x 1 foo group 41836 2012-10-14 19:19 dangerous.exe

你注意到有什么不对吗？

acl

1 个回答

  1. Best Answer

    我已经写了一个答案，但这似乎是一个“家庭作业”问题。我不认为那很糟糕，但我确实建议您在提出此类问题时提供有关您到目前为止所了解的内容的详细信息。这既可以为您提供最有用的答案，也可以帮助您将教师预期的教学优势与 Internet 社区提供的教学优势结合起来——例如，通过告知我们您已经学过和尚未学过的知识，或者让您知道仍然可以自己找出一些解决方案。

    ACL 代表访问控制列表。这里的问题似乎与普通的 Unix 风格权限有关（另请参见FilePermissions），而不是 ACL。具体来说，这是一个关于 setuid 可执行文件以及 组和其他类的可执行权限位的练习。（如果这是您当前正在做的练习，那么这可能足以为您解决问题提供线索。）

    为什么我认为这（也）与 ACL 无关？在 的输出中没有关于文件上设置的 ACL 的信息ls -l。即使 存在与 ACL 相关的问题dangerous.exe，也没有提供指向或以其他方式暗示它的信息。

    此外，至少在 Ubuntu 中，ls检查文件的权限是否通过 ACL 自定义，如果是，则附加+到符号权限字符串的末尾。

    ek@Ilex:~$ ls -l foobar                  # no + in the output of ls
-rw-rw-r-- 1 ek ek 0 Sep 14 13:16 foobar
ek@Ilex:~$ setfacl -m g:adm:r foobar
ek@Ilex:~$ ls -l foobar                  # now there's a + in the output
-rw-rw-r--+ 1 ek ek 0 Sep 14 13:16 foobar

    （但请注意，可能有一些类 Unix 系统具有不同的 ACL 实现和/或默认ls可执行文件不检查文件上是否存在 ACL 规则。）

    有关 Ubuntu 中 ACL 的更多信息，请参阅FilePermissionsACLs。至于其他问题，具体分析如下。

    首先，对问题的设计进行一些评论，以帮助我们记住练习中常见的事情，但如果在“现场”遇到，则不应忽略这些事情。

    在现实生活中，尽管这不太可能是练习的重点：

    • 调用foo生产系统的用户很奇怪。
      （虽然它可能属于 Fordham Oo, Jr.）

      而且，更极端的是，调用user（如中所示$PS1）的用户基本上从来都不是一个好主意。

      这些名字很可能在同事之间的交流中被元句法解释，甚至可能在深夜被一个正在努力解决一个几乎不相关的问题的系统管理员以这种方式无意中看到。

    • 同样，调用的组group基本上也不是一个好主意。

    • dangerous.exe一个我不知道其历史的文件令人震惊。它要么命名不当，要么不应该随意使用。

    现在，在这种情况下，通常与安全相关的主要问题是什么。

    在现实生活中，可能在写这个问题的人的脑海中：

    • sin意味着是一个 setuid 可执行文件。这可以通过以下方式完成：-rwsr-xr-xdangerous.exechmod

      ek@Ilex:~$ ls -l dangerous.exe 
-rwxr-xr-x 1 ek ek 0 Sep 14 12:29 dangerous.exe
ek@Ilex:~$ chmod u+s dangerous.exe
ek@Ilex:~$ ls -l dangerous.exe
-rwsr-xr-x 1 ek ek 0 Sep 14 12:29 dangerous.exe

      因为dangerous.exe是 setuid，所以无论谁执行它，它都以其所有者的身份运行。偶尔这是合适的，但除非谨慎谨慎地使用，否则它会导致非常严重的安全问题，从而促进对拥有可执行文件的帐户的意外访问。

    • 但这还不是全部。我们知道这特别有可能出现安全问题。（如果系统上运行的任何用户或服务应该被阻止做事情foo是能够做的，那就是。这是可能的。请记住，只有一个人类用户的系统默认情况下会使用其他用户帐户由系统以降低的权限执行操作。）

      这是由于在 上设置了其他权限dangerous.exe。由于其可执行位的设置方式，任何人都可以执行dangerous.exe！

      -rwsr-xr-x 1 foo group 41836 2012-10-14 19:19 dangerous.exe
      |   \
      \    This x indicates all users other than foo and members of
       \   'group' may execute the file! That's almost definitely bad!
        \
          This x indicates anyone in the 'group' group may execute the
          file. Depending on what the 'group' group means and who's in
          it, that might be bad.

      我们如何通过检查知道这一点-rwsr-xr-x 1 foo group 41836 2012-10-14 19:19 dangerous.exe？第一个字符（-用于普通文件、d目录和l符号链接）之后是九个字符。

      前三个表示拥有该文件的用户是否可以r读取、写入w和x执行它。（-当答案为否时出现 A。）下一组三人表示文件组所有者的成员（用户所有者除外）是否可以r读、写w和x执行它。最后一组三人说如果其他用户既不拥有文件也不在其组所有者中，可以r读取、写入w和x执行它。

      因此，系统上的所有用户都可以运行dangerous.exe——当他们这样做时，他们是在运行系统foo而不是他们自己！

    • 对于要安全设置为 setuid（或 setgid）的文件，必须仔细编写以确保它只能用于执行适当的操作。例如，/usr/bin/passwd当用户使用命令更改密码时运行的可执行文件passwd是 setuid，并且由 root 拥有，因此即使受限用户运行它，它也会以 root 身份运行。这是必要的，因为它可以更改密码数据库。但它经过精心编写，因此只会进行授权更改。

      根据在foo系统上拥有的权限，与 root 拥有的 setuid 可执行文件存在允许以非预期方式使用它的错误相比，这可能是一个不太严重的问题。但这仍然是引起恐慌的原因。

      如果您是这种情况下的系统管理员，您可能希望咨询用户foo，看看他们设置的权限是否dangerous.exe有误。（根据情况的背景和其他因素，您可能会采取更直接的行动。）

    • 1

相关问题