Дать права root приложению linux

Как дать Root права пользователю в Linux

Суперпользователь «root” — это король пользователей Linux / Unix. Наличие корневого доступа предоставляет полный и неограниченный доступ к дистрибутиву Linux.

В этой инструкции я покажу вам, как дать root права пользователю в системе Linux. Как правило, доступ на корневом уровне (root) используется в системном администрировании. Поэтому всегда больно давать root-доступ другим пользователям. Вы должны быть очень осторожны и должны забрать доступ, как только необходимость в этом отпадет.

Как дать Root права пользователю в Linux

Согласно разрешениям файловой системы Linux, root или суперпользователь имеет полные права на чтение (r), запись (w) и выполнение (x) любого файла. По умолчанию идентификатор пользователя root равен «0».

Я собираюсь создать двух пользователей, а именно user1 и user2. Затем я предоставлю root-правак пользователю «user1«.

Способ 1: Добавление в корневую группу с помощью usermod

Давайте посмотрим, как мы можем дать обычному пользователю root- права, добавив его в корневую группу.

# adduser user1
# adduser user2
# groupadd test

Это группы, которые есть в моей дистрибутиве Linux.

# groups
root bin daemon sys adm disk wheel

Я собираюсь добавить user1 в корневую группу следующим образом:

Приведенная ниже команда даст пользователю привилегию root

Способ 2: Добавление в корневую группу с помощью команды Useradd

Я добавил нового пользователя «user3» в корневую группу с помощью команды:

# useradd -m -G root user3
# groups user3
user3 : user3 root

useradd -c “Imitation Root” -d /home/root_user -m -k /etc/skel -s /bin/bash -u 0 -o -g root root_user

Способ 3: Редактирование файла /etc/passwd

Отредактируйте /etc/passwd для конкретного пользователя. Измените UID и GID пользователя на «0«. Это даст root права пользователю в linux.

Теперь пользователь temproot должен иметь привилегии root:

ВНИМАНИЕ: это не рекомендуемый метод предоставления корневого доступа (root-прав)

Способ 4: Дать права пользователя Sudo

Конфигурационный файл sudo — это файл /etc/sudoers, и вы можете отредактировать его с помощью команды visudo:

Использование visudo защищает от конфликтов и гарантирует использование правильного синтаксиса.

Чтобы предоставить полный доступ конкретным пользователям

Добавьте в файл запись, приведенную ниже:

Следовать этому методу не очень хорошая идея, потому что это позволяет и User1, и User2 использовать команду su для предоставления постоянных привилегий root. Таким образом пропуская функции ведения журнала команд sudo.

Предоставление доступа к определенным файлам одному конкретному пользователю

Эта запись позволяет User 1 и всем другим членам группы получить доступ ко всем программным файлам в каталогах /sbin и /usr/sbin, а также привилегию выполнения команды /usr/oracle/backup.pl…

User1, %operator ALL= /sbin/, / usr/sbin, /usr/oracle/backup.pl

Если у вас есть какие-либо вопросы или предложения по этой теме, оставьте комментарий.

Источник

Администратор в Ubuntu, или Что такое sudo

Содержание

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

Раньше данная проблема решалась достаточно просто: при обладании паролем root можно было зайти в систему под его аккаунтом либо временно получить его права, используя команду su . Потом выполнить все необходимые операции и вернуться обратно под обычного пользователя. В принципе, такая схема работает неплохо, однако у неё есть много существенных недостатков, в частности, невозможно никак (точнее, очень сложно) ограничивать административные привилегии только определённым кругом задач.

Поэтому в современных дистрибутивах Linux вместо root аккаунта для администрирования используется утилита sudo .

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

Что такое sudo

sudo — это утилита, предоставляющая привилегии root для выполнения административных операций в соответствии со своими настройками. Она позволяет легко контролировать доступ к важным приложениям в системе. По умолчанию, при установке Ubuntu первому пользователю (тому, который создаётся во время установки) предоставляются полные права на использование sudo. Т.е. фактически первый пользователь обладает той же свободой действий, что и root. Однако такое поведение sudo легко изменить, об этом см. ниже в пункте про настройку sudo.

Где используется sudo

