Упражнение по ACL из курса компьютерной безопасности

Я написал ответ, но это похоже на "домашнее задание". Я не считаю это плохим, но я предлагаю предоставить подробности о том, что вы выяснили до сих пор, задавая такие вопросы. Это может как получить наиболее полезные ответы, так и помочь вам объединить педагогические преимущества, предусмотренные инструктором, с преимуществами, предоставляемыми интернет-сообществами - например, информируя нас о том, что вы уже изучили и еще не изучили, или сделав так, чтобы вы все еще можете выяснить некоторые решения самостоятельно.

ACL расшифровывается как Access Control List. Кажется, что проблема здесь связана с обычными разрешениями в стиле 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 в файлах.)

Для получения дополнительной информации о ACL в Ubuntu см. FilePermissionsACL. Что касается других вопросов, подробный анализ следует.

Во-первых, некоторые комментарии о том, что придумано в этой проблеме, чтобы помочь нам помнить о видах вещей, которые являются обычными в упражнениях, но не должны игнорироваться, если встречаются "в поле".

В реальной жизни это вряд ли то, на чем было сосредоточено упражнение:

• Пользователь называется foo на производственной системе странно.
  (Хотя, возможно, это принадлежит Фордхему Оо, младшему)

  И, что более важно, пользователь по имени user (как указано в $PS1) в принципе никогда не бывает хорошей идеей.

  Эти имена, скорее всего, будут интерпретированы метасинтаксически при общении между коллегами, и даже могут быть случайно обнаружены таким поздно ночью системным администратором, который борется с большей частью не связанной с этим проблемой.

• Точно так же группа под названием group в принципе никогда не хорошая идея.

• Файл называется dangerous.exe чья история, о которой я не знаю, вызывает тревогу. Это либо неправильно названо, либо, может быть, оно не должно валяться.

Теперь о том, что в этой ситуации обычно будет главной проблемой, связанной с безопасностью.

Как в реальной жизни, так и, вероятно, в голове того, кто написал вопрос:

• s в -rwsr-xr-x средства dangerous.exe исполняемый файл setuid Это может быть сделано с chmod:

  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 а не как себя!

• Для того чтобы файл был безопасно установлен (или установлен), он должен быть тщательно написан, чтобы гарантировать, что он может использоваться только для выполнения соответствующих действий. Например, /usr/bin/passwd исполняемый файл, который запускается, когда пользователь меняет свой пароль с passwd Команда является setuid и принадлежит пользователю root, поэтому даже если ее запускает пользователь с ограниченными правами, он запускается как root. Это необходимо для внесения изменений в базу паролей. Но он тщательно написан, чтобы вносить только авторизованные изменения.

  В зависимости от того, какие привилегии foo в системе, это, вероятно, менее серьезная проблема, чем если бы у исполняемого файла setuid, принадлежащего пользователю root, была ошибка, позволяющая использовать его непреднамеренным образом. Но это все еще повод для тревоги.

  Если вы были системным администратором в этой ситуации, вы можете проконсультироваться с пользователем foo чтобы увидеть, если разрешения они установили dangerous.exe были ошибкой (В зависимости от контекста и других элементов ситуации вы можете предпринять более немедленные действия.)