А в чем проблема? Сорри, я лично даже не знаю, как его ставить не из консоли. Текстовой редактор есть, apt-get есть, wget есть, даже консольный браузер, если уж вообще приспичит, есть. Обычно все руководства в инете рассчитаны именно на работу с консолью.
А как вы проприетарные драйвере ставите, не используя консоль?
Если вы боитесь, что будут какие-то проблемы, то советую просто подождать с обновлением. Обычно в первые дни всегда находятся какие-то косяки, но и правят их быстро. А ставить с нуля лично для меня не резон — это не по-джедайски. Линукс — это не такая система, которую надо при каждом чихе ставить с нуля, обычно все проблемы можно решить.
А насчет видеодрайвера — всегда есть Ctrl-Alt-F1, в консоли конфигурируйте драйвер как вам надо (обновить или поставить другой). Возврат обратно в графический режим — Alt-F7.
На свой ноут как поставил в свое время 9.04 x64, так с тех пор и работаю, все нормально. Без проблем прошло обновление на 9.10. Были некоторые заморочки с флешем, и то они были вызваны собственно Adobe, а не Canonical. Сейчас никаких неудобств не испытываю — все железо определяется, используются корректные драйвера, ждущие и спящие режимы работают.
Тема действительно весьма обширная, но в данном контексте делать отдельные статьи для новичков и профи не считаю разумным — механизмы одинаковые, отличаются лишь способы использования. А вот описывать как использовать то или иное средство — это тема для отдельной книги, а не статьи.
Но есть другая проблема — лишь после написания статьи я понял, что за бортом осталась сетевая безопасность, шифрование, внутренние механизмы безопасности в ядре, обеспечение целостности данных и другие темы. Если даже просто перечислять средства, то это получится очень большой список, который не потянет на формат статьи. Так что я решил оставить все как есть, а если кто-то проявит заинтересованность в отдельной теме, то можно будет написать новую статью.
Про getfacl/setfacl упомянул. Описание chroot тоже поменял, хотя оно и стало немного громоздким.
Про SELinux важнее было бы сказать, что в отличие от других систем, контекст исполнения выстанавливается для исполяемых данных с определенных инодов, а не для текущего пользователя, или пользователя-владельца процесса.
Немного не понял. SELinux не отменяет использование стандартных ACL. Если процесс исполняется от имени пользователя, у которого нет доступа, то и у процесса доступа не будет. Можно пояснить вашу мысль?
AppArmor — стандарт де-факто для Ubuntu и SuSE. В альтернативы я никак не могу его поместить, т.к. эта система широко используется.
pivot_root — как я понимаю, это утилита специализирована для Linux. Сорри за мое UNIX-прошлое, я не знаком с ней. Она часто используется? Стоит ли ее упоминать?
NSS — мне кажется, это довольно-таки вспомогательная технология. Сорри за плохую аналогию, но SSH как бы тоже относится к безопасности, но это не повод его упоминать в качестве средства и/или механизма обеспечения безопасности (хотя в каком-то смысле он таковым является).
PAX еще жив? Я слышал про него несколько лет назад, но не знаю текущий статус. Судя по докам в инете все не так хорошо, как хотелось бы. То же самое касается Grsecurity. То, что не входит в мейнстрим, я не рассматривал, это же касается и RSBac. Но упомянуть в качестве дополнительных материалов могу. Если у вас на примете есть еще какие-нибудь интересные аббревиатуры, дайте знать.
Про механизмы ядра думаю нет смысла рассказывать, — конечным пользователям, конечно, будет приятно, что это есть, но для безопасной работы с системой это необязательно.
Я не спорю, но признаюсь честно, я не знаю централизованных VCS (и которые при том еще используются), которые не пихают свои внутренние каталоги по всему проекту. Удовлетворите любопытство, если не сложно. Системы, которые работают только под Windows, можно не упоминать.
Спасибо, добавил. В принципе, я на это не хотел особо концентрировать внимание, т.к. думаю, что все знают как работать с ACL. Но для новичков пригодится.
В комментариях были даны толковые ответы, но я бы хотел от себя добавить одно замечание. Наиболее лучшим и безопасным решением будет использовать сервер контроля версий, причем лучше DVCS, а не svn или cvs (думаю все помнят, как смогли поломать кучу серверов прочитав системные директории .svn). Т.е. вы работаете на своей рабочей станции, заливаете код в git/hg/bzr, а на стороне сервере делаете update под нужным пользователем (www или www-data, зависит от настроек). Помимо того, что будет хорошая безопасность, вы сможете более тщательно контролировать ревизии, откатиться при каких-то проблемах и т.п.
Многие разработчики знают filemon, но не знают strace и другие утилиты. Достаточно посмотреть в гугле количество запросов «filemon linux». И везде одни и те же советы — используйте strace, lsof, inotify etc.
К слову сказать, прямые аналоги есть, например File monitoring with Mortadelo and SystemTap. Но SystemTap использует debug-версию ядра, поэтому я его упомянул лишь в постскриптуме.
«Серверный» в данном контексте означает, что система работает без взаимодействия с пользователем. И SELinux и AppArmor работают в ядре, и напрямую не могут ничего запрашивать у пользователя. Максимум «интерактивности», которую добавили разработчики — это уведомление пользователей об ошибках доступа (apparmor-notify, setroubleshoot).
Ну тогда в рамках существующих технологий статические права разруливаются профилями AppArmor, а динамические права потенциально могут разруливаться PolicyKit. Потенциально — потому что PolicyKit сейчас в основном используется системными сервисами (тем же HAL), а менеджеры файловых системы его используют редко.
В идеале я вижу такой механизм:
1. Запускаю `nano /etc/passwd`. AppArmor дает доступ на чтение. Менеджер файловой системы проверяет права через PolicyKit и дает доступ.
2. Пытаюсь сохранить. AppArmor дает доступ (если есть соответствующее правило). Менеджер файловой системы опрашивает PolicyKit, и в зависимости от результата либо все-таки запрещает, либо запрашивает пароль.
Теоретически, можно обойтись без AppArmor, если менеджер файловой системы поддерживал бы профили безопасности (это ближе к подходу SELinux, который использует filesystem labeling). Тогда вся работа шла бы напрямую через PolicyKit.
Сделано, спасибо за напоминание. Если вы знаете какие-то другие инструменты, дайте знать, если не трудно. Кстати, filemon был когда-то и под Линукс, но потом из-за модификаций ядра он перестал работать.
Не спорю. По моему мнению, лучший кандидат на «реал-тайм + статистика» — SystemTap. Но я не стал про него даже упоминать, т.к. он требует debug-версию ядра.
Конечно, еще есть /proc/sys/vm/block_dump — достаточно хардкорный, но рабочий метод. Также можно упомянуть inotify, но это все-таки другое.
Лично я ничего протива AppArmor не имею, хотя и настораживает, что Novell уволила оригинальных разработчиков. Впрочем, разработка не остановилась, и новые фичи появляются.
Но все-таки AppArmor — это серверный компонент, в нем нет той интерактивности, которую предполагал автор топика по безопасности. Т.е. он не позволяет временно повышать привилегии, причем только на необходимом уровне, а не давать полные права рута. Единственный путь — предварительно создать нужные роли.
Не забудьте дать ему доступ на чтение к папке с фильмами.
Про это то же говорилось. Если вы дали mplayer-у доступ в сеть и доступ к папке с фильмами, то нет гарантии, что он не сольет домашнее порно в инет. Вариант, что домашнее порно не стоит хранить в папке с фильмами, учитывается, но не снимает первоначального вопроса.
Хорошо, тогда у меня пара вопросов (пусть даже это и не относится собственно к топику):
1. Как различать какие файлы можно редактировать, а какие нет? Например, в рамках текущей концепции я наберу «nano /etc/sudoers» и сделаю себя админом. Этого допускать нельзя, соответственно, какое-то дополнительное разграничение прав должно быть. Сейчас это решается на уровне POSIX ACL (ограничение прав пользователей) и PolicyKit (ограничение прав программ).
2. Как быть с системными процессами? Они должны работать в привилегированном режиме, и иметь доступ ко всему? Но тогда в случае их компрометации вся безопасность системы идет в лес. Сейчас это решается на уровне SELinux (доступ только к соответствующим контекстам).
Да, с таким профилем согласен. Одно но — для каждого приложения придется делать собственный профиль безопасности. Такая задача весьма трудоемкая, и здесь уже недалеко до аналога Apple Store — каждое приложение проверяется, плюс добавляется требование предоставить профиль безопасности и проверочные интеграционные тесты. Было бы хорошо — да, реализуемо ли в ближайшем будущем — трудно сказать.
SELinux — серверный компонент, он не умеет ничего запрашивать у пользователя. Но «эмулировать» интерактивность можно — при ошибке доступа прочитать лог, найти нужную ошибку, и на основе нее создать правило доступа. См. audit2allow.
А десктопным компонентом, который будет именно запрашивать пароль при ограниченном доступе, является PolicyKit. К сожалению, файловых систем, интегрированных с PolicyKit, нет, хотя создать можно — это проблема не технологическая, а концептуальная — нет хорошего способа написать правила доступа для программ. В ближайшее время накидаю статью, в которой раскрою эту тему.
А как вы проприетарные драйвере ставите, не используя консоль?
А насчет видеодрайвера — всегда есть Ctrl-Alt-F1, в консоли конфигурируйте драйвер как вам надо (обновить или поставить другой). Возврат обратно в графический режим — Alt-F7.
Но есть другая проблема — лишь после написания статьи я понял, что за бортом осталась сетевая безопасность, шифрование, внутренние механизмы безопасности в ядре, обеспечение целостности данных и другие темы. Если даже просто перечислять средства, то это получится очень большой список, который не потянет на формат статьи. Так что я решил оставить все как есть, а если кто-то проявит заинтересованность в отдельной теме, то можно будет написать новую статью.
Немного не понял. SELinux не отменяет использование стандартных ACL. Если процесс исполняется от имени пользователя, у которого нет доступа, то и у процесса доступа не будет. Можно пояснить вашу мысль?
AppArmor — стандарт де-факто для Ubuntu и SuSE. В альтернативы я никак не могу его поместить, т.к. эта система широко используется.
pivot_root — как я понимаю, это утилита специализирована для Linux. Сорри за мое UNIX-прошлое, я не знаком с ней. Она часто используется? Стоит ли ее упоминать?
NSS — мне кажется, это довольно-таки вспомогательная технология. Сорри за плохую аналогию, но SSH как бы тоже относится к безопасности, но это не повод его упоминать в качестве средства и/или механизма обеспечения безопасности (хотя в каком-то смысле он таковым является).
PAX еще жив? Я слышал про него несколько лет назад, но не знаю текущий статус. Судя по докам в инете все не так хорошо, как хотелось бы. То же самое касается Grsecurity. То, что не входит в мейнстрим, я не рассматривал, это же касается и RSBac. Но упомянуть в качестве дополнительных материалов могу. Если у вас на примете есть еще какие-нибудь интересные аббревиатуры, дайте знать.
Про механизмы ядра думаю нет смысла рассказывать, — конечным пользователям, конечно, будет приятно, что это есть, но для безопасной работы с системой это необязательно.
Не понял, в чем подвох? PAM используется в основном для аутентификации, причем тут авторизация?
К слову сказать, прямые аналоги есть, например File monitoring with Mortadelo and SystemTap. Но SystemTap использует debug-версию ядра, поэтому я его упомянул лишь в постскриптуме.
В идеале я вижу такой механизм:
1. Запускаю `nano /etc/passwd`. AppArmor дает доступ на чтение. Менеджер файловой системы проверяет права через PolicyKit и дает доступ.
2. Пытаюсь сохранить. AppArmor дает доступ (если есть соответствующее правило). Менеджер файловой системы опрашивает PolicyKit, и в зависимости от результата либо все-таки запрещает, либо запрашивает пароль.
Теоретически, можно обойтись без AppArmor, если менеджер файловой системы поддерживал бы профили безопасности (это ближе к подходу SELinux, который использует filesystem labeling). Тогда вся работа шла бы напрямую через PolicyKit.
Конечно, еще есть /proc/sys/vm/block_dump — достаточно хардкорный, но рабочий метод. Также можно упомянуть inotify, но это все-таки другое.
Но все-таки AppArmor — это серверный компонент, в нем нет той интерактивности, которую предполагал автор топика по безопасности. Т.е. он не позволяет временно повышать привилегии, причем только на необходимом уровне, а не давать полные права рута. Единственный путь — предварительно создать нужные роли.
Про это то же говорилось. Если вы дали mplayer-у доступ в сеть и доступ к папке с фильмами, то нет гарантии, что он не сольет домашнее порно в инет. Вариант, что домашнее порно не стоит хранить в папке с фильмами, учитывается, но не снимает первоначального вопроса.
1. Как различать какие файлы можно редактировать, а какие нет? Например, в рамках текущей концепции я наберу «nano /etc/sudoers» и сделаю себя админом. Этого допускать нельзя, соответственно, какое-то дополнительное разграничение прав должно быть. Сейчас это решается на уровне POSIX ACL (ограничение прав пользователей) и PolicyKit (ограничение прав программ).
2. Как быть с системными процессами? Они должны работать в привилегированном режиме, и иметь доступ ко всему? Но тогда в случае их компрометации вся безопасность системы идет в лес. Сейчас это решается на уровне SELinux (доступ только к соответствующим контекстам).
А десктопным компонентом, который будет именно запрашивать пароль при ограниченном доступе, является PolicyKit. К сожалению, файловых систем, интегрированных с PolicyKit, нет, хотя создать можно — это проблема не технологическая, а концептуальная — нет хорошего способа написать правила доступа для программ. В ближайшее время накидаю статью, в которой раскрою эту тему.