sudo используется всегда, когда вы запускаете что-то из меню Администрирования системы. Например, при запуске Synaptic вас попросят ввести свой пароль. Synaptic — это программа управления установленным ПО, поэтому для её запуска нужны права администратора, которые вы и получаете через sudo вводя свой пароль.

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

Запуск графических программ с правами администратора

Для запуска графических программ с правами администратора можно воспользоваться диалогом запуска программ, вызываемым по умолчанию сочетанием клавиш Alt + F2 .

Допустим, нам необходимо запустить файловый менеджер Nautilus с правами администратора, чтобы через графический интерфейс как-то изменить содержимое системных папок. Для этого необходимо ввести в диалог запуска приложений команду

Вместо gksudo можно подставить gksu , кроме того, пользователи KDE должны вместо gksudo писать kdesu . У вас попросят ввести свой пароль, и, если вы обладаете нужными правами, Nautilus запуститься от имени администратора. Запуск любого графического ПО можно производить с правами администратора, просто написав в диалоге запуска

Запуск программ с правами администратора в терминале

Для запуска в терминале команды с правами администратора просто наберите перед ней sudo :

У вас попросят ввести ваш пароль. Будьте внимательны, пароль при вводе никак не отображается, это нормально и сделано в целях безопасности, просто вводите до конца и нажимайте Enter . После ввода пароля указанная команда исполнится от имени root.

Система какое-то время помнит введённый пароль (сохраняет открытой sudo-сессию). Поэтому при последующих выполнениях sudo ввод пароля может не потребоваться. Для гарантированного прекращения сессии sudo наберите в терминале

Кроме того, часто встречаются ошибки, связанные с каналами в Linux. При исполнении команды

с правами root исполнится только cat , поэтому файл result.txt может не записаться. Нужно либо писать sudo перед каждой командой, либо временно переходить под суперпользователя.

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

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

После этого вы перейдёте в режим суперпользователя (с ограничениями, наложенными через настройки sudo), о чём говорит символ # в конце приглашения командной строки. Данные команды по действию похожа на su , однако: — sudo -s — не меняет домашний каталог на /root, домашним остается домашний каталог пользователя вызвавшего sudo -s, что обычно очень удобно. — sudo -i — сменит так же и домашний каталог на /root.

Для выхода обратно в режим обычного пользователя наберите exit или просто нажмите Ctrl + D .

Использование традиционного root аккаунта и команды su

Ubuntu 11.04 и младше

Для входа под root достаточно задать ему пароль:

Потом на экране входа нажмите Другой… и введите логин (root) и пароль, который вы задали.

Ubuntu 11.10 и старше

Начиная с версии 11.10 был установлен менеджер входа lightdm, и дело со входом под root обстоит немного сложнее.

1. Устанавливаем root пароль. Введите в терминал:

2. Включаем пункт «Введите логин». Введите в терминал:

В конце файла допишите:

3. Перезагружаем lightdm. Введите в терминал:

Все, на экране входа появится пункт «Логин». В поле логин вводим «root», в поле пароль — пароль, который мы задали на первом этапе.

Для обратной блокировки учетной записи root вам потребуется откатить изменения в настройках lightdm, а также заблокировать учетную запись root командой в терминале:

Настройка sudo и прав доступа на выполнение различных команд

sudo позволяет разрешать или запрещать пользователям выполнение конкретного набора программ. Все настройки, связанные с правами доступа, хранятся в файле /etc/sudoers . Это не совсем обычный файл. Для его редактирования необходимо (в целях безопасности) использовать команду

По умолчанию, в нём написано, что все члены группы admin имеют полный доступ к sudo , о чём говорит строчка

Подробнее о синтаксисе и возможностях настройки этого файла можно почитать выполнив

Разрешение пользователю выполнять команду без ввода пароля

Для того, что бы система не запрашивала пароль при определенных командах необходимо в sudoers после строки # Cmnd alias specification добавить строку, где через запятую перечислить желаемые команды с полным путём(путь команды можно узнать, выполнив which имя_команды:

И в конец файла дописать строку

