Linux запретить пользователю запускать

Обновлено: 04.07.2024

Ограничение прав пользователей в операционной системе – тема сложная, но необходимая. В зависимости от семейства операционной системы существуют разные правила и стандарты. Рассмотрим подробнее, как это происходит в ОС Ubuntu.

Права администратора

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

usermod -a -G sudo username1

Теперь пользователь с именем username1 добавлен в группу sudo и является администратором для операционной системы. Ему доступны настройки ОС, а также доступ к каталогу /dev с вложениями. Большинство привилегий администраторов схоже с возможностями суперпользователя, но они неполные.

Как выставить запрет

В корпоративных информационных системах большинство ОС являются многопользовательскими. Соответственно, необходимо для каждого владельца разграничить права доступа. Для этого используется внутренняя команда chmod, например:

sudo chmod o-x $(which ls)>

Вышеуказанная строка означает, что только root имеет право запускать команду ls. Всем остальным в доступе будет отказано.

Разберем другую ситуацию. Есть пользователь с именем username1. Ему необходимо ограничить доступ к команде ls. Для этого создаем группу пользователей usergroup1, в которую перенесём всех кроме username1.

sudo groupadd usergroup1
sudo useradd -G usergroup1 <username2, username3>

Вторая строка добавляет в группу usergroup1 пользователей username2, username3 и т. д. Ограничим права на запуск команды ls. Её смогут активировать только участники usergroup1.

sudo chown :group2 $(which ls)
sudo chmod 754 $(which ls)

Теперь неучастник usergroup1 не сможет активировать ls.

Немного о файле /etc/sudoers

Sudoers содержит информацию о пользователях, которые могут использовать утилиту sudo. Чтобы открыть файл, используем специальную утилиту visudo.

Внутри содержится следующая информация:

Содержимое sudoers

Скриншот №1. Содержимое sudoers

Расскажем подробнее о строке:

Задать правила

Скриншот №2. Задать правила

%sudo означает, что к группе sudo применяется следующее правило. Если устанавливаем правила для конкретного пользователя, то % не нужен.

Первая переменная ALL расшифровывает, как применить правило ко всем IP-адресам. Второй и третий ALL – указанный пользователь или группа имеют право исполнять команды в сессии любого пользователя или группы. Четвертая переменная означает, что данный шаблон применяется ко всем командам.

Например, необходимо установить права на запуск утилиты apt get для группы admin.

Alias (псевдонимы)

Для удобства разграничения прав доступа используются алиасы. Они объединяют один или несколько значений в один параметр. Например, присвоим IP-адресу облачного хранилища более удобное имя.

Host_Alias CLOUD = 105.17.125.37

CLOUD – псевдоним, который указывается в параметрах вместо IP-адреса.

При необходимости алиасы используются для объединения пользователей в одну группу.

User_Alias Name = user1,user2.
, где Name – псевдоним, а user1, user2 – имена пользователей. Также утилита Alias доступна и для команд, т. е. объединяем список инструкций в единую группу.

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

noexec в опциях /etc/fstab на /home, /tmp, /dev/shm и т.п. (ну, что доступно на запись пользователям, туда и noexec )

В grsecurity, кажется, было что-то на предмет trusted path execution, но грсек -- это головная боль.

> noexec в опциях /etc/fstab на /home, /tmp, /dev/shm и т.п. (ну, что доступно на запись пользователям, туда и noexec )

> В grsecurity, кажется, было что-то на предмет trusted path execution, но грсек -- это головная боль.

можно ли сделать noexec, если и /tmp и /home в /-разделе?


mount --bind olddir newdir

After this call the same contents is accessible in two places. One can also remount a single file (on a single file).

> mount --bind olddir newdir

> After this call the same contents is accessible in two places. One can also remount a single file (on a single file).


> Это?

что с чем ты предлагаешь биндить? и подойдёт ли туда noexec. и к чему именно оно тогда будет относиться?

man mount смотрел


mv /home /home.real ; mkdir /home ; mount -o noexec /home.real /home


Будет-ли noexec - не знаю, но можно попробовать?

> Будет-ли noexec - не знаю, но можно попробовать?

не доверяй и проверяй!

А спасёт ли noexec от

А смысл делать защиту, если все равно можно сделать cat evil.py | python? Другое дело, что накропать evil на питоне, перле или шелле намного сложнее, чем на C.

Нет, можно конечно все скриптовые языки пропатчить на предмет невосприятия stdin (про perl -e 'print "hello!\n"' не забываем), но это видимо overkill и ни один большой дистрибутив такого делать не будет.

Как пользователю запретить выполнять какие либо программы?

Для новичков как вообще в Linux, так и в конкретной теме, к которой относится вопрос.

Модератор: Bizdelnick

