проблема безопасности Linux sudo команда?

Это не дыра в системе безопасности по крайней мере не больше, чем su .

sudo только имеет путь к администратору для того, чтобы иметь быстрый корневой доступ, не используя корневую оболочку (который может быть опасным).

sudo просто требует, чтобы пользователь ввел свой собственный пароль, и действительно предоставит ему корневой доступ (попытка $ sudo whoami). Однако не все должны быть в /etc/sudoers файл.

Если Вы смотрите на sudo страница справочника, Вы найдете, как ограничить sudo к некоторым простым командам.

Можно, например, только позволить пользователю bob выполниться $ sudo poweroff не позволяя ему сделать $ sudo cat /etc/shadow.

Так не, это не дыра в системе безопасности, если Вы настраиваете и используете его правильно. Если Вы не хотите, чтобы у Ваших пользователей была корневая оболочка, думайте о запрещении команд как $ sudo su.

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

Поскольку только корень может настроить его так или иначе, нет никакой дыры в системе безопасности. Корень настраивает, у кого есть доступ к нему, кто должен вставить который пароль, для каждого пользователя, для каждой группы.

Кроме того, о последней части: "так как пользователи кроме корня могли работать с полномочием пользователя root": это - смысл sudo программы.

sudo безопасен потому что:

1. пользователь root или другой sudo-поддерживающий пользователь (кто может выполнить 'visudo' или '/etc/sudoers' $EDITOR) должны изменить/etc/sudoers для предоставления полномочий.

2. Можно ограничить и указать точно, что человек может выполнить с полномочиями пользователя root, который позволяет иметь переменные уровни администраторских пользователей на сервере.

3. Как привилегированный пользователь можно просмотреть существующий/etc/sudoers файл, для наблюдения, у каких пользователей есть полномочия.

4. Вы не должны совместно использовать пароль root среди команды администраторов.

5. Существует полный учет того, что сделано с командой sudo, обеспечив ясный журнал аудита

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

Действительно необходимо ограничить, кто использовал бы его. Как правило, Вы ограничиваете его людьми, которые знали бы пароль root так или иначе, хотя возможно стать более необычным и ограничить то, что могут сделать определенные люди.

Проблема безопасности, которая беспокоит меня, - то, что не необходимо ввести мой пароль для каждой команды sudo; если я ввожу другого немногие от того же терминала без большого количества времени, протекая, он принимает sudo без пароля. Это должно, по-видимому, постараться не делать меня непрерывно вводом моего пароля, но возможно, что некоторое программное обеспечение пространства пользователя плохого парня могло использовать это. Я не знаю достаточно для оценки риска, лично.

sudo безопасен - достаточно безопасный для некоторых дистрибутивов (Ubuntu), чтобы использовать и рекомендовать это по умолчанию.

Тем не менее при предоставлении слоя sudo права пользователю, он в основном удаляет разделение, которое Вы имеете между той учетной записью и корневой учетной записью. При предоставлении слоя sudo права пользователю timmy, например, учетная запись timmy становится столь же привилегированной как корневая учетная запись. Любой, кто врывается в учетную запись timmy, может сделать что-либо как корень (в большинстве случаев, пароль timmy необходим).

Аргументы Pro-sudo

• Обычно настраиваемый так, чтобы никто не мог войти в систему как пользователь, названный "корнем". Может мешать к "в лоб" вход в систему суперпользователя.
• Можно иметь мелкомодульный контроль, по которой командам пользователь может выполниться как суперпользователь (хотя обычно Вы давали бы все полномочия одной учетной записи, которая эффективно выполняет ту же роль как "корень" с другим именем).
• Удаляет искушение просто остаться, вошел в систему как корень, если не все команды, Вы выполняете полномочия суперпользователя потребности.

Аргументы Anti-sudo

