В Ubuntu временно заблокирована (https://www.ubuntu.com/usn/usn-3285-1/) возможность использования гостевого сеанса в дисплейном менеджере LightDM из-за выявления уязвимости (https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1663157) (CVE-2017-8900 (https://security-tracker.debian.org/tracker/CVE-2017-8900)), которая позволяет получить доступ к файлам вне гостевой директории, в том числе к файлам в домашних каталогах обычных пользователей. Проблема проявляется в начиная с Ubuntu 16.10 и вызвана прекращением применения ограничений AppArmor (в Ubuntu 16.04 и более ранних выпусках применялся профиль /usr/lib/lightdm/lightdm-guest-session) после перехода к использованию systemd для управления сеансами. В качестве возможного пути устранения проблемы рассматривается использование модуля pam_apparmor для применения ограничивающего профиля AppArmor.URL: https://www.ubuntu.com/usn/usn-3285-1/
Новость: https://www.opennet.ru/opennews/art.shtml?num=46537
Показателен ответ разработчиков Ubuntu на сообщение о баге, которое было отправлено ещё в феврале:"Ow. Unfortunately I don't have any information on how to fix this since most of the work on guest sessions and systemd was done by Martin Pitt."
В итоге, после трёх месяцев не придумали ничего, чем просто отключить гостевой сеанс.
Зря ругаешь. Это обычный самоотвод, т.к. вопрос вне компетенций данного инженера. Во всем виноват systemd, это очевидно.
То есть в других дистрибутивах с systemd всё нормально, и только в Ubuntu проблемы, но виноват все равно systemd. Логика железная.
> То есть в других дистрибутивах с systemd всё нормально, и только в
> Ubuntu проблемы, но виноват все равно systemd. Логика железная.Без СистемД данная проблема была ?
а без убунты, а без линукса?
То есть если бы был открыт доступ к ssh с публичным паролем, это была бы проблема ssh? Ведь без него проблемы нет.
Нас в садике учили: если не хочешь, чтобы другие другие видели твои файлы, сделай chmod 700 $HOME.
там немного другое: на системе есть зареганые юзеры - они могут видеть файлы друг друга, и есть гостевой сеанс - он не должен видеть файлы остальных узверей. вот это "не должен" и сломали при внедрении systemdвообще странно что гостя тупо не засунули под контейнера, это самый очевидный способ загнать в клетку
засовывать его в контейнер ещё тот аттракцион, причём с учётом того что нужно будет пропихнуть в контейнер, не факт что поможет.
> они могут видеть файлы друг друганаверно могут те -- которые сделали их друг для друга доступными через вызов setfacl?
> и есть гостевой сеанс - он не должен видеть файлы остальных узверей
потому что ни кто не делал вызов setfacl для него?
> наверно могут те -- которые сделали их друг для друга доступными через вызов setfacl?Неа. По дефолту юзеры без проблем могут шастать по чужой домашней папке
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/
1. $ find /home/user -type f -exec chmod 600 {} \;
2. $ find /home/user -type d -exec chmod 700 {} \;Только не перепутайте последовательность.
1. Достаточно {} или нужно "{}" (с кавычками)?
2. Что будет если перепутать последовательность?
1. На практике достаточно.
2. Не войдете потом ни в одну папку в домашней директории.
3. Имя пользователя нужное не забудьте подставить вместо "user".
> 2. Не войдете потом ни в одну папку в домашней директории.Подозреваю ты хотел сказать "не перепутайте "-type d ... 700" с "-type d ... 600"
$ chmod -R a=,u+rwX ~
> $ chmod -R a=,u+rwX ~chmod -R go-rwx ~ # у группы и осталных отобрать read, write, execute
А что ваш набор букв означает?
>> $ chmod -R a=,u+rwX ~
> chmod -R go-rwx ~ # у группы и осталных отобрать read, write,
> execute
> А что ваш набор букв означает?Мой "набор букв" означает сначала рекурсивно забрать все права у всех (000), а потом рекурсивно дать права на чтение, запись и открытие директорий владельцу (600 для файлов и 700 для директорий) Всё в одном "наборе букв".
Ваш же "набор букв" только забирает права у группы и остальных, но не забирает бит исполнения у владельца, а также не гарантирует наличие прав на чтение, запись и открытие директорий у его владельца.
Тут ~/bin/* передают тебе привет.
> Тут ~/bin/* передают тебе привет.В том-то и дело, что зонды, спайвари и прочая нечисть не сможет этого сделать.
А если Вы разработчик и у Вас в ~/bin/ проекты, то
1 Вы сами должны знать об этом и управлять правами!
2 При желании, Вам ничего не должно мешать запустить их через оболочку sh ~/bin/appname
3 QtCreator, возможно и другие IDE, сами при пересборке проекта назначают бит исполнения свеже-собранному эльфу.
> Неа. По дефолту юзеры без проблем могут шастать по чужой домашней папкеВ зависимости от дефолтных настроек.
Тогда все юзеры идут в группу users, а гость в группу guest, права выставляем соответсвенно.
(с) мопед не мой -- подход придуман где-то в ранних 70-х умными людьми и вроде как обкатан и железобетонно работал всё это время.
Меня тоже в убунте иногда удивляет желание разработчиков прикрутить свои "велосипеды" вместо использования простого рабочего решения.
он под "appaarmor"
> там немного другое: на системе есть зареганые юзеры - они могут видеть
> файлы друг другаВсе давно уже есть, делаете специальную группу для этих вездешастающих юзеров, добавляете их в ту группу и делаете
chmod 750 ~
chown :special_group ~voila!
Кстати, если просто хочется закрыть доступ к домашнему каталогу для других пользователей (включая системных пользователей как nobody и daemon), в chmod не нужно -R, path traversal не будет работать если нет доступа к хотя бы одному каталогу. chmod 700 $HOME хватит. Адептам find ... -exec chmod советую "chmod 700 /".
Они могут видеть потому что являются членами группы, которой разрешено смотреть в чужие хоумы. И это "не должен" не зависит от системдэ.
трудное у тебя было детство, сочувствую
сколько ещё нам чудных открытий готовит системде
Это ещё мелочи. Вот когда его ломать начнут...
> Это ещё мелочи. Вот когда его ломать начнут...поскорее бы, а то скушно читать хейтеров systemd, одна слюна и никакой крошки
>> Это ещё мелочи. Вот когда его ломать начнут...
> поскорее бы,А что, самостоятельные сломы типа
https://github.com/systemd/systemd/issues/1143
> By setting the date to sometime in 2038, we can make systemd getting stuck printing systemd[1]: Time has been changed over and over again.или
https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_... (ну да, кто бы мог подумать, что параметр-то пустой будет, а?)
ну или
https://github.com/systemd/systemd/issues/5644
> tmpfiles: R! /dir/.* destroys roothttps://github.com/systemd/systemd/issues/5441
> Assertion 'path' failed .. Freezing executionуже не считаются, да?
> а то скушно читать хейтеров systemd,
Так возьмите и почитайте код systemd. Правда, можете сами стать хейтером.
> одна слюна и никакой крошкиОдни фантазии поттерофилов и никакой конкретики.
> Одни фантазии поттерофилов и никакой конкретики.эту школоту надо заставить пользоваться своим фетишем, а не блеять о его офигенности на форумах, вот тогда и посмеяться можно будет
Ах да, в убунту же сделали гостевой аккаунт. Ещё в релизе 8.10... Так и не затестил. Спасибо что напомнили!
> Ах да, в убунту же сделали гостевой аккаунт. Ещё в релизе 8.10...
> Так и не затестил. Спасибо что напомнили!Неожиданно вспомнил о нём когда человеку(не случайному) срочно понадобился комп, а дома был ноут с убунтой :)
> Неожиданно вспомнил о нём когда человеку(не случайному) срочно понадобился комп, а дома
> был ноут с убунтой :)боюсь спросить - там adduser поломан уже насовсем, или "не случайному" - в смысле, полицаи пришли, cp искать, и надо было срочно сделать вид, что никаких других юзеров там нет?
>полицаи пришли, cp искатьИ нашли в /bin?
Поттеринг же, теперь cp в /usr/bin. Вот так мы беспалевно храним ЦоПэ в /bin/cp, и никто даже не думает там искать :-)
Да в чем пилять юмор. Я уж и гугол теребил. И в рестриктет шел cp нормально работает.
Что за фишка с гостевым пользователем и cp?
> Проблема проявляется начиная с Ubuntu 16.10 и вызвана прекращением применения ограничений AppArmor (в Ubuntu 16.04 и более ранних выпусках применялся профиль /usr/lib/lightdm/lightdm-guest-session) после перехода к использованию systemd для управления сеансами.А я уже думал на что же переходить с LinuxMint 17 (который на основе 14.04)
> Linux Mint 18 is based on Ubuntu 16.04.
Тогда надо брать.
Эта долбанная AppArmor вместо того чтобы защищать систему наоборот позволяет получить доступ над всем сервером на ubuntu и debian злодей 3 раза уже взламывал через нее мой сервер представляясь как кэш полиция Гугла блокируя мои директивы, пристраивая свой кэш и воруя мой трафик, сразу и не заметишь, при этом не позволяя мне отключить ее, приходилось полностью переустанавливать систему и сервер, если бы не отдельный аккаунт на VPS биллинг то полностью бы потерял контроль над сервером. Разработчикам стоит задуматься над этим полуфабрикатом а не запускать ее по умолчанию.