Как пользователю запретить выполнять какие либо программы?

Есть Debian etch + KDE. есть пользователь test. как ему запретить запускать определенные программы? ну допустим kwrite, kedit и т.д. ?

хм.. установил kiosk admin tools но не могу найти чтобы тут где-то можно было доступ к конкретным программам ограничить..
подскажите пжлста..

как ему запретить запускать определенные программы? ну допустим kwrite, kedit и т.д. ?
Найти их исполняемые файлы, присвоить им созданную заранее группу, убрать у категории «остальные» права на чтение и выполнение и не включать пользователя test в эту группу. Есть Debian etch + KDE. есть пользователь test. как ему запретить запускать определенные программы? ну допустим kwrite, kedit и т.д. ?
ACL.
Зпретить доступ пользователю тест к выбранным программам/каталогам. Есть Debian etch + KDE. есть пользователь test. как ему запретить запускать определенные программы? ну допустим kwrite, kedit и т.д. ?
ACL.
Зпретить доступ пользователю тест к выбранным программам/каталогам.

что-то не могу разобраться с man'ом.. можете подсказать конкретный пример как запретить юзеру test запускать kwrite ?

Есть Debian etch + KDE. есть пользователь test. как ему запретить запускать определенные программы? ну допустим kwrite, kedit и т.д. ?
ACL.
Зпретить доступ пользователю тест к выбранным программам/каталогам.

что-то не могу разобраться с man'ом.. можете подсказать конкретный пример как запретить юзеру test запускать kwrite ?

Есть Debian etch + KDE. есть пользователь test. как ему запретить запускать определенные программы? ну допустим kwrite, kedit и т.д. ?
ACL.
Зпретить доступ пользователю тест к выбранным программам/каталогам.

что-то не могу разобраться с man'ом.. можете подсказать конкретный пример как запретить юзеру test запускать kwrite ?

мдя.. написал же что не получается разобратся с маном.. ( .. проще всего отправтиь на гугл имхо..

Тогда уж проще найти того, кто Вам все настроит. Можно даже каким-либо образом вознаградить его за это. Тогда уж проще найти того, кто Вам все настроит. Можно даже каким-либо образом вознаградить его за это.

как я понял людей которые могут помочь все настроить нет. пока попадаются одни шутники.

Найти их исполняемые файлы, присвоить им созданную заранее группу, убрать у категории «остальные» права на чтение и выполнение и не включать пользователя test в эту группу. ACL.
Зпретить доступ пользователю тест к выбранным программам/каталогам. Найти их исполняемые файлы, присвоить им созданную заранее группу, убрать у категории «остальные» права на чтение и выполнение и не включать пользователя test в эту группу. ACL.
Зпретить доступ пользователю тест к выбранным программам/каталогам.

1- в admin kiosk tools нельзя запретить запуск kwrite для какого либо юзера.
2- если убрать права на чтение и выполнение у приложеия chmod o-rx `which kwrite` то всеравно кликнув два раза по файлу test.txt откроется kwrite! проверьте если не верите!
3 с ACL пока не получается разобраться, собственно и прошу по этому помощи.. выяснил только то что у kwrite родитель kdeinit, и как ограничить через ACL - хз..


P.S.: как я полнял с ACL можно запретить доступ к директории или ограничить, а вот как запретить запуск kwrite только для одного пользователя так и не пойму. : /

1- в admin kiosk tools нельзя запретить запуск kwrite для какого либо юзера.

Еще как можно. Запретите выполнение команд по Alt+F2, уберите все лишние программы из меню (в том числе обязательно все эмуляторы терминалов) и отключите ассоциации файлов с kwrite.

2- если убрать права на чтение и выполнение у приложеия chmod o-rx `which kwrite` то всеравно кликнув два раза по файлу test.txt откроется kwrite! проверьте если не верите!

Охотно верю, что если сделать что-то неправильно, то нужного результата достигнуть не удастся. Вы выполнили лишь два пункта из четырех, которые дал Rootlexx:

1. Найти их исполняемые файлы
2. присвоить им созданную заранее группу
3. убрать у категории «остальные» права на чтение и выполнение
4. не включать пользователя test в эту группу

Всего-то и нужно было, что дать следующие команды:


Ну и для очистки совести удостовериться, что пользователь test не входит в группу kwrite. Хотя если группа была создана позже пользователя, то маловероятно, что он в нее попадет. Но лучше все же перестраховаться, чем недостраховаться. :) 1- в admin kiosk tools нельзя запретить запуск kwrite для какого либо юзера.

Еще как можно. Запретите выполнение команд по Alt+F2, уберите все лишние программы из меню (в том числе обязательно все эмуляторы терминалов) и отключите ассоциации файлов с kwrite.

2- если убрать права на чтение и выполнение у приложеия chmod o-rx `which kwrite` то всеравно кликнув два раза по файлу test.txt откроется kwrite! проверьте если не верите!

Охотно верю, что если сделать что-то неправильно, то нужного результата достигнуть не удастся. Вы выполнили лишь два пункта из четырех, которые дал Rootlexx:

1. Найти их исполняемые файлы
2. присвоить им созданную заранее группу
3. убрать у категории «остальные» права на чтение и выполнение
4. не включать пользователя test в эту группу

Всего-то и нужно было, что дать следующие команды:


Ну и для очистки совести удостовериться, что пользователь test не входит в группу kwrite. Хотя если группа была создана позже пользователя, то маловероятно, что он в нее попадет. Но лучше все же перестраховаться, чем недостраховаться.

по первому пункту - пользователь может пользоваться флешкой в FAT32, на ней лежат файлики .txt и множество других. Так что блокировка Alt+F2 в киосктулз отпадает. (походу я просто плохо объяснил свою проблему..ссори ) ) ассоциации файлов буду рассматривать в последний вариант, так как необходимо "в корне" отрубить пользователю возможность запускать kwrite и т.д.


после этого тыкаю на файл test.txt и он без проблем всеравно открывается kwrite! имхо дело тут не в группах, я теже права отключал для пользователя.. и в группе он или нет - не имеет значения. (пробывал даже chmod a-rx `which kwrite`) поэтому естественно опять не сработало
может я опять что-то не то сделал? Пользователь должен выйти из системы и заново войти. "На лету" эти изменения не применятся.
Хотя могу и ошибаться, проверю-ка у себя. Пользователь должен выйти из системы и заново войти. "На лету" эти изменения не применятся.

странно обычно изменения с правами применяются "на лету" : /

даже после перезагрузки компа спокойно открывается kwrite

и даже так kwrite запускается.. может потому что kwrite как-то связан с kdeinit??

и даже так kwrite запускается.. может потому что kwrite как-то связан с kdeinit??

Может. Именно поэтому я и советовал kiosk.

Проверил. В качестве подопытных кроликов использовал kedit и xterm. После манипуляций с группами и правами доступа kedit удалось запустить из главного меню KDE и с помощью Alt+F2, из консоли он запускаться отказался. К слову сказать, он не запускался с помощью Alt+F2 в случае указания полного имени файла. Что касается xterm, то он отказался запускаться в любом случае.

и даже так kwrite запускается.. может потому что kwrite как-то связан с kdeinit??

Может. Именно поэтому я и советовал kiosk.

Проверил. В качестве подопытных кроликов использовал kedit и xterm. После манипуляций с группами и правами доступа kedit удалось запустить из главного меню KDE и с помощью Alt+F2, из консоли он запускаться отказался. К слову сказать, он не запускался с помощью Alt+F2 в случае указания полного имени файла. Что касается xterm, то он отказался запускаться в любом случае.

и какой вердикт? получается установка прав запрета на выполнение программ которые входят в состав KDE (таких как kwrite) ничего не дает и их всеравно можно выполнять
kiosk tools я и так юзаю по полной, но просто отключить ассациации для данного типа файлов мне кажется изначально не правильный подход. охото запретить именно запуск kwrite..

В системе Linux, такой как Debian, как я могу предотвратить использование установленного приложения другими пользователями, если они не введут пароль? Другие типы токенов аутентификации также приемлемы.

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

3 ответа 3

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

Однако запретить запуск исполняемого файла другим пользователям можно с помощью chmod при условии, что у вас есть право владения данным файлом: chmod 700 /some/executable/file . Это дает владельцу файла (исполняемого файла) все разрешения (чтение / запись / выполнение) и никаких прав доступа другим пользователям в системе. Хотя интуитивно понятно, что нужно всего лишь удалить разрешение на выполнение, пользователь все равно сможет скопировать исполняемый файл в свой собственный каталог, а затем снова сделать его исполняемым. Поэтому разрешение на чтение также должно быть удалено.

Ваш вопрос до сих пор неясен.

Если это первая пуля, вероятно, проще всего просто выполнить chmod исполняемого файла и жить с тем фактом, что этот root сможет обойти эту защиту.

Например, если ваша программа называется myprog , вы можете сделать

(используя -d для расшифровки.) Существует риск того, что root может сделать копию вашей программы, когда кто-то ее расшифрует.

Правильная установка владельца и группы владельцев файла, а также его chmod не позволит нежелательным пользователям, кроме root выполнить файл. Обратите внимание, что если другие пользователи могут прочитать файл, но не могут выполнить его, они все равно могут скопировать его и изменить бит x в своей собственной копии, поэтому вы должны отключить разрешение r разрешением x если хотите предотвратить выполнение.

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

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

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

Читайте также: