Хотелось сделать все без костылей, но оказалось все нормальные решения(SELinux,AppArrmor) замедляют работу приложения. Решил с помощью костыля - запускаю от имени другого пользователя.
Имхо это как раз нормальное решение, хоть и не слишком надёжное, а то - костыли, которые обеспечивают лишь немногим большую безопасность. И вообще, у них цель другая - ограничивать тот же хромиум, а не наоборот.
Права: запись и чтение для хозяина, для остальных чтение, это меня вполне устраивает. Дал право на запись для других в папку Загрузки и все качает прямо в нужную папку.
Это нормальное решение только для этой ситуации. А если нужно было бы еще такие ограничения ставить, например чтобы к папке с моими проектами имел доступ только geany, к музыке только clementine, к почте только trunderbird и т.д., то надоест пользователей создавать, а с AppArrmor это было бы намного проще, но естественно производительность уменьшать никому не хочется.
Стесняюсь спросить зачем это нужно. Я стараюсь практически каждое не надёжное приложение запускать от отдельного юзера и это вполне нормально, хоть и слабая преграда в случае направленной атаки. В крайнем случае можно группировать по задачам, если нужно ограничивать всё. Интересно, как там поживает TOMOYO.
Возможно и так, я не дочитал статью по настройке apparmor до конца, я дошёл до строчки о том, что это сильно понижает производительность, а дальше читать смысла не было.
Я решил подумать о безопасности и подумал как бы я атаковал свой компьютер (опыт написания вредоносных имеется, но этот опыт никогда не применялся для причинения вреда). Немного подумал я нашёл кучу способов наделать на своём ПК гадостей, все было быстро исправлено кроме одной проблемы, любая программа запущенная от моего пользователя могла получить доступ к cookie chromium'а, вначале я подумал запускать chromium от имени другого пользователя, но решил спросить на лоре может есть решения поэлегантней, но поэлегантней оказалось потормознутей.
Насчет ненадёжных приложений, вредоносным может оказаться надёжное приложение, например: возьмём gnome-mplayer, он на порядок хуже smplayer и многие используют последний, что лично мне помешает вступить в команду разработчиков gnome-mplayer (или форкнуть его) и постепенно довести его качество до уровня smplayer, те у кого в системе большинство приложений используют gtk автоматом перейдут на gnome-mplayer(или форк), а затем я пишу шикарный встроенный в приложение браузер youtube, vimeo, vk.com, в котором будет 5 тыс строк запутанного говно-кода с ассемблерными вставками и с минимальным количество комментариев, и спрячу в самом неприметно месте несколько строк вредоносного кода, и кто этот код изучать будет?, правильно - никто. А теперь случай из жизни http://www.opennet.ru/opennews/art.shtml?num=28998. Так что надёжное приложение может в любой момент стать ненадёжным.
Вы всё ещё считаете медиаплееры надёжным ПО? Ваши проблемы. Достаточно вспомнить о том, какое ffmpeg решето. От бэкдоров в системных компонентах мало что поможет, а 5 тыс строк запутанного кода с вставками на асме впихнуть в сколько-нибудь популярный проект не так просто, и в любом случае такие патчи проходят аудит в открытых проектах, тем более что это не много, а ассемблер по определению повышает подозрительность к коммитеру. Единственное сколько-нибудь надёжное решение - gentoo hardened, но это не значит, что нельзя сломать, это значит, что цена взлома будет несколько выше и шансов сделать это - меньше.
А утечка кук это не очень страшно, на самом деле. Большинство сколько-нибудь серьёзных сервисов не ставит долгоживущие куки и принимает дополнительные меры безопасности, и это вообще ни от чего не спасёт в случае, скажем, кражи какой-нибудь базы данных со стороны сервера.
Нет не считаю, но запускать медиаплеер в песочнице или от имени другого пользователя - паранойя 80 уровня. Да и медиаплеер я привел только для примера.
5 тыс строк запутанного кода с вставками на асме впихнуть в сколько-нибудь популярный проект не так просто, и в любом случае такие патчи проходят аудит в открытых проектах, тем более что это не много, а ассемблер по определению повышает подозрительность к коммитеру.
Однако регулярно появляются в популярных проектах уязвимости, а значит аудит не помог - недосмотрели.
А утечка кук это не очень страшно, на самом деле. Большинство сколько-нибудь серьёзных сервисов не ставит долгоживущие куки и принимает дополнительные меры безопасности, и это вообще ни от чего не спасёт в случае, скажем, кражи какой-нибудь базы данных со стороны сервера.
У меня долгоживущие cookie от gmail и потеря моего почтового ящика будет для меня очень неприятна.
Это не значит, что их добавляют намеренно. При полном отсутствии исходников уязвимостей находят не меньше.
gmail
Для изменения учётных данных необходим пароль от аккаунта, а в целом крайне не желательно оставлять залогинеными аккаунты с важной информацией, точно также их сможет посмотреть любой желающий при наличии физического доступа.
Это не значит, что их добавляют намеренно. При полном отсутствии исходников уязвимостей находят не меньше.
Я и не имел ввиду, что их добавляют намеренно, я имел ввиду, что присоеденившись к команде разработчиков можно намеренно сделать такую уязвимость и вероятность того, что её заметят сразу невелика, та же недавняя новость про уязвимость в ядре - появилась уязвимость в 2009 г. нашли в 2013 г.
Для изменения учётных данных необходим пароль от аккаунта, а в целом крайне не желательно оставлять залогинеными аккаунты с важной информацией, точно также их сможет посмотреть любой желающий при наличии физического доступа.
Физическим доступом к моему пк есть только у меня. Если я не оставлю залогиненым почту то мне прийдется вводить пароль заново каждый раз когда я захочу почту посмотреть, а пароль у меня состоит из прописных и строчных букв, знаков, цифр, длинна пароля более 20 символов, каждый раз вводить такой пароль - мазохизм.