Ограничьте типичных пользователей для выполнения команды с определенным аргументом

Я разрешил проблему путем отключения NetworkManager сервис. Вероятно, при необходимости в том сервисе, чтобы быть активными, можно взять в учетной записи предложение Tim, или можно использовать NM_CONTROLLED=no опция. Так или иначе, с этой используемой опцией, я думаю, что необходимо будет сделать некоторые другие настройки.

2
24.09.2013, 00:07
3 ответа

Я думаю, что единственный путь состоял бы в том, чтобы записать Вашу собственную обертку в рассматриваемую команду/утилиту и иметь ее, решают то, что позволяется или не позволяется на основе (E) UID пользователя, который запустил его. Инструменты Вы упоминаете, что делают это такой как chsh или passwd встройте эту функциональность в их реализацию.

Как записать обертку для ls

#!/usr/bin/perl

use strict;
use warnings;

my $problematic_uid = 1000; # For example
my $is_problematic = $< == $problematic_uid;
unless(/ -l / ~~ @ARGV or $is_problematic){
    exec qq{/new/path/to/ls }.join '',@ARGV
}else{
    die "Sorry, you are not allowed to use the -l option to ls\n"
}

Необходимо удостовериться что путь к оригиналу ls не находится в Вашем пользователе PATH. Который является, почему я записал /new/path/to/ls. Проблема, эта обертка требует, чтобы Ваш пользователь смог выполнить оригинал ls таким образом, пользователь может все еще обойти его путем вызова оригинала ls непосредственно.

3
27.01.2020, 21:51
  • 1
    @RaduRădeanu. Дайте мне несколько минут для скольжения через man sudoers и отправьте назад здесь. Я знаю, что это возможно от предыдущего чтения страницы, но я забыл механику относительно нее. –  Joseph R. 23.09.2013, 23:35
  • 2
    @RaduRădeanu, Это кажется этим, не будет работать на Ваш вариант использования. sudoers страница говорит, указываете ли Вы параметры командной строки затем, это - единственная версия команды, которую пользователю разрешают пробежать sudo, который отличается от того, что Вы хотите. Мое плохое... –  Joseph R. 23.09.2013, 23:43
  • 3
    я думал об этом, также... Но, что относительно записи Ваша собственная обертка к команде...? Как я могу сделать это? Искренне время сначала, когда я слышу о чем-то вроде этого. сезам –  Radu Rădeanu 23.09.2013, 23:48
  • 4
    @JosephR. необходимо было бы указать все возможные комбинации опций. В то время как это смотрит невозможные команды fo как ls, tar или ps, это могло работать с подмножеством опций, если они, по крайней мере, отсортированы в обертке. обертка –  peterph 23.09.2013, 23:55
  • 5
    @RaduRădeanu является простым исполняемым файлом (обычно на языке в виде сценария), который (часто) имеет то же имя как целевой исполняемый файл, но предшествует ей во время поиска команды (например, именно в каталоге, появляется в PATH ранее, чем цель). В Вашем случае однако, это довольно проблематично, так как Вы не хотите предоставлять доступ к целевому исполняемому файлу - все же это должно быть доступно для обертки. –  peterph 23.09.2013, 23:59

Команды как chsh и passwd кодируются особенно. Они работают с дополнительными полномочиями (они - setuid), корень), и содержите их собственный механизм авторизации. Обе проверки, какой пользователь вызывает их и позволяет некорневым пользователям только подмножество их функциональности.

chsh и passwd исключение. Большинство команд не заботится, кто вызывает их.

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

Можно сделать ограниченную учетную запись, которой только позволяют выполнить набор в белом списке команд: с ограниченной оболочкой, или для единственных передачей данных учетных записей, rssh или scponly.

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

3
27.01.2020, 21:51

Ответ Rahul относится к Вашему вопросу, потому что то, что Вы хотите, a) не хорошая идея и b) вероятно, только возможный путем создания пользовательской оболочки. Исполняемые файлы как ls отдельные, автономные программы, которые обрабатывают их аргументы собой - если Вы хотели бы препятствовать тому, чтобы пользователи использовали ls -l, необходимо было бы записать и скомпилировать собственное ls. Как можно, вероятно, предположить, это не было бы легко, и также потребуется много времени, потому что необходимо сделать это для каждой команды, которую Вы хотите изменить.

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

Я думаю, что это может быть возможно, так как существуют некоторые команды как chsh или passwd который типичный пользователь может выполнить их, но он отклонил разрешение, когда он работает chsh root или passwd -a -S.

Это - что-то еще полностью, потому что эти программы записаны тот путь. Если Вы хотели бы изменить их поведение, как Вы хотите изменить поведение ls, необходимо было бы изменить их исходные коды и перекомпилировать их.

2
27.01.2020, 21:51
  • 1
    Это не было бы настолько трудно, начиная с удаления опции, намного легче, чем добавление одного (обычно, просто необходимо закомментировать несколько строк кода). –  peterph 24.09.2013, 00:02
  • 2
    Однако, это походит на безумно плохую идею мне, точно так же, как "эй, давайте отключим значки на рабочем столе и командную строку на рабочих станциях Windows наших пользователей, вызовите Вас, знают, тот материал ОПАСЕН". Мне действительно не нравится тот подход. спасибо –  Martin von Wittich 24.09.2013, 00:24
  • 3
    Ну, ограничение доступа к узкому набору управляет, определенно имеет смысл при некоторых обстоятельствах. Ограничение использования некоторых опций для ls и подобный походит вполне на глупую идею действительно (пример ls определенно плохой). Но для некоторых команд это могло бы иметь смысл также - c.f. unix.stackexchange.com/questions/91214 / … –  peterph 24.09.2013, 11:49

Теги

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