• sudo, как могло бы замечаться, поощрял бы практику распространения полномочий уровня суперпользователя пользователям, который является, вероятно, не хорошей идеей.
• sudo немного более сложен для установки, потому что это настолько гибко. В то время как это позволяет Вам делать это хорошим и безопасным, это может также помочь непреднамеренно открыть разрывы безопасности, если Вы не осторожны или не понимаете то, что Вы делаете.
• Это может рассматриваться как плохая идея в целом для использования учетной записи с полномочиями суперпользователя для повседневного использования, и имеющий sudo полномочия следующая лучшая вещь. Контрдовод к этому - то, что Ваш пароль пользователя (в большинстве случаев) все еще требуется поднять до состояния суперпользователя, и это вряд ли будет известно процессам злоумышленников рабочие / ошибочные рабочие процессы как Вы.

По существу они - всего две различных философских школы, оба достаточно допустимые, чтобы иметь целые дистрибутивы, поддерживающие их собственный подход.

Я более доволен подходом non-sudo, главным образом потому что это - то, с чем я более знаком как пользователь Debian. Я нахожу простоту наличия корневой учетной записи по гибкости побед sudo для меня. Я не позволяю корневой вход в систему удаленно (т.е. через SSH), и я рекомендую, чтобы никто больше не был должен, также.

sudoers автоматически не имеют доступа как корня. У них есть доступ как у настроенного пользователя. Это возможно и корректно для обеспечения пользовательского доступа для выполнения инструментов как других некорневых пользователей.

Любые пользователи, у которых есть доступ для выполнения оболочки или команды, которая может предоставить доступ оболочки, должны быть пользователями, которым Вы доверили бы пароль root. С sudo возможно выполнить систему без пароля root. Все использование sudo зарегистрировано, который не имеет место с командами, выполненными как корень.

Как отмечено это - possble для ограничения доступа к определенным командам. Пример sudoers имеет много наборов команд, которые Вы могли бы хотеть предоставить определенным пользователям, которые должны сделать задачу, требующую полномочий пользователя root. При помощи sudo возможно позволить это, не давая им пароль root.

Любому, кто может запустить скрипт или команду с корнем privleges, который они могут изменить, эффективно предоставили корневой доступ. Вы должны доверять этим людям или не предоставляете им доступ.

Существует большое количество задачи, которые требуют корневого доступа. С sudo можно безопасно делегировать их задача скопировать операторы, веб-мастеров, и т.д.

Sudo намного более безопасен что альтернативы. Если неправильно сконфигурировано, или если некорректному доступу предоставляют к недоверяемым пользователям, это - угроза безопасности (дыра).

sudo команда позволяет одному пользователю командам выполнения с полномочиями другого. Другой пользователь может быть root или это может быть кто-то еще, но значение по умолчанию root. Это было разработано с этой целью, имеет много параметров конфигурации помочь отнести вещи блокировки во множестве путей и исследовалось за многие годы большим количеством людей. Это не подходит для всех проблем безопасности, но используемое правильно, это может быть очень полезный инструмент. Однако, если не используемый правильно, это может создать больше проблем, чем это решает.

sudo не способствует безопасности. Программное обеспечение делегирования привилегий помогает различать, кто что делал, и надежно регистрировать действия. Но с большинством настроек sudo журнал активности можно легко подделать. А использование системного пароля пользователя означает, что если кто-то украдет пароль для входа в систему, он также сможет запустить sudo от имени этого пользователя, чтобы сделать что-то плохое. Затем на платформах UNIX / Linux любому системному администратору очень легко запустить сценарий в фоновом режиме для кражи чужого пароля. Системный администратор также может провести атаку с заменой пароля, чтобы использовать учетную запись жертвы для совершения плохих действий. А также может использовать учетную запись жертвы для запуска sudo, чтобы сделать что-то плохое через обновление файла временной метки sudo. Это означает, что когда журнал сообщает, что А сделал что-то и в какое время, это может быть не А. Требуется дополнительное расследование, чтобы выяснить, что произошло, но это может не всегда возможно.