У меня есть сервер, на котором я просто установил апача. У меня есть сценарий PHP на сервере, от которого я хотел бы выполнить команду sudo. Я обыскивал сеть на том, почему предоставление www-данных sudo nopasswd доступ в sudoers файле плохо, но я на самом деле не понимаю почему? Если это - единственный сценарий PHP на сервере, и единственная цель сервера состоит в том, чтобы обработать этот сценарий PHP, это все еще опасно? Если так, как еще должен я делать это. Я не могу понять это. Я запускаю скрипт Python, который будет использовать os.system () для выполнения команды sudo, и именно поэтому я хочу предоставить ему доступ. Другая вещь, которую я заметил, состоит в том, что, когда я направляю его только к папке с моим сценарием Python, это не работает. Когда я направляю его ко ВСЕМ, это делает. Я не уверен, что сделать.Спасибо.
Ни при каких обстоятельствах не разрешают Ваш веб-сервер к командам выполнения с sudo
. Даже гиперопределенные команды.
Это - огромная угроза безопасности. Веб-серверу нельзя дать полномочия получить доступ sudo
команды, которые затем разрешают корневой доступ для команд. Особенно, когда дали nopasswd
форма sudo
, должен Ваш веб-сервер быть нарушенным, , любая команда, выполненная злонамеренным агентом угрозы, может быть выполнена как root
с полномочиями бога, таким образом, Ваша вся система в досягаемости для хищения данных, удаления данных, повреждения и повреждения ОС .
Много веб-приложений не записаны в безопасном методе, и если Ваша установка Apache будет нарушена, то Вы не сможете защитить себя от сценариев и злонамеренных агентов угрозы от выполнения любой произвольной команды.
, Если Вы должны , дают разрешение веб-сервера выполнить что-то как корень, Вы очень делаете что-то не так и должны переоценить то, что Вы пытаетесь сделать. Учитывая, что Ваш вопрос ничего не указывает о том, чего точно Вы пытаетесь достигнуть или что точно Ваш сценарий делает, единственный совет, который я могу дать как, системы adminsitrator и человек безопасности , не пытаются дать веб-сервер sudo
доступ .
Принцип позади www-data
пользователь - то, что это непривилегированно пользователь.
при выполнении демона (фоновая программа как веб-сервер) в целях безопасности, для него хорошо отбросить полномочия после запуска, так, чтобы это потратило остальную часть его времени с самыми низкими возможными полномочиями.
В прошлом эти nobody
учетная запись часто использовалась с этой целью. Преимущество этого было то, что имя, "никто" не прояснил, что это, как предполагалось, было непривилегированно учетная запись без прав.
Однако исключения из правила иногда подходили бы, посредством чего кому-то будет нужен демон, чтобы иметь разрешение записи здесь или там. При изменении эти nobody
учетная запись влияла бы на всех демонов.
Так www-data
родился как способ иметь главным образом непривилегированного пользователя для веб-серверов только, но изолированный от других демонов или целей, поэтому если бы действительно необходимо было дать той учетной записи пользователя некоторые дополнительные полномочия, она только влияла бы на веб-сервер и не уменьшила бы безопасность другой системные демоны.
идея, которая www-data
должна быть непривилегированным пользователем, все еще важна. Чем больше полномочий Вы даете это, тем больше озабоченности Вы должны иметь по поводу того, что могло бы произойти, если демон (или любой из сценариев или управляет этим, работает), поставлен под угрозу или выставляет дыру в системе безопасности любого вида.
Предоставление www-data
приблизительно sudo
доступ является антитезой этого принципа. В то время как возможно быть выборочным с sudo доступом, это все еще открывает довольно большую угрозу безопасности из-за потенциала для человеческой ошибки, или потенциал, который веб-сервер или любые сценарии это выполняет, может иметь дыры в системе безопасности.
, Как можно избежать его?