Root пользователь и его привилегии

Использование chmod

При настройке разрешений рассчитайте необходимое вам значение. Если вы хотите установить чтение, запись и выполнение для пользователя, чтение и выполнение для группы, а также чтение и выполнение для других в файле /somefile, то вы используете следующую команду chmod:

chmod 755 /somefile

Когда вы используете chmod таким способом, все текущие разрешения заменяются установленными вами разрешениями.

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

1. Сначала вы указываете, для кого вы хотите изменить разрешения. Для этого вы можете выбрать между пользователем (u), группой (g) и другими (o).
2. Затем вы используете оператор для добавления или удаления разрешений из текущего режима или устанавливаете их абсолютно.
3. В конце вы используете r, w и x, чтобы указать, какие разрешения вы хотите установить.

При изменении разрешений в относительном режиме вы можете пропустить часть «кому», чтобы добавить или удалить разрешение для всех объектов. Например, эта команда добавляет разрешение на выполнение для всех пользователей:

chmod +x somefile

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

chmod g+w,o-r somefile

При использовании chmod -R o+rx /data вы устанавливаете разрешение на выполнение для всех каталогов, а также для файлов в каталоге /data. Чтобы установить разрешение на выполнение только для каталогов, а не для файлов, используйте chmod -R o+ rX /data.

Верхний регистр X гарантирует, что файлы не получат разрешение на выполнение, если файл уже не установил разрешение на выполнение для некоторых объектов. Это делает X более разумным способом работы с разрешениями на выполнение; это позволит избежать установки этого разрешения на файлы, где оно не требуется.

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

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

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

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

sudo: no tty present and no askpass program specified

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

python -c 'import pty;pty.spawn("/bin/bash")'

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

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

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

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

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

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

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
grep -a -R -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' /var/log/ 2>/dev/null | sort -u | uniq #IPs inside logs

Sudo

Команда 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 доступны на чтение любому пользователю.

ls -la /etc/cron.d  # show cron jobs 

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

ls -la /etc/init.d/  # show init scripts 

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

find / -perm -2 -type f 2>/dev/null # find world writable files

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

chmod +w /path 
chmod 777 /path

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

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

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

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

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

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

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

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

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

gksudo nautilus

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

gksudo <имя_команды>

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

Установка прав по умолчанию с помощью umask

Выше вы узнали, как работать с ACL по умолчанию. Если вы не используете ACL, есть параметр оболочки, который определяет права по умолчанию, которые вы получите: umask (обратная маска). В этом разделе вы узнаете, как изменить разрешения по умолчанию с помощью umask.

Вы, наверное, заметили, что при создании нового файла устанавливаются некоторые разрешения по умолчанию. Эти разрешения определяются настройкой umask. Этот параметр оболочки применяется ко всем пользователям при входе в систему. В параметре umask используется числовое значение, которое вычитается из максимальных разрешений, которые могут быть автоматически установлены для файла; максимальная настройка для файлов — 666, а для каталогов — 777.

Однако некоторые исключения относятся к этому правилу. Вы можете найти полный обзор настроек umask в таблице внизу.

Из цифр, используемых в umask, как и в случае числовых аргументов для команды chmod, первая цифра относится к разрешениям пользователя, вторая цифра относится к разрешениям группы, а последняя относится к разрешениям по умолчанию, установленным для других. Значение umask по умолчанию 022 дает 644 для всех новых файлов и 755 для всех новых каталогов, созданных на вашем сервере.

Полный обзор всех числовых значений umask и их результатов в таблице ниже.

Простой способ увидеть, как работает параметр umask, выглядит следующим образом: начните с разрешений по умолчанию для файла, установленного на 666, и вычтите umask, чтобы получить действующие разрешения. Сделайте то же самое для каталога и его разрешений по умолчанию 777.

Есть два способа изменить настройку umask: для всех пользователей и для отдельных пользователей. Если вы хотите установить umask для всех пользователей, вы должны убедиться, что параметр umask учитывается при запуске файлов среды оболочки, как указано в /etc/profile. Правильный подход — создать сценарий оболочки с именем umask.sh в каталоге /etc/profile.d и указать umask, который вы хотите использовать в этом сценарии оболочки. Если в этом файле изменяется umask, он применяется ко всем пользователям после входа на сервер.