Создание синонимов (alias`ов)

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

и добавьте в конец файла строки

Время действия введённого пароля

Возможно, вы хотите изменить промежуток времени, в течение которого sudo действует без ввода пароля. Этого легко добиться добавив в /etc/sudoers (visudo) примерно следующее:

Здесь sudo для пользователя foo действует без необходимости ввода пароля в течение 20 минут. Если вы хотите, чтобы sudo всегда требовал ввода пароля, сделайте timestamp_timeout равным 0.

sudo не спрашивает пароль

sudo без пароля — чудовищная дыра в безопасности, кому попало разрешено делать что угодно. Если вы разрешили это намеренно — срочно верните обратно как было.

Однако, в некоторых случаях sudo внезапно перестаёт требовать пароль само по себе. Если сделать visudo , то можно увидеть примерно такую строку, которую пользователь вроде бы не добавлял:

Скорее всего, эта катастрофичная строка была добавлена при установке программы типа Connect Manager от МТС или Мегафона. В таком случае, её нужно поменять на строку, разрешающую с правами root запускать только этот Connect Manager, примерно так:

Есть и другие варианты решения проблемы, небольшое обсуждение здесь.

Источник

Я есть root. Разбираемся в повышении привилегий ОS Linux

Первый квартал 2020 года я провел за подготовкой к экзамену OSCP. Поиск информации в Google и множество «слепых» попыток отнимали у меня все свободное время. Особенно непросто оказалось разобраться в механизмах повышения привилегий. Курс PWK уделяет этой теме большое внимание, однако методических материалов всегда недостаточно. В Интернете есть куча мануалов с полезными командами, но я не сторонник слепого следования рекомендациям без понимания, к чему это приведет.

Мне хочется поделиться с вами тем, что удалось узнать за время подготовки и успешной сдачи экзамена (включая периодические набеги на Hack The Box). Я испытывал сильнейшее ощущение благодарности к каждой крупице информации, которая помогала мне пройти путь Try Harder более осознанно, сейчас мое время отдать должное комьюнити.

Я хочу дать вам мануал по повышению привилегий в OS Linux, включающий в себя разбор наиболее частых векторов и смежных фишек, которые вам обязательно пригодятся. Зачастую сами механизмы повышения привилегий достаточно несложные, трудности возникают при структурировании и анализе информации. Поэтому я решил начать с «обзорной экскурсии» и далее рассматривать каждый вектор в отдельной статье. Надеюсь, я сэкономлю вам время на изучение темы.

Итак, почему повышение привилегий вообще возможно в 2020-м, если методы хорошо известны уже очень давно? На самом деле при грамотном обращении пользователя с системой повысить привилегии в ней действительно не удастся. Основная глобальная проблема, которая порождает такие возможности, заключается в небезопасной конфигурации. Наличие в системе устаревших версий ПО, содержащих уязвимости, также является частным случаем небезопасной конфигурации.

Повышение привилегий через небезопасную конфигурацию

Прежде всего давайте разберемся с небезопасной конфигурацией. Начнем с того, что ИТ-специалисты часто пользуются мануалами и ресурсами вроде stackoverflow, многие из которых содержат небезопасные команды и конфиги. Яркий пример — новость о том, что самый копируемый со stackoverflow код содержал ошибку. Опытный админ увидит косяк, но это — в идеальном мире. Даже грамотные специалисты при повышенной рабочей нагрузке способны допускать ошибки. Представьте, что админ занимается подготовкой и согласованием документации на очередной тендер, параллельно вникает в новую технологию, которую предстоит внедрить в следующем квартале, при этом периодически решает задачи по поддержке пользователей. И тут ему нарезают задачу по-быстрому поднять пару виртуалок и раскатать на них сервисы. Как вы думаете, какова вероятность того, что админ просто не заметит косяк? Потом специалисты меняются, а костыли остаются, при этом компании всегда стремятся минимизировать затраты, в том числе на ИТ-шников.

Получаем стабильный shell

Системная оболочка, полученная на стадии эксплуатации, часто бывает ограниченной, особенно если вы заполучили ее через взлом пользователя веб-сервера. Например, ограничения оболочки могут помешать применить команду sudo с выводом ошибки:

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

Вы спросите: «Зачем мне тысяча команд, если я могу воспользоваться одной, например, для передачи файлов?» Дело в том, что системы бывают сконфигурированы по-разному, на очередном хосте может быть не установлен Python, однако иметься Perl. Мастерство в том, чтобы иметь возможность делать в системе привычные вещи без привычных инструментов. Полный перечень возможностей можно найти тут.

Низкопривилегированный шелл можно получить, используя команды 1 и команды 2 (удивительно, что даже GIMP).

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

Linux собирает историю всех выполненных команд в файле

/.bash_history. Если сервер активно используется, и его история не очищается, существует большая вероятность найти в этом файле учетные данные. Чистить историю банально неудобно. Если администратор вынужден выбирать десятиэтажные команды через \, конечно, ему будет удобнее вызвать эту команду из истории, чем вводить заново. Плюс многие не знают об этом «хаке». Если в системе присутствуют альтернативные оболочки вроде Zsh или Fish, они ведут свою историю. Чтобы вывести историю команд в любой оболочке, достаточно набрать команду history.

Существует shared hosting, при котором сервер используется для хостинга нескольких сайтов. Обычно при такой конфигурации для каждого ресурса создается свой пользователь с отдельной домашней директорией и виртуальный хост. Так вот, при неправильной настройке в корневой директории веб-ресурса можно обнаружить файл .bash_history.

Поиск паролей в файловой системе и атаки на смежные системы

Конфигурационные файлы различных сервисов могут быть доступны для чтения вашему текущему пользователю. В них можно встретить учетные данные в открытом виде — пароли для доступа в базу данных или смежные сервисы. Один и тот же пароль может быть использован как для доступа в базу данных, так и для авторизации пользователя root (credential staffing).
Бывает так, что найденные учетные данные принадлежат сервисам на других хостах. Развитие атаки на инфраструктуру через скомпрометированный хост ничем не хуже эксплуатации других хостов. Смежные системы также можно найти с помощью поиска IP-адресов в файловой системе.

В случае, если на скомпрометированном хосте имеется веб-приложение, доступное из Интернета, лучше исключить его логи из поиска IP-адресов. Адреса пользователей ресурса из Интернета нам вряд ли будут полезны, а вот адреса внутренней сети (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) и то, куда они заходят, судя по логам, могут представлять интерес.

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

Первое, что нужно сделать, получив доступ в систему, — выполнить команду sudo -l. Она выведет разрешение на использование команды sudo. Если получен пользователь без пароля (например, apache или www-data), вектор повышения привилегий через sudo маловероятен. При использовании sudo система запросит пароль. Через команду passwd задать пароль также не выйдет, она запросит текущий пароль пользователя. Но если sudo все же доступен, то, по сути, необходимо искать:

• любые интерпретаторы, каждый может заспавнить shell (PHP, Python, Perl);
• любые текстовые редакторы (vim, vi, nano);
• любые просмотровики (less, more);
• любые возможности работы с файловой системой (cp, mv);
• тулы, которые имеют выход в bash, интерактивный или в виде исполняемой команды (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

В Интернете есть множество мануалов, которые советуют собрать все suid/sgid команды, однако редкая статья даёт конкретику, что делать с этими программами. Варианты повышения привилегий, не учитывающие применение эксплоитов, можно найти тут. Также ряд исполняемых файлов имеет специфические уязвимости под версию ОС, например.

В идеальном мире нужно пропустить все установленные пакеты хотя бы через searchsploit. На практике подобное стоит проделывать с наиболее популярными программами типа sudo. Также всегда есть вариант использовать и поддерживать разработку автоматизированных инструментов, которые подсветят интересные, с точки зрения повышения привилегий, исполняемые файлы с выставленными битами suid/sgid. Перечень таких инструментов я приведу в соответствующем разделе статьи.

Доступные на запись скрипты, запускаемые Cron или Init, в контексте Root

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

Похожим образом обстоят дела с init. Отличие в том, что задачи в cron выполняются периодически, а в init — при старте системы. Для эксплуатации потребуется перезагрузка системы, при этом часть сервисов может и не подняться (если они не были прописаны в автозагрузку).

Также можно поискать файлы, доступные для записи любому пользователю.

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

Получение доступа в оболочку других пользователей

Смотрим список пользователей в /etc/passwd. Обращаем внимание на тех, у кого есть оболочка. Можно побрутить этих пользователей — не исключено, что через полученного пользователя в итоге удастся повысить привилегии.

Для повышения безопасности рекомендую всегда придерживаться принципа минимальных привилегий. Также имеет смысл уделить время проверке небезопасных конфигураций, которые могли остаться после траблшутинга, — это «технический долг» системного администратора.

Самописный код

Стоит внимательно посмотреть на исполняемые файлы в домашней директории пользователя и веб-сервера (/var/www/, если не задана другая). Эти файлы могут оказаться совершенно небезопасным решением и содержать в себе невероятные костыли. Конечно, если вы имеете какой-нибудь фреймворк в директории веб-сервера, не имеет смысла искать в нем zero-day в рамках пентеста, однако найти и изучить кастомные доработки, плагины и компоненты рекомендуется.

Для повышения безопасности лучше по возможности отказаться от использования учетных данных в самописных скриптах, а также от потенциально опасного функционала, например чтения /etc/shadow или манипуляций с id_rsa.

Повышение привилегий через эксплуатацию уязвимостей

Прежде чем пытаться повысить привилегии через эксплуатацию, важно разобраться с передачей файлов на целевой хост. Помимо привычных средств вроде ssh, ftp, http (wget, curl) есть целый «зоопарк» возможностей.

Для повышения безопасности системы регулярно обновляйте ее до актуальных стабильных версий, а также старайтесь использовать дистрибутивы, рассчитанные на Enterprise. В противном случае, редко, но бывают ситуации, когда apt upgrade делает систему неработоспособной.

Эксплуатация сервисов, запущенных в контексте пользователя root

Некоторые сервисы Linux работают от привилегированного пользователя root. Их можно найти с помощью команды ps aux | grep root. При этом сервис может не анонсироваться в Cеть и быть доступным локально. Если он имеет публичные эксплоиты, их можно смело применять: падение сервиса в случае неудачи гораздо менее критично, чем падение ОС.

Самым удачным случаем можно считать работу взломанного сервиса в контексте пользователя root. Эксплуатация сервиса SMB дает привилегированный доступ SYSTEM в системах Windows (например, через ms17-010). Однако в системах Linux такое встречается нечасто, поэтому можно провести немало времени над повышением привилегий.

Эксплуатация уязвимостей ядра Linux

Это путь, которым следует идти в последнюю очередь. Неудачная эксплуатация может привести к падению системы, а в случае ребута некоторые сервисы (в том числе те, через которые удалось получить изначальный shell) могут не подняться. Бывает, что администратор банально забыл применить команду systemctl enable . Плюс это вызовет много недовольства вашими работами, если эксплуатация не была согласована.
Если решили использовать исходные коды из exploitdb, обязательно прочитайте комментарии в начале скрипта. Помимо прочего, там обычно написано, как следует правильно компилировать данный эксплоит. Если самому лень или по срокам нужно было «вчера», можно поискать репозитории с уже скомпилированными эксплоитами, например. Однако следует понимать, что в таком случае вы получите кота в мешке. С другой стороны, если бы программист разбирался до байта, как устроен компьютер и используемый им софт, он бы за всю жизнь не написал бы и строчки кода.

Metasploit

Для того, чтобы поймать и обработать соединение, всегда лучше использовать модуль exploit/multi/handler. Главное — выставить правильный payload, например, generic/shell/reverce_tcp или generic/shell/bind_tcp. Оболочку, полученную в Metasploit, можно улучшить до Meterpreter с использованием модуля post/multi/manage/shell_to_meterpreter. Имея Meterpreter, вы можете автоматизировать процесс постэксплуатации. Например, модуль post/multi/recon/local_exploit_suggester проверяет платформу, архитектуру и необходимые для эксплуатации сущности и предлагает модули Metasploit для повышения привилегий на целевой системе. Благодаря Meterpreter, повышение привилегий иногда сводится к запуску нужного модуля, однако взлом без понимания происходящего под капотом не является «тру» (вам еще отчет писать).

Tools

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

Linpeas

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

LinEnum

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

Linux-exploit-suggester (1,2)

Этот эксплоит проанализирует систему на наличие подходящих условий для эксплоитов. По сути, сделает работу, идентичную модулю Metasploit local_exploit_suggester, но предложит не модули Metasploit, а ссылки на исходные коды exploit-db.

Linuxprivchecker

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

Источник