Intereting Posts
debian X Xconf разрешение xrandr badmatch Как получить Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01) беспроводная карта, работающая на Debian Wheezy Что означает «\ (\)» в этой команде: grep («- (mean | std) \ (\)», x ) Как узнать, какие команды будут использовать расширение скобки, а что нет? NMI получен по неизвестной причине 20 – У вас есть странный режим энергосбережения? Bumblebee: Как исправить «Экран 1 удаленный» -Error Поддерживает ли конфигурация iscsi target и инициатор iscsi в двух Linux-узлах и использование Ethernet-кабеля для связи делает его SAN? Функции листинга, определенные в сценарии «sourced»? Что случилось с профилем основного администратора в Solaris 11? Добавить репозитории в Kali Linux 2.0 Получить строки между двумя временными метками из файла Возможно ли создать файл с привилегиями других пользователей? Запуск демона как непривилегированного пользователя Возможная ошибка перенаправления в zsh 5x Я сделал дистрибутив Linux (вроде). Как я могу получить его на серверах и зеркалах?

Билеты на судо и последующий процесс брата не судо

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

Эффективно ли это дает процессам, выполняющимся как дочерние элементы процесса, который вызвал sudo , но не самим sudo (то есть, как братья и сестры, а не дочерние элементы процесса, который был запущен с помощью sudo ), возможность повысить свои привилегии до root?

В качестве конкретного примера представьте, что я запускаю в терминале:

 sudo echo "hi" other_process 

Процесс echo запускается с помощью sudo , а other_process – нет. Может ли other_process использовать билет sudo с 10-минутным other_process действия, связанный с более ранним вызовом sudo , например, сам запуск other_process через sudo ?

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

Меняется ли ответ, если вызов sudo происходит не непосредственно в терминале, а в сценарии, запущенном из терминала?

Например, я бегу:

 script.sh other_process2 

Если внутри script.sh есть строка, подобная sudo echo "inside script" , смогут ли другие процессы, впоследствии запущенные сценарием, использовать билет sudo для повышения своих привилегий до root? Как насчет того, чтобы завершить работу сценария: смогут ли другие процессы в терминале, который script.sh прежнему использовать билет sudo 1 ?


1 Они больше не похожи на братьев и сестер, а на процессы «тетя» или «дядя» (родные братья и сестры).

Да, билет sudo подходит для любого процесса, запущенного в этом терминале (по крайней мере, от имени вашего пользователя). Это достаточно легко проверить. Просто создайте test.sh (или любой другой) с помощью:

 #!/bin/sh sudo apt-get check 

Затем:

 $ sudo apt-get check [sudo] password for anthony: Reading package lists... Done Building dependency tree Reading state information... Done $ ./test.sh Reading package lists... Done Building dependency tree Reading state information... Done 

Как правило, не рекомендуется запускать ненадежные программы, особенно как пользователь. И вам определенно не следует делать это на терминале, на который у вас есть билет sudo. Если вы должны запускать ненадежные программы, вы должны установить защитные барьеры (как минимум, другого пользователя, но еще лучше – виртуальную машину или, по крайней мере, контейнер – настройка безопасной изолированной программной среды для запуска ненадежных программ не является тривиальной ).

Да. Поскольку авторизация sudo связана с сочетанием вашего имени пользователя, tty и метки времени, любые команды, запускаемые из этой оболочки, могут передавать возможность самостоятельно повышать привилегии через sudo без ввода пароля (при условии, что у вас нет timestamp_timeout=0 в ваш файл /etc/sudoers ).

Пока эти сценарии выполняются в течение установленного вами времени ожидания (по умолчанию = 15 минут).

файл test.sh:

 #!/bin/bash echo "test: \$SHLVL is: $SHLVL" echo "test: I am $(id) on $(tty)" echo "test: with sudo I am $(sudo id) on $(tty)" /bin/bash -l ./sudotest.sh 

файл sudotest.sh:

 #!/bin/bash echo "sudotest: \$SHLVL is: $SHLVL" echo "sudotest: I am $(id) on $(tty)" echo "sudotest: with sudo I am $(sudo id) on $(tty)" 

результаты в:

 test: $SHLVL is: 2 test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7 [sudo] password for tim: test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7 sudotest: $SHLVL is: 3 sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7 sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7 

В этом случае первый вызов sudo был в test.sh , но sudotest.sh не был вызван вместе с самим sudo, хотя мои имя пользователя и tty остались прежними, sudo распознал этот процесс как имеющий право на повышенные привилегии и не Не запрашивайте пароль во время выполнения sudotest.sh .

И если я запустлю его снова через пару минут, но до истечения времени ожидания:

 test: $SHLVL is: 2 test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7 test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7 sudotest: $SHLVL is: 3 sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7 sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7 

Я не получаю подсказки вообще. И я не буду, пока не пройдет ограничение времени timestamp_timeout .

Вы можете видеть, что tty остается одним и тем же во время выполнения, и что SHLVL увеличивается, потому что каждый процесс оболочки, выполняемый сценарием, находится на уровень глубже от вызывающей оболочки. Моя интерактивная shell, SHLVL = 1 , вызывает test.sh который получает SHLVL = 2 , который вызывает sudotest.sh который получает SHLVL = 3 .

Одним из возможных предостережений в этом случае является наличие у вас более старой версии sudo, где не установлена ​​опция tty_tickets , которая удаляет гранулярность username + tty для сеансов sudo и ограничивает гранулярность только именем пользователя и отметкой времени.

Другие варианты sudoers могут оказать влияние, например requiretty .

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

Ответ – нет. Попробуйте sudo id и id для подтверждения.