Альтернативой настройке umask через /etc/profile и связанные файлы, где он применяется ко всем пользователям, входящим в систему, является изменение настроек umask в файле с именем .profile, который создается в домашнем каталоге каждого пользователя.

Настройки, примененные в этом файле, применяются только для отдельного пользователя; следовательно, это хороший метод, если вам нужно больше детализации. Мне лично нравится эта функция, чтобы изменить значение umask по умолчанию для пользователя root на 027, тогда как обычные пользователи работают с umask по умолчанию 022.

Суперпользователь

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

Управление ACL (setfacl, getfacl) в Linux

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

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

Понимание ACL

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

Утилита tar не поддерживает ACL. Чтобы убедиться, что настройки ACL не будут потеряны при создании резервной копии, используйте star вместо tar. star работает с теми же параметрами, что и tar; он просто добавляет поддержку настроек ACL.

Вы также можете создать резервную копию ACL с помощью getfacl, которую можно восстановить с помощью команды setfacl. Чтобы создать резервную копию, используйте getfacl -R /directory > file.acls. Чтобы восстановить настройки из файла резервной копии, используйте setfacl —restore=file.acl.

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

Подготовка файловой системы для ACL

Перед началом работы с ACL может потребоваться подготовить файловую систему для поддержки ACL. Поскольку метаданные файловой системы необходимо расширять, не всегда есть поддержка по умолчанию для ACL в файловой системе. Если при настройке списков ACL для файловой системы вы получаете сообщение «operation not supported», возможно, в вашей файловой системе отсутствует поддержка ACL.

Чтобы это исправить, вам нужно добавить опцию acl mount в файле /etc/fstab, чтобы файловая система была смонтирована с поддержкой ACL по умолчанию.

Изменение и просмотр настроек ACL с помощью setfacl и getfacl

Чтобы установить ACL, вам нужна команда setfacl. Чтобы увидеть текущие настройки ACL, вам нужен getfacl. Команда ls -l не показывает никаких существующих ACL; он просто показывает + после списка разрешений, который указывает, что списки ACL применяются и к файлу.

Перед настройкой списков ACL всегда полезно показать текущие настройки ACL с помощью getfacl. Ниже на примере вы можете увидеть текущие права доступа, как показано с помощью ls -ld, а также как показано с getfacl. Если вы посмотрите достаточно внимательно, вы увидите, что показанная информация точно такая же.

[root@server1 /]# ls -ld /dir
drwxr-xr-x. 2 root root 6 Feb 6 11:28 /dir
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

В результате выполнения команды getfacl ниже видно, что разрешения показаны для трех разных объектов: пользователя, группы и других. Теперь давайте добавим ACL, чтобы дать права на чтение и выполнение и группе sales. Команда для этого setfacl -m g:sales:rx /dir. В этой команде -m указывает, что текущие настройки ACL необходимо изменить. После этого g:sales:rx сообщает команде установить ACL для чтения и выполнения (rx) для группы (g) sales. Ниже вы можете увидеть, как выглядит команда, а также вывод команды getfacl после изменения текущих настроек ACL.

[root@server1 /]# setfacl -m g:sales:rx /dir
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
group:sales:r-x
mask::r-x
other::r-x

Теперь, когда вы понимаете, как установить групповой ACL, легко понять ACL для пользователей и других пользователей. Например, команда setfacl -m u:linda:rwx /data дает разрешения пользователю linda в каталоге /data, не делая его владельцем и не изменяя назначение текущего владельца.

Команда setfacl имеет много возможностей и опций. Один вариант особенно важен, параметр -R. Если используется, опция делает настройку ACL для всех файлов и подкаталогов, которые в настоящее время существуют в каталоге, где вы устанавливаете ACL. Рекомендуется всегда использовать эту опцию при изменении списков ACL для существующих каталогов.

Работа с ACL по умолчанию

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

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

Это важно знать. Если вы хотите использовать ACL для настройки доступа нескольких пользователей или групп к одному и тому же каталогу, вы должны установить ACL дважды. Сначала используйте setfacl -R -m, чтобы изменить ACL для текущих файлов. Затем используйте setfacl -m d:, чтобы позаботиться обо всех новых элементах, которые также будут созданы.

