Анонсирован (http://scarybeastsecurity.blogspot.com/2012/04/vsftpd-300-an...) релиз надежного, защищенного и высокопроизводительного FTP-сервера vsftpd 3.0.0 (https://security.appspot.com/vsftpd.html). Ключевым улучшением, появившимся в новой версии, является реализация нового sandbox-режима, изолирующего выполнение процесса с использованием seccomp-фильтра.В настоящее время в vsftpd задействован полный спектр средств защиты, доступных в Linux, включая выполнение в chroot, capabilities, контроль файловых дескрипторов, пространства имён, rlimits и даже экспериментальный уровень изоляции на основе ptrace. Seccomp позволяет реализовать новый уровень изоляции на уровне системных вызовов, чем-то напоминая sandbox на базе ptrace, но изначально основанный на технологии для обеспечения безопасности (ptrace является отладочным инструментом), обладающий значительно более высокой производительностью и отличающийся более высокой стабильностью.
Seccomp пока не включён в состав основного ядра Linux, но будет активирован по умолчанию в 64-разрядной сборке Ubuntu 12.04. Принцип работы Seccomp сводится к ограничению доступа к системным вызовам, при том, что логика выставляемых ограничений задаётся на уровне (ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-3.0.0/secc...) защищаемого приложения. Доступ к системным вызовам определяется в виде правил, оформленных в BPF-представлении (Berkley Packet Filter), которое получило распространение в системах фильтрации сетевых пакетов. BPF позволяет реализовывать достаточно сложные правила доступа, учитывающие передаваемые и возвращаемые аргументы. В код программы добавляется структура с перечнем допустимых системных вызовов (например, ALLOW_SYSCALL) и реакции в случае несовпадения (например, KILL_PROCESS).
Программа сама определяет какие системные вызовы её необходимы и какие параметры допустимы, все остальные системные вызовы блокируются, что позволяет ограничить возможности атакующего в случае эксплуатации уязвимости в защищённом при помощи seccomp приложении. Более того, изоляция с использованием seccomp позволяет защититься от большинства атак, эксплуатирующих уязвимости в системных вызовах. Например, выявленные за последние годы критические уязвимости в glibc и ядре Linux, такие как AF_CAN (http://sota.gen.nz/af_can/), sock_sendpage (http://blog.cr0.org/2009/08/linux-null-pointer-dereference-d...) и sys_tee (http://www.juniper.net/security/auto/vulnerabilities/vuln228...), успешно блокируются при использовании функциональности seccomp по проверке аргументов. Кроме vsftpd, патч с поддержкой seccomp уже подготовлен (http://hg.mindrot.org/openssh/rev/f40779d28db5) для OpenSSH и будет включён (https://twitter.com/#!/damienmiller/status/187351912113377280) в состав OpenSSH 6.0.
Кроме обеспечения поддержки seccomp из изменений, добавленных в vsftpd 3.0.0 можно отметить:- По умолчанию сервер запускается в обособленном режиме, самостоятельно обрабатывающем соединения (listen). Ранее по умолчанию подразумевался запуск через inetd;
- Ранее реализованный экспериментальный sandbox на базе ptrace теперь именуется в настройках "ptrace_sandbox" вместо "sandbox". Новый sandbox "seccomp_sandbox" включен по умолчанию для систем, поддерживающих seccomp;
- Добавлены дополнительные проверки состояния в код привилегированного управляющего процесса;
- Для сборки использована подборка опций, обеспечивающих более высокий уровень безопасности (например, включаются различные рандомизаторы памяти и средства защиты от переполнения стека);- Добавлена новая опция "allow_writeable_chroot" для управления возможностью записи в chroot-окружениях, создаваемых для аутентифицированных пользователей;
- В качестве SSL-шифра по умолчанию задействован AES128-SHA;
- Устранение проблем с работой пассивного режима FTP при высокой нагрузке на сервер;
- Решение проблем с таймаутами, в частности, возникающими при использовании SSL.URL: http://scarybeastsecurity.blogspot.com/2012/04/vsftpd-300-an...
Новость: http://www.opennet.ru/opennews/art.shtml?num=33569
> В настоящее время в vsftpd задействован полный спектр средств защиты, доступных в Linux, включая выполнение в chroot, capabilities, контроль файловых дескрипторов, пространства имён, rlimits и даже экспериментальный уровень изоляции на основе ptrace.Прекрасно, молодцы ребята.
А в федоре/сусе/мендриве эти средства защиты можно легко задействовать для любой службы, вне зависимости от их поддержки разработчиками. Но федора/мандрива/суся отнюдь не позиционируют себя как супер-пупер защищенные системы.
Т.е. правила напишуться сами? Или вы настолько хорошо знаете все сервисы, что для каждого можете написать такие правила? Может тогда напишете?
А правила по хорошему должны писать разработчики.
> Seccomp пока не включён в состав основного ядра LinuxА почему? Проблемы со стабильностью?
если включат, потом нельзя ни выключить ни userspace API поменять
смотря как ломают API в ядре - это уж за запросто.
API эволюционируют внутри ядра оставаясь неизменным в syscalls для юзерспейса. Слово "ломают" неверно по отношению к тому, что не предполагалось быть неизменным.
Да ёлки же ты палки. Вместо того, что бы всем миром писать нормальные политики к SELinux, занимаются ерундой какой то
> нормальные политики к SELinux,Не, пусть это такие как ты пишут. И всякие хрены из FBI у которых регламент, так что по регламенту положено так сношаться.
Вы похожу не представляете что за зверь этот SELinux и в чем его . Его хватит на все. Ну а проблема восприятия процесса настройки политика как (не)приятного акта некоторой деятельности - это сугубо ваша личная проблема, не правда ли?
Да с кем ты споришь? С этим хренкиным? Он никогда в жизни в заведении крупнее Рогов и Копыт не работал. А строем тем более не ходил, ибо кривой-косой-хромой или просто откосил.
100500 ФС, 100500 планировщиков, 100500 систем безопасности: SELinux, теперь Seccomp.Зачем все это плодить, а не продумать один раз наперед?
> Зачем все это плодить, а не продумать один раз наперед?Гугль не осилил selinux, пользователи хрома не осилили selinux, никто не осилил selinux. Аноним не осилил подумать наперёд. Ситуэйшн нормал.
SELinux, seccomp, tomoyo, yama, apparmor. действительно, не много ли всего?
Много-не много, не важно. Главное, что _не _достаточно!:D
дистрибутивов тоже как-то недостаточно, вообще очень мало
> дистрибутивов тоже как-то недостаточно, вообще очень малоДа, то-ли дело винды. Там MS железной рукой за всех решил что сегодня бум жрать вот эти вот кактусы и все тут. И фиг оспоришь. Наверное так лучше по вашему мнению, да? :)
>> дистрибутивов тоже как-то недостаточно, вообще очень мало
> Да, то-ли дело винды. Там MS железной рукой за всех решил что
> сегодня бум жрать вот эти вот кактусы и все тут. И
> фиг оспоришь. Наверное так лучше по вашему мнению, да? :)Прикинь - это много лучше чем 1024 дистра, отличающихся друг от друга лишь обоями. И причем среди них нет нужного мне - дистра черниговских венерологов с гениталиями крупным планом на обоях в разрешении 1280x1024!
100500 вариантов фичи хороший признак, говорит о её востребованности, и в то же время о незрелости решений.
Так что запасаемся попкорном или коммитим патчи в апстримы - до полного созревания.
> 100500 вариантов фичи хороший признак, говорит о её востребованности, и в то
> же время о незрелости решений.
> Так что запасаемся попкорном или коммитим патчи в апстримы - до полного
> созревания.Вряд ли ты при жизни это увидишь. Примерно как метро в Зимбабве.
> 100500 ФС, 100500 планировщиков, 100500 систем безопасности: SELinux, теперь Seccomp.
> Зачем все это плодить, а не продумать один раз наперед?Именно так и рассуждает каждый изобретатель нового стопицотпервого велосипеда.
Как его подружить с sqlite? В плане, виртуальных пользователей авторизовывать через БД, хранящуюся в sqlite? Гугель намекает на модуль pam-sqlite, но я такого не обнаружил, только эти туманные намеки...
Ох. А sqlite это так принципиально? Если вам "на месте просто править", можно взять текстовый файл, хэшируемый средствами dbm - такое поддерживается, если в SQL хранить важно - можно в mysql.sqlite, он весьма неэффективен под данную задачу - он рассчитан на то, что из приложения будет идти вся работа, а тут вы хотите извне изменять, а он чтобы подтягивал. Это постоянно переоткрывать файл и т.д., в том же dbm это намного эффективнее будет. Поэтому на тему sqlite никто особо и не заморачивается.
> sqlite, он весьма неэффективен под данную задачуНю-ню, тут даже pam-модуль на питоне, который каждый раз парсит xml на предмет аутентификационных данных, справится.
>> sqlite, он весьма неэффективен под данную задачу
> Ню-ню, тут даже pam-модуль на питоне, который каждый раз парсит xml на
> предмет аутентификационных данных, справится.Тю! А потом семейка велосипедистов изойдет на гогно, говоря, какой питон тормоз горный.
> какой питон тормоз горный.Насколько он горный - хрен знает, но тормозит отменно :P
> Ох. А sqlite это так принципиально? Если вам "на месте просто править",
> можно взять текстовый файл, хэшируемый средствами dbm - такое поддерживается, если
> в SQL хранить важно - можно в mysql.
> sqlite, он весьма неэффективен под данную задачу - он рассчитан на то,
> что из приложения будет идти вся работа, а тут вы хотите
> извне изменять, а он чтобы подтягивал. Это постоянно переоткрывать файл и
> т.д., в том же dbm это намного эффективнее будет. Поэтому на
> тему sqlite никто особо и не заморачивается.Дятло, а почему бы, чтобы карандаш очинить, не взять сразу мельничный жернов? Оракель, например?
>> Ох. А sqlite это так принципиально? Если вам "на месте просто править",
>> можно взять текстовый файл, хэшируемый средствами dbm - такое поддерживается, если
>> в SQL хранить важно - можно в mysql.
>> sqlite, он весьма неэффективен под данную задачу - он рассчитан на то,
>> что из приложения будет идти вся работа, а тут вы хотите
>> извне изменять, а он чтобы подтягивал. Это постоянно переоткрывать файл и
>> т.д., в том же dbm это намного эффективнее будет. Поэтому на
>> тему sqlite никто особо и не заморачивается.
> Дятло, а почему бы, чтобы карандаш очинить, не взять сразу мельничный жернов?
> Оракель, например?А что плохого в том, чтобы держать пользователей в БД? Например, виртуальных пользователей для почты, ftp и так далее. Есть много причин, по которым sql тут удобнее, чем файлик; но sqlite это совершенно некорректный sql под данную задачу, нужно клиент-серверный.
Конечно, с точки зрения корректности правильнее хранить пользователей в ldap, но предлагать городить ldap на пустом месте это как раз будет мельничным жерновом, пожалуй. А вот перейти на более правильный sql - по-моему нормальное предложение.
> Ох. А sqlite это так принципиально? Если вам "на месте просто править",
> можно взять текстовый файл, хэшируемый средствами dbm - такое поддерживается, если
> в SQL хранить важно - можно в mysql.
> sqlite, он весьма неэффективен под данную задачу - он рассчитан на то,
> что из приложения будет идти вся работа, а тут вы хотите
> извне изменять, а он чтобы подтягивал. Это постоянно переоткрывать файл и
> т.д., в том же dbm это намного эффективнее будет. Поэтому на
> тему sqlite никто особо и не заморачивается.У меня просто уже есть БД пользователей в sqlite, и хочется держать это централизованно. Может, какой-то другой ftpd это умеет? Я не нашел.
Проблема тут в том, что sqlite по дизайну "под одно приложение", на другое применение он не рассчитан - поэтому и работает плохо. Если вам нужно хранить пользователей в sql, то просто нужно сделать маленький шаг и хранить в клиент-серверном mysql, а не "файлике" sqlite, и такой проблемы возникать не будет.
tactical facepalm, when simple facepalm is just not enough.
Осталось Capsicum добавить и можно юзать на последней фре :-)
> полный спектр средств защиты, доступных в Linux, включая выполнение в chroot,
> capabilities, контроль файловых дескрипторов, пространства имён, rlimits и даже
> экспериментальный уровень изоляции на основе ptrace.А LXC где? Чрут галимый - есть, а куда как более дуракозащищенный LXC - оно где?
Какую поддержку на уровне приложения вы ожидаете? :-)>> полный спектр средств защиты, доступных в Linux, включая выполнение в chroot,
>> capabilities, контроль файловых дескрипторов, пространства имён, rlimits и даже
>> экспериментальный уровень изоляции на основе ptrace.
> А LXC где? Чрут галимый - есть, а куда как более дуракозащищенный
> LXC - оно где?
напиши. Это же опенсорс
> По умолчанию сервер запускается в обособленном режиме, самостоятельно обрабатывающем соединения (listen). Ранее по умолчанию подразумевался запуск через inetd;Порадовало.
Я так понимаю, все современные дистрибутивы ещё при инсталляции переделывают конфиг на использование listen.
А то уже лет 5 vsftpd+inetd не то что, на серверах не видел, а даже статей про такую настройку не встречал.> Добавлена новая опция "allow_writeable_chroot" для управления возможностью записи в chroot-окружениях, создаваемых для аутентифицированных пользователей;
А вот это удобная фича.