Вопросы Теги

Защитите папку от sudoers

Следующий подход дает Вам способность предварительно просмотреть/сократить сгенерированные команды прежде, чем выполнить их, и это очень портативно: это должно работать не только над Mac, не только с ударом, и не только с GNU sed; даже в системах без find(1) команда возможно заменить им с du(1) без проблемы.

find . -name '*(1).m4a' |
sed 's/\(.*\)(1).m4a$/mv & \1.m4a/'

Если счастливый печатными командами, повторно выполненными с | sh -x добавленный.

Если затронуто пробелами в именах файлов, добавьте другой s для выхода из всех пробелов:

find . -name '*(1).m4a' |
sed -e 's/ /\\ /g' -e 's/\(.*\)(1).m4a$/mv & \1.m4a/'

Если другие специальные символы ожидаются, это получает небольшой более хитрый бит:

find . -name '*(1).m4a' |
sed -e "s/'/'\\\\''/g" -e 's/\(.*\)(1).m4a$/mv '\''&'\'' '\''\1.m4a'\'/

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

7
13.06.2013, 02:12
5 ответов

Предположение, что “sudoers” Вы имеете в виду людей, которые разрешены командам выполнения как корень с sudo префикс, потому что они упоминаются в sudoers файл через строку как bob ALL=(ALL) ALL, затем эти люди являются корнем. То, что определяет быть корнем, не знает пароля корневой учетной записи, это имеет доступ к корневой учетной записи через любые средства.

Вы не можете защитить свои данные из корня. По определению пользователь root может сделать все. Полномочия не помогли бы, так как корень может изменить или обойти полномочия. Шифрование woulnd't справка начиная с корня может ниспровергать программу, делающую дешифрование.

Если Вы не доверяете кому-то, не предоставляйте им корневой доступ на машине, где Вы храните свои данные. Если Вы не доверяете кому-то, у кого есть корневой доступ на машине, не храните свои данные на нем.

Если пользователь должен базироваться доступ для некоторой определенной цели, такой как удобное администрирование приложения, установка пакетов, и т.д., затем дать им их собственные аппаратные средства или дать им их собственную виртуальную машину. Позвольте им быть корнем в VM, но не на хосте.

10
27.01.2020, 20:13

Обычно sudo доступ предоставляется в этом типе способа:

# User privilege specification

root    ALL=(ALL) ALL
user1   ALL=(ALL) ALL

В этом сценарии у пользователя по существу есть беспрепятственный доступ, чтобы стать корнем и сделать независимо от того, что они хотят. Можно быть более разумными в том, как Вы предоставляете доступ к различным задачам в sudo путем выполнения вещей этот путь вместо этого:

user1  ALL=(root) /usr/bin/find, /bin/rm

Вот, мы ограничиваем команды, для которых может использовать user1 просто find и rm. Если Вы знаете, что пользователю только нужна конкретная команда, можно предоставить им доступ исключительно только к той команде.

Далее больше можно создать сценарии вместо того, чтобы просто добавить команды. Например:

user1  ALL=(root) /usr/local/bin/limited_script.sh

Этот сценарий был бы единственной командой, к которой у них будет доступ, Вы могли, например, cd /to/some/dir, в предшествующем сценарии, и затем переносят любую команду, к которой у них должен быть доступ. Это могло бы быть способом ограничить их доступ.

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

5
27.01.2020, 20:13
  • 1
    sudo /usr/bin/find . -maxdepth 0 -exec any-command-you-like \; –  Keith Thompson 13.06.2013, 02:19
  • 2
    Спасибо, да, это ни в коем случае не идеальное решение, как в безопасности, которая это о слоях. Но в этом случае это - очень тонкий слой. –  slm♦ 13.06.2013, 03:23
  • 3
    Хорошее решение. Но я думаю, что ответ @Gilles верен. Я никогда не буду feal в безопасном, если у кого-то еще будет даже только некоторый корень priviligues. –  Arthur Halma 13.06.2013, 11:41
  • 4
    Мы сказали по существу то же самое. Мой ответ предоставил Вам метод, который даст Вам способность позволить пользователю выполнять команду w/o доступ к диску, в то время как его не сделал. Я верю тому, именно это просил Ваш вопрос? Дополнительно его ответ говорит только с bob ALL=(ALL) ALL который является худшим способом пахать sudo полномочия. Как я сказал, чрезвычайно невозможно заблокировать управляемого пользователя в не поглощение команд в sudo в низких целях. Но мой ответ является на самом деле более представительным для того, как Вы дали бы sudo полномочия. –  slm♦ 13.06.2013, 11:50

Если команды, которые может выполнить sudoer, не ограничиваются в sudoers файл конфигурации (обычно /etc/sudoers), sudo дает root, таким образом, нет ничего, что можно сделать, чтобы препятствовать тому, чтобы sudoer получил доступ каталогу.

4
27.01.2020, 20:13

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

Я предполагаю лучшее, которое Вы могли сделать, должен был зашифровать папку/файлы в некотором роде к личному паролю.

4
27.01.2020, 20:13

Вы могли бы возможно использовать ACLs и в установке соответствующих записей ACE, Вы смогли делать это. Однако это - немного больше стычки.

Так или иначе, если Вы делаете это, как администратор собирается помочь Вам решить проблему со своими файлами/каталогами? Или Вы полагаете, что Ваши доверяемые пользователи или Вы не делаете и перемещаетесь другой системе, где Вы доверяете своим администраторам.

2
27.01.2020, 20:13

Теги

Похожие вопросы