Чтобы установить ACL по умолчанию, вам просто нужно добавить опцию d после опции -m (порядок имеет значение!). Поэтому используйте setfacl -m d:g:sales:rx /data, если вы хотите, чтобы группа sales имела доступ на чтение и выполнение всего, что когда-либо будет создано в каталоге /data.

При использовании списков ACL по умолчанию также может быть полезно установить ACL для других. Обычно это не имеет особого смысла, потому что вы также можете изменить разрешения для других, используя chmod. Однако, что вы не можете сделать с помощью chmod, это указать права, которые должны быть предоставлены другим пользователям для каждого нового файла, который когда-либо будет создан. Если вы хотите, чтобы другие не получали никаких разрешений на что-либо, созданное в /data, например, используйте setfacl -m d:o::- /data.

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

Пример управления расширенными правами с использованием ACL

В этом примере вы продолжите работу с каталогами /data/account и /data/sales, которые вы создали ранее. В предыдущих примерах вы гарантировали, что группа sales имеет разрешения на /data/sales, а группа account имеет разрешения на /data/account.

Сначала убедитесь, что группа account получает разрешения на чтение в каталоге /data/sales, а группа sales получает разрешения на чтение в каталоге /data/account.

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

1. Откройте терминал.
2. Выполните setfacl -m g:account:rx /data/sales и setfacl -m g:sales:rx /data/account.
3. Выполните getfacl, чтобы убедиться, что права доступа были установлены так, как вы хотели.
4. Выполните setfacl -m d:g:account:rwx,g:sales:rx /data/sales, чтобы установить ACL по умолчанию для каталога sales.
5. Добавьте ACL по умолчанию для каталога /data/account, используя setfacl -m d:g:sales:rwx,g:account:rx /data/account.
6. Убедитесь, что настройки ACL действуют, добавив новый файл в /data/sales. Выполните touch /data/sales/newfile и выполните getfacl /data/sales/newfile для проверки текущих разрешений.

Управление владением файлами

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

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

В Linux у каждого файла и каждого каталога есть два владельца: пользователь и группа.

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

Это происходит в следующем порядке:

1. Оболочка проверяет, являетесь ли вы владельцем файла, к которому вы хотите получить доступ. Если вы являетесь этим владельцем, вы получаете разрешения и оболочка прекращает проверку.
2. Если вы не являетесь владельцем файла, оболочка проверит, являетесь ли вы участником группы, у которой есть разрешения на этот файл. Если вы являетесь участником этой группы, вы получаете доступ к файлу с разрешениями, которые для группы установлены, и оболочка прекратит проверку.
3. Если вы не являетесь ни пользователем, ни владельцем группы, вы получаете права других пользователей (Other).

Чтобы увидеть текущие назначения владельца, вы можете использовать команду ls -l. Эта команда показывает пользователя и группу-владельца. Ниже вы можете увидеть настройки владельца для каталогов в каталоге /home.

[root@server1 home]# ls -l
total 8
drwx------. 3  bob            bob            74     Feb   6   10:13 bob
drwx------. 3  caroline       caroline       74     Feb   6   10:13 caroline
drwx------. 3  fozia          fozia          74     Feb   6   10:13 fozia
drwx------. 3  lara           lara           74     Feb   6   10:13 lara
drwx------. 5  lisa           lisa           4096   Feb   6   10:12 lisa
drwx------. 14 user           user           4096   Feb   5   10:35 user

find / -user linda

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

find / -group users

Изменение владельца

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

chown кто что

Например, следующая команда меняет владельца каталога /home/account на пользователя linda:

chown linda /home/account

Команда chown имеет несколько опций, одна из которых особенно полезна: -R. Вы можете догадаться, что она делает, потому что эта опция доступна и для многих других команд. Это позволяет вам рекурсивно устанавливать владельца, что позволяет вам установить владельца текущего каталога и всего, что находится ниже. Следующая команда меняет владельца для каталога /home и всего, что находится под ним, на пользователя lisa:

Сейчас владельцы выглядят так:

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 account account 62 Sep 25 21:41 account
drwx------. 2 lisa    lisa    62 Sep 25 21:42 lisa

[root@localhost ~]# chown -R lisa /home/account
[root@localhost ~]#

Теперь пользователь lisa стал владельцем каталога account:

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 lisa account 62 Sep 25 21:41 account
drwx------. 2 lisa lisa    62 Sep 25 21:42 lisa

Изменение владельца группы

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

Следующая команда изменяет какого-либо владельца группы /home/account на группу account:

chown .account /home/account

Вы можете использовать chown для изменения владельца пользователя и/или группы несколькими способами. Вот несколько примеров:

• chown lisa myfile1 устанавливает пользователя lisa владельцем файла myfile1.
• chown lisa.sales myfile устанавливает пользователя lisa владельцем файла myfile, а так же устанавливает группу sales владельцем этого же файла.
• chown lisa:sales myfile то же самое, что и предыдущая команда.
• chown .sales myfile устанавливает группу sales владельцем файла myfile без изменения владельца пользователя.
• chown :sales myfile то же самое, что и предыдущая команда.

Вы можете использовать команду chgrp, чтобы изменить владельца группы. Рассмотрим следующий пример, где вы можете с помощью chgrp установить владельцем каталога account группу sales:

chgrp .sales /home/account

Как и в случае с chown, вы можете использовать опцию -R с chgrp, а также рекурсивно менять владельца группы.

Понимание владельца по умолчанию

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

Чтобы показать текущую эффективную первичную группу, пользователь может использовать команду groups:

[root@server1 ~]# groups lisa
lisa : lisa account sales

Если текущий пользователь linda хочет изменить эффективную первичную группу, он будет использовать команду newgrp, за которой следует имя группы, которую он хочет установить в качестве новой эффективной первичной группы. После использования команды newgrp первичная группа будет активна, пока пользователь не введет команду exit или не выйдет из системы.

Ниже показано, как пользователь lisa использует эту команду, что бы первичной группой стала группа sales:

lisa@server1 ~]$ groups
lisa account sales
[lisa@server1 ~]$ newgrp sales
[lisa@server1 ~]$ groups
sales lisa account
[lisa@server1 ~]$ touch file1
[lisa@server1 ~]$ ls -l
total 0
-rw-r--r--. 1 lisa sales 0 Feb 6 10:06 file1

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

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

Запуск команды от пользователя root

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

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

sudo cat journal.log

Присвоение привилегий sudo

По умолчанию пользователи создаются в системе без доступа к sudo. Это делается вручную с помощью добавления учётной записи к одноимённой группе:

gpasswd -a username sudo

В CentOS группа с полными привилегиями администратора называется wheel, значит вы можете использовать примеры выше, заменив sudo на wheel. 

Резюме

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

Если вам понравился этот перевод, то прошу написать об этом в комментариях. Будет больше мотивации делать полезные переводы.

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

Вместо «Только кто-то с административными правами на каталог может применять разрешение на выполнение.» исправил на «Только кто-то с правами записи на каталог может применять разрешение на выполнение.», что будет более правильным.

За замечания спасибо berez.

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

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

Спасибо за замечание CryptoPirate

Смена пользователя на root

Связки ключей

Есть ещё один интересный механизм, связанный с обеспечением безопасности. Дело в том, что для хранения различных пользовательских паролей в Ubuntu используются так называемые связки ключей (keyrings). Весь этот механизм служит одной цели — никто, кроме конкретного пользователя, не должен иметь доступа к пользовательским паролям. Связка ключей — это собственно зашифрованный контейнер для хранения паролей, для доступа к которому строго говоря тоже нужен пароль. Кстати, связки ключей не имеют ничего общего с административными правами. Они принадлежат конкретному пользователю и вообще не зависят от прав доступа к системным параметрам.

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

Что ж, надеюсь вы немного разобрались с тем, как управлять вашей новой системой. Если же всё вышеописанное показалось вам китайской грамотой, то запомните одну простую вещь: в Ubuntu у каждого пользователя есть только один пароль, и когда у вас система запрашивает авторизацию, всегда вводите именно его³⁾. Если у вас будут права на доступ к запрашиваемому функционалу, то вы получите к нему доступ, если не будет — то не получите, всё просто. Никаких дополнительных паролей для доступа к каким-либо функциям системы в Ubuntu нет. Если вы так и не поняли смысла вводить один и тот же пароль несколько раз, то перечитайте эту статью с начала. А теперь пора отдать должное истории развития Linux и рассказать про основы использования терминала:

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

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

sudo <команда>

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

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

sudo -K

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

sudo cat test.txt | grep text > result.txt

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

Ссылки

• Настройка sudo — топик на форуме о времени действия пароля

Расширенные права

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

Понимание расширенных прав SUID, GUID и sticky bit

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

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

Рассмотрим, например, ситуацию, когда пользователю необходимо сменить пароль. Для этого пользователь должен записать свой новый пароль в файл /etc/shadow. Однако этот файл недоступен для записи пользователям, не имеющим прав доступа root:

root@hnl ~]# ls -l /etc/shadow
----------. 1 root root 1184 Apr 30 16:54 /etc/shadow

Разрешение SUID предлагает решение этой проблемы. В утилите /usr/bin/passwd это разрешение применяется по умолчанию. Это означает, что при смене пароля пользователь временно получает права root, что позволяет ему записывать в файл /etc/shadow. Вы можете видеть разрешение SUID с ls -l как s в позиции, где обычно вы ожидаете увидеть x для пользовательских разрешений:

[root@hnl ~]# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 32680 Jan 28 2010 /usr/bin/passwd

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

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

Второе специальное разрешение — это идентификатор группы (SGID). Это разрешение имеет два эффекта. При применении к исполняемому файлу, он дает пользователю, который исполняет файл, разрешения владельца группы этого файла. Таким образом, SGID может выполнить более или менее то же самое, что SUID. Однако для этой цели SGID практически не используется.

Как и в случае с разрешением SUID, SGID применяется к некоторым системным файлам в качестве настройки по умолчанию.

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

Это не всегда очень полезно, особенно потому, что у пользователей Red Hat/CentOS в качестве основной группы задана группа с тем же именем, что и у пользователя, и из которых пользователь является единственным участником. Таким образом, по умолчанию файлы, которые создает пользователь, будут групповыми для общего доступа.

Представьте себе ситуацию, когда пользователи linda и lori работают в бухгалтерии и являются членами группы account. По умолчанию эти пользователи являются членами частной группы, единственным членом которой они являются. Однако оба пользователя являются членами группы account, но также и в качестве параметра вторичной группы.

Ситуация по умолчанию состоит в том, что когда любой из этих пользователей создает файл, основная группа становится владельцем. Поэтому по умолчанию linda не может получить доступ к файлам, созданным lori, и наоборот. Однако, если вы создаете общий каталог группы (скажем, /groups/account) и убедитесь, что разрешение SGID применено к этому каталогу и что учет группы установлен как владелец группы для этого каталога, все файлы, созданные в этом каталоге и во всех его подкаталогах, также получают account группы как владельца группы по умолчанию.

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

Разрешение SGID показывается в выводе ls -ld как s в позиции, где вы обычно находите разрешение на выполнение группы:

[root@hnl data]# ls -ld account
drwxr-sr-x. 2 root account 4096 Apr 30 21:28 account

Третий из специальных разрешений — sticky bit. Это разрешение полезно для защиты файлов от случайного удаления в среде, где несколько пользователей имеют права на запись в один и тот же каталог. Если применяется закрепленный sticky bit, пользователь может удалить файл, только если он является пользователем-владельцем файла или каталога, в котором содержится файл. По этой причине он применяется в качестве разрешения по умолчанию для каталога /tmp и может быть полезен также для каталогов общих групп.

Без sticky bit, если пользователь может создавать файлы в каталоге, он также может удалять файлы из этого каталога. В общедоступной групповой среде это может раздражать. Представьте себе пользователей linda и lori, которые оба имеют права на запись в каталог /data/account и получают эти разрешения благодаря участию в группе account. Поэтому linda может удалять файлы, созданные lori, и наоборот.

Когда вы применяете sticky bit, пользователь может удалять файлы, только если выполняется одно из следующих условий:

• Пользователь является владельцем файла;
• Пользователь является владельцем каталога, в котором находится файл.

При использовании ls -ld, вы можете видеть sticky bit как t в позиции, где вы обычно видите разрешение на выполнение для других:

[root@hnl data]# ls -ld account/
drwxr-sr-t. 2 root account 4096 Apr 30 21:28 account/

Применение расширенных прав

Чтобы применить SUID, SGID и sticky bit, вы также можете использовать chmod. SUID имеет числовое значение 4, SGID имеет числовое значение 2, а sticky bit имеет числовое значение 1.

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

chmod 2755 /somedir

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

1. Для SUID используйте chmod u+s.
2. Для SGID используйте chmod g+s.
3. Для sticky bit используйте chmod +t, а затем имя файла или каталога, для которого вы хотите установить разрешения.

В таблице обобщено все, что важно знать об управлении специальными разрешениями.

Пример работы со специальными правами

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

1. Откройте терминал, в котором вы являетесь пользователем linda. Создать пользователя можно командой useradd linda, добавить пароль passwd linda.
2. Создайте в корне каталог /data и подкаталог /data/sales командой mkdir -p /data/sales. Выполните cd /data/sales, чтобы перейти в каталог sales. Выполните touch linda1 и touch linda2, чтобы создать два пустых файла, владельцем которых является linda.
3. Выполните su — lisa для переключения текущего пользователя на пользователя lisa, который также является членом группы sales.
4. Выполните cd /data/sales и из этого каталога выполните ls -l. Вы увидите два файла, которые были созданы пользователем linda и принадлежат группе linda. Выполните rm -f linda*. Это удалит оба файла.
5. Выполните touch lisa1 и touch lisa2, чтобы создать два файла, которые принадлежат пользователю lisa.
6. Выполните su — для повышения ваших привилегий до уровня root.
7. Выполните chmod g+s,o+t /data/sales, чтобы установить бит идентификатора группы (GUID), а также sticky bit в каталоге общей группы.
8. Выполните su — linda. Затем выполните touch linda3 и touch linda4. Теперь вы должны увидеть, что два созданных вами файла принадлежат группе sales, которая является владельцем группы каталога /data/sales.
9. Выполните rm -rf lisa*. Sticky bit предотвращает удаление этих файлов от имени пользователя linda, поскольку вы не являетесь владельцем этих файлов. Обратите внимание, что если пользователь linda является владельцем каталога /data/sales, он в любом случае может удалить эти файлы!

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

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

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

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

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

Defaults:foo timestamp_timeout=20

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

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

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

sudo -s
sudo -i

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

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

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

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

sudo visudo

%admin ALL=(ALL) ALL

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

man sudoers

Если вы допустите ошибку при редактировании этого файла, то вполне возможно полностью лишитесь доступа к административным функциям. Если такое случилось, то необходимо загрузиться в recovery mode, при этом вы автоматически получите права администратора и сможете всё исправить. Кроме того, отредактировать этот файл можно с LiveCD.

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

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

# Cmnd alias specification
Cmnd_Alias SHUTDOWN_CMDS = /sbin/shutdown, /usr/sbin/pm-hibernate, /sbin/reboot

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

имя_пользователя ALL=(ALL) NOPASSWD: SHUTDOWN_CMDS

Внимание! Вышеописанные действия не отменяют необходимости ввода команды sudo перед вашей командой

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

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

  ~bashrc 

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

 =
 =
 pm-hibernate=
 =
 = 

Настройка sudo

Настроить команду sudo можно в файле /etc/sudoers, в нём хранятся все нужные параметры. Этот файл напрямую влияет на работу системы, если он сконфигурирован неправильно или содержит ошибки синтаксиса, система может начать работать некорректно. 

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

Работать с файлом sudoers вы можете в любом удобном текстовом редакторе. По умолчанию visudo открывает vi (в Ubuntu — nano), но может работать и с другими. Для этого выберете нужный вариант с помощью команды update-alternatives:

sudo update-alternatives --config editor

В CentOS задать редактор по умолчанию ещё проще — в ~/.bashrc нужно добавить строку:

После того, как вы определились с редактором, в котором вам удобно работать с файлом, можно приступать к настройке sudo.

Для работы с файлом sudoers у вас уже должен быть доступ к учётной записи суперпользователя. Откройте файл с помощью программы visudo:

В нашей оболочке откроется файл sudoers. По умолчанию он состоит из нескольких групп строк. 

Настройки по умолчанию

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

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

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

secure_path определяет путь для операций sudo. Иными словами, она содержит каталоги, в которых ОС будет искать приложения. Переопределяя пользовательские настройки, мы избегаем выполнения потенциально вредоносных программ.

Вы можете добавлять настройки по умолчанию с помощью псевдонима Default. Например, если у вас сложный пароль, вы можете расширить количество попыток ввода с трёх (по умолчанию) до 5. 

Sudo сохраняет данные сеанса в течение 5 минут после первой аутентификации. Это сделано, чтобы вам не нужно было каждый раз при выполнении программ вводить пароль. Вы можете сбросить форсировать запрос пароля с помощью флага -k при выполнении команды sudo. Если нужно вводить пароль каждый раз, установите значение этого таймаута 0.

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

Defaults passwd_timeout=5
Defaults logfile=/var/log/sudo.journal.log

Четвёртая строка определяет привилегии sudo для root. Она содержит имя пользователя, список хостов, пользователей, групп и команд. 

root    ALL=(ALL:ALL) ALL

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

Добавим новые полномочия для пользователя timeweb-backup, которому нужно выполнять команду монтирования директории root/backup.d. Для этого добавим следующую строку:

timeweb-backup ALL=(root) /bin/mount /root/backup.d

Теперь пользователь timeweb-backup сможет запустить команду sudo mount /root/backup.d со своим паролем, а не с паролем пользователя root. 

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

Подключение других файлов

Строка, которая начинается с означает подключение конфигурации из других источников. В данном случае указано, что нужно применить правила из файлов внутри каталога /etc/sudoers.d, при этом подключается любой файл, если он не содержит в названии точку или не заканчивается тильдой (~). 

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

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

visudo -f /etc/sudoers.d/config_file

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

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

Cmnd_Alias. Псевдоним команды.

Например, отредактируем файл sudoers так, чтобы различные пользователи могли запускать скрипты резервирования системы от пользователя root.

Host_Alias REMOTE = cloud.timeweb.com
Cmd_Alias Cmds = /root/backup

После создания псевдонима применяем правило:

Теперь пользователи timeweb-backup, remote, hal9000 смогут запускать команды бэкапа от имени пользователя root на хосте REMOTE. 

Представим, что этим пользователям должна быть доступна команда монтирования, при этом мы можем пренебречь вводом пароля:

Cmnd_Alias APT_UPDATE = /usr/bin/apt-get update,/usr/bin/apt-get upgrade

Псевдонимы помогут эффективно делить пользователей на группы и выдавать им права (или забирать их с помощью флага NOEXEC) на выполнение только определённых команд.

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

Вы можете запускать команды sudo от имени тех пользователей или групп, которых задали в файле sudoers. Используйте для этого флаги -u и -g соответственно. 

Чтобы посмотреть привилегии для вашего пользователя, просто используйте команду sudo -l. Вы увидите список всех правил из файла /etc/sudoers. Так вы поймёте, на что именно у вас есть разрешение в системе.  

Администратор и суперпользователь

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

Администратор

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

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

Если вы введете правильно (и если вы являетесь администратором, конечно), то откроется собственно сам Synaptic:

Как пользоваться этой программой я расскажу в статье про установку приложений, а пока закройте её.

Кстати, если вы введёте в подобное окно пароль не правильно, то система просто закроет его и ничего вам не скажет. Соответственно и операция, для которой требовались права администратора, выполнена не будет. Имейте это ввиду.

Видите, вы не можете ничего изменить, поскольку все поля заблокированы. Однако внизу находится кнопка с ключиком, рядом с которой написано «Нажмите для внесения изменений». Нажмите её, система снова спросит ваш пароль, правда несколько иным образом:

И если у вас есть полномочия на изменение даты и времени (а у администратора они естественно есть), то система откроет вам доступ к настройкам:

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

Разблокировка учетной записи root приводит неоправданным рискам (работая постоянно под рутом вы имеете 100500 способов «отстрелить себе ногу»), а также упрощает получение доступа к вашему компьютеру злоумышленником.

Ubuntu 11.04 и младше

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

sudo passwd root

Ubuntu 11.10 и старше

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

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

sudo passwd root

gksu gedit /etc/lightdm/lightdm.conf

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

greeter-show-manual-login=true

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

sudo service lightdm restart

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

sudo passwd -l root