Спустя три года с момента волны уязвимостей (1, 2, 3, 4, 5) в подсистеме AF_PACKET ядра Linux выявлена ещё одна проблема (CVE-2020-14386), позволяющая локальному непривилегированному пользователю выполнить код с правами root или выйти из изолированных контейнеров, при наличии в них root-доступа...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53656
Значит может появиться рут патчинг для андроид?
Хорошо бы, но вряд ли: сначала нужно найти, например, ранее неизвестную дыру в mediaserver, позволяющую выполнять произвольный код (такое бывало конечно, но известные-то уже давно закрыты), а потом ещё запастись большим везением.
Но например, ты можешь написать свой собственный mediaserver!
Как раз пишу на хаскеле для тайлинга такое.
2020 - Уязвимость в реализации сокетов AF_PACKET ядра Linux
...
Проблема присутствует в ядре с июля 2008 годаНо ведь... тысячиглаз.. и вообще, там кодят только труЪ системные программисты, а не какие-то вебмакаки...
А вот было бы оно написано на Rust...
Хорошо хоть не удаленная уязвимость. Было бы весело. Да и локально это далеко не каждому грозит, как я понял.
В основном опять любители доскеров пострадают.
Там s stands for "security", так что только самые глупые.Любители обмазываться неймспейсами, заменять виртуалки контейнеризацией "так дешевле и я так привык", они и вне докера расплодились в неимоверном количестве.
Да я бы не сказал, что контейнеры проще настраивать, чем виртуалки.
У контейнеров назначение другое.
Настроить браузер в контейнере - да, не сразу.
> любители доскеров пострадаютНу да. Профессионалы-то умеют запускать в нём процессы не от рута.
> вызовет переполнение
> неверной последующей установке указателя на буферАхахахахаха
Ну то есть даже если разработчик знает о том, в каком месте постоянно возникают такие ошибки он не в состоянии безопасно работать с указателями. Это говорит многое о языке.
Если бы Rust был так прост и удобен, то все уже давно бы переехало на него,
а так как там наплодили всякого хакерства, то ждем улучшенный вариант Rust.
Если разработчик знает о том, в каком месте постоянно возникают такие ошибки и при этом он не в состоянии безопасно работать с указателями, то это в первую очередь говорит многое о разработчике.
Кривые руки никакой язык не исправит (дыры вполне себе неплохо получаются и без всяких указателей).
Для особо одарённых - уязвимость вызвана ошибкой вычисления переменной netoff, т.е. это алгоритмическая ошибка. Твой, пииии, Rust не способен угадывать правильность алгоритма.
Да, от ошибки в вычислении раст не спасёт. Но будет ли происходить запись в память за пределами выделенного буфера?
Это код ядра, в этом месте потребовалось бы unsafe.
> Это код ядра, в этом месте потребовалось бы unsafe.Анонимный эксперд намба ван.
Свидетель Раста животворящего.
> Свидетель минимального знания обсужддаемого предмета.
Dereference a raw pointer
Call an unsafe function or method
Access or modify a mutable static variable
Implement an unsafe trait
Access fields of unionsIt’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks
поправил. Не благодари, Эксперд.
В ядре все фиксированно и очень мало, особенно стек. Там подсказки раста - как сказать макаке, что валуны есть нельзя.
Предлагаешь разрешить выполняться сборщику мусора на OSI 2 lvl?
> Предлагаешь разрешить выполняться сборщику мусора на OSI 2 lvl?Анонимный эксперд намба ту.
Анонимный растоперейсатель намба трипицотчетыре
> Анонимный растоперейсатель намба трипицотчетыреНаверное, все же лучше быть "растоперейсателем", чем очередным анонимым Экспердом, пишущим чушь.
в расте нет GC
вы наверное с Go перепутали
А как раст проверяет границы буфера? При каждой записи дополнительные проверки делает?
У любителей сижки все ошибки алгоритмические, особенно записи за пределы буфера.
smugface.jpg
Ну ведь так и есть. Чтобы не допускать buffer overflow, нужно добавить проверки.
Ни в одном стандарте (языка, кодирования, проектирования и т. п.) не видел фразы "реализовывать проверки строго запрещается".
Всегда в коллективе есть хоть один, не делающий проверок и искреннее обиженный, когда заставляют.
>АхахахахахаЧто тебя так развесилило?
> Для создания сокета AF_PACKET и эксплуатации уязвимости требуется наличие полномочий CAP_NET_RAW.Ну то есть "почти рут" - процесс, которому разрешили делать все что угодно с сетью, может стать "совсем рутом" - процессом, могущим творить что угодно с машиной.
С одной стороны - не сильно страшно - таких процессов с гулькин нос и атакующему еще их нужно начать контролировать, с другой - хорошо, что нашли. С третьей - интересно будет посмотреть сколько времени уйдет у производителей всяческих сетевых железок на то, чтобы это подтянуть.
>> Для создания сокета AF_PACKET и эксплуатации уязвимости требуется наличие полномочий CAP_NET_RAW.
> Ну то есть "почти рут" - процесс, которому разрешили делать все что
> угодно с сетью, может стать "совсем рутом" - процессом, могущим творить
> что угодно с машиной.
> С одной стороны - не сильно страшно - таких процессов с гулькин
> нос и атакующему еще их нужно начать контролировать, с другой -
> хорошо, что нашли. С третьей - интересно будет посмотреть сколько времени
> уйдет у производителей всяческих сетевых железок на то, чтобы это подтянуть... с четвертой - 12 лет "искали"
> .. с четвертой - 12 лет "искали"С дивана оно удобно обсуждать, но реально копаться в ядерном C - та еще задача. И хотя есть довольно много народу, который это делает, утверждать что каждая функция ядра прочитана и проверена много раз - по меньшей мере наивно. Открою "тайну" - оно так с любым софтом. Мотивация на "давайте сделаем, чтоб работало и приносило нам бабки прямщас" куда сильнее чем на "давайте сделаем так, чтобы оно никогда не приносило бабки кому не надо".
А разве нету какой-то системы "доверия" коду, типо пометки "прочитали -цать раз, всё перепроверили, этот код ошибок не содержит"?
stable api nonsense же ж.
Сегодня прочитали, завтра бросились переделывать. Послезавтра еще раз.Я вот попробовал применить этот патч к любимому 3.0 - как и следовало ожидать, код вообще ни разу не похож. Проверки, тем не менее, нет.
Патч добавляет АЖ ТРИ СТРОКИ. Одна из них не то что не работает в 3.0, а даже непонятно, чем заменять - управляющие структуры ядра совершенно не те.
Ну ладно, подождем - авось редхат починит в 6.
Не поменялось там нихрена, единственное tp_drops в stats лежит:https://elixir.bootlin.com/linux/v3.0.101/source/net/packet/...
> Не поменялось там нихрена, единственное tp_drops в stats лежит:и он не atomic_t
А теперь вот и скажи - его можно просто ++, или нужно оборачивать в spin-lock?
(подозреваю, впрочем, что и то, и другое для тебя китайская грамота)
Это статистика, она особо ни на что не повлияет. Правильно будет инкрементить ++, взяв sk_receive_queue.lock.>подозреваю, впрочем, что и то, и другое для тебя китайская грамота
Лолнет.
> Это статистика, она особо ни на что не повлияет.там кое-где в других местах по похожей статистике if'ы случаютцо ;-)
> Правильно будет инкрементить ++, взяв sk_receive_queue.lock.
вот и я так подумал - ну это ж прям очевидно, стоит только посмотреть в текст патча, где ничего и близко похожего нет, ага? ;-)
> Лолнет.
ЛОВИТЕ НОРКОМАНА! Он правда знает много лишнего, типичному посетителю опеннета совершенно неположенного!
Капы как раз нужны, чтобы не было возможности делать что угодно.
Это правда. Но стоит последить за связанными с capabilities уязвимостями, как становится понятно - когда ядро начиналось, этого не было. И в голове у многих разработчиков застряла эта идея - рут-не-рут, третьего не дано. В итоге ошибки дизайна вылезают как уязвимости вида "почти рут может стать рутом".
> Ну то есть "почти рут"проблема, что у вас последние годы стало очень много этих "почти рутов", причем сбрасывать привиллегии сразу после того как ими воспользовались стало немодно, немолодежно, да и зачем - за вас все сделает сцыстемде, надо только грамотно прописать полсотни загогулин в нечеловекочитаемый "сервис", незачем учиться программированию в устаревшем юникс.
> С одной стороны - не сильно страшно - таких процессов с гулькин нос
да, твой /bin/ls в полной безопастносте.
К сожалению для модных девляпсов, любителей докера в докере в докере, их любимая мантра "обмажем все контейнерами, нейспейсами и запустим рутовое приложение от непривиллегированного юзера" в очередной раз лажанулась.
> С третьей - интересно будет посмотреть сколько времени уйдет у производителей всяческих сетевых
> железоку производителей большинства сетевых железок рут все еще остается рутом, и им эта увизгвимость совершенно пофигу.
Вот любители всяких дерьмонасов, которые помимо хранения файлов имеют еще миллионы свистоперделок, или виртуализации замененной шибка-дешевой контейнеризацией - могут пострадать.
Вы уж определитесь, кто у вас дурак — производители сетевых железок, пользующиеся «устаревшим юниксом» и чётко понимающие, что рут - это рут, и к нему доступ без вмешательства человека с консолью заварен найух, или любители дерьмонасов, которые даже не пытались вникнуть в то, почему существует так много разных "пользователей" и групп почти под каждую задачу.
> это рут, и к нему доступ без вмешательства человека с консолью заварен найухпричем бы тут - сонсоль? Достаточно найти уязвимость даже в "безопасной" "нерутовой" программе, позволяющую даже не произвольный код выполнить, а просто использовать уже созданный ей для чего-то сокет.
Остается надеяться, что на сетевых железках таких немного - просто потому что их там любых немного, а тут надо ж еще и особо постараться.> или любители дерьмонасов, которые даже не пытались вникнуть в то, почему существует так много
> разных "пользователей" и групп почти под каждую задачу.как это то есть не пытались? Пытались, тот же omv в основном тем и отличается от немодного freenas, что там докер ехал через докер. Просто попытка изначально провальная.
И если программе нужен зачем-то af_packet - этому докеру будет выдан нужный capability. Не, ну а чо, изоляция жеж.
Я бы больше боялся за миллионы Android устройств без поддержки, потому что> В Android право создавать сокеты AF_PACKET имеет процесс mediaserver, через который может быть эксплуатирована уязвимость.
Mediaserver довольно известное сито само по себе, а теперь ему ещё и универсальный эксплойт подвезли.
> Я бы больше боялся за миллионы Android устройств без поддержкичего их бояться, им все равно ничего не светит - хоть свинцовой фольгой оберни, хоть еще и в презерватив засунь - все равно поимеют.
Ну и потом - твои данные уже и так читают гугль с клаудфлерей, не отстают китайцы, выпустившие телефон, а тебе для пацанов жалко?
без пакетной передачи (и в режиме ожидания с 0-м балансом) совсем разгульным банкет не будет
Ну вот, вчера как раз за USER_NS говорили (и почему отключаю в "своих" ядрах)...PS: только оно с подчёркиванием, ага.
PPS для альтернативно одарённых(tm): нет, это не серебряная пуля.
Боюсь, Михаил, вы тоже ничего не поняли, как и ваш протеже.
Для выдающихся умов повторяю: в докере user namespaces по умолчанию отключены, и 95% пользователей докера вообще не знают, что это такое и как их включить.
Именно поэтому основной вектор атаки - эксплуатация уязвимостей в программах, которым выдана привилегия cap_net_raw. И отключения в ядре USER_NS никак от этого не поможет.
> в докере user namespaces по умолчанию отключеныа в web-браузерах?
> Для выдающихся умов повторяю: в докереСпасибо, о великий гуру, но докером мир не ограничивается.
https://docs.docker.com/engine/security/rootless/ - перепроверь официальное руководство.По статистике Mozilla USER_NS включен у 85% пользователей.
> Для выдающихся умов повторяю: в докере user namespaces по умолчанию отключенываш выдающийся ум так и не понял, что в данном случае не уязвимость при их использовании, а уязвимость, от которой и они (в очередной раз) бесполезны, недорут становится настоящим рутом.
> 95% пользователей докера вообще не знают, что это такое и как их включить.
95% пользователей докера просто копируют из кем-то наспех написанной инструкции - "этой нужной и полезной хрени нужен параметр --cap-add=SYS_ВАЩЕВСЕ " Я тоже так делаю - раз написано, значит, все равно без него не работает.
За остальных, продвинутых, 5% это сделал готовый конфижек для composer. Они его даже не открывали.
Это проблема вообще многих советов онлайн. Часто советуют вполне себе опасные вещи (или полную чепуху) с лицом, полным уверенности.
я давеча наблюдал на одном форуме, как люди, называющие себя системными администраторами, на серьёзных щщах обсуждают полнодисковое шифрование LUKS на виртуальных машинах.
- мне хсотер выдал VNC доступ к виртуалке, через который я установил ось с нуля и зашифровал диск, теперь мои данные safe?
- да, теперь твои данные safe, ведь никто не сможет расшифровать диск без твоей passphrase.
Ну на 95% случаев тупого изъятия сервера товарищем майором это сгодится.
Ставим ssh сервер в initramfs, настраиваем протокол Diffie–Hellman'а для ssh handshake, при перезагрузке сервера коннектимся по ssh и вводим пароль (автоматизированно конечно, мы ведь любим devops, да?). Товарищи майоры если они даже пишут весь трафик, ничего не могут поделать, потому что надо было изначально ломать трафик активным человеком посередине. Ну и тут надо сваливать с хостинга сразу как тов. майоры первый раз остановили сервер.
если у товарища майора айсикью чуть выше, чем у хлебушка, то он попросит хсотера сделать дамп оперативной памяти этой виртуалки, прежде чем изымать сервер целиком.
но, к счастью, в 95% случаев это будет именно тупое изъятие.
Отключение неймспейсов очень ограничивает применимость и защищённость такого ядра и программ под его управлением. В том числе браузеров, суидная песочница не многим лучше. Не обязательно же от рута сидеть в нём. Ещё бы можно было менять пользователя в неймспейсе (т.е. выполнил настройку от рута и сбросил привилегии, после чего уже запретил изменение), но так к сожалению нельзя, во всяком случае у меня не получилось.
getcap -r /bin /sbin /lib* /usr
/bin/arping cap_net_raw=ep
/bin/ping cap_net_raw=ep
/sbin/unix_chkpwd cap_dac_override=ep
/usr/sbin/mtr-packet cap_net_raw=ep
/usr/sbin/criu =
/usr/bin/dumpcap cap_dac_read_search,cap_net_admin,cap_net_raw=ep
/usr/libexec/qemu-bridge-helper cap_net_admin=ep
/usr/lib64/libexec/kf5/start_kdeinit cap_sys_resource=epВот кстати да, что это за странные права у criu? Там вроде CAP_CHECKPOINT_RESTORE должно стоять. Кеды меня нервируют, суидный бинарник хотя бы можно удалить?
find / -mount -perm -4000 | grep kf5
/usr/lib64/libexec/kf5/fileshareset
sh-4.4# getcap -v /usr/lib64/libexec/kf5/start_kdeinit
/usr/lib64/libexec/kf5/start_kdeinit
sh-4.4# ls -lh /usr/lib64/libexec/kf5/fileshareset
-rwxr-xr-x 1 root root 11K Feb 3 2019 /usr/lib64/libexec/kf5/filesharesetкак же хорошо, что опенсусе не предустанавливают на ноутбуки! меньше пользователей — меньше дыр.
Ну вообще, именно это конфигурируется, а по последниму у тебя версия двухлетней давности и с тех времён изменений очень много было.
* Searching for USE flag caps ...
[IP-] [ ] app-crypt/pinentry-1.1.0-r3:0
[IP-] [ ] app-emulation/qemu-5.1.0:0
[IP-] [ ] app-misc/pax-utils-1.2.6:0
[IP-] [ ] app-shells/zsh-5.8:0
[IP-] [ ] kde-frameworks/kinit-5.73.0:5/5.73
[IP-] [ ] kde-plasma/kwin-5.19.5:5
[IP-] [ ] media-libs/gstreamer-1.16.2:1.0
[IP-] [ ] net-misc/chrony-4.0_pre3:0
[IP-] [ ] net-misc/iputils-20200821:0
[IP-] [ ] sys-apps/coreutils-8.32-r1:0
[IP-] [ ] sys-apps/iproute2-5.8.0:0
[IP-] [ ] sys-apps/smartmontools-7.1:0
[IP-] [ ] sys-apps/util-linux-2.36:0
[IP-] [ ] sys-auth/pambase-20200817:0
[IP-] [ ] sys-libs/glibc-2.32-r1:2.2
//последнему*там правда у половины это называется filecaps, вот их можно отключить наверно, мне они вообще не нужны. Ну wireshark наверно они понадобятся, чтобы не от рута работать, а остальные я не знаю, видимо тоже изоляция, чтобы не от рута запускать.
* Searching for USE flag filecaps ...
[IP-] [ ] app-emulation/qemu-5.1.0:0
[IP-] [ ] net-analyzer/mtr-0.93-r1:0
[IP-] [ ] net-analyzer/wireshark-3.2.6:0/3.2.6
[IP-] [ ] net-misc/iputils-20200821:0
[IP-] [ ] sys-libs/pam-1.4.0_p20200829:0
> Проблема присутствует в ядре с июля 2008 года, т.е. проявляется во всех актуальных ядрах.Отправил модераторам исправление на вот такое:
Ошибка вычисления (баг) присутствует в ядре с июля 2008 года, т.е. во всех актуальных ядрах, однако известная сейчас возможность применить ее для записи в область за границей выделенного буфера (уязвимость) предположительно была привнесена в феврале 2016 (ядра 4.6-rc1 и новее), с развитием поддержки virtio_net.
Чуть подробнее об этом написал в oss-security.
Вот накуя андрюшиному медиасерверу доступ к RAW-сокетам?
Дудосить пацанской музыкой наушники в метро?
Так для RTP нужен UDP.
А зачем для udp raw сокеты?
Что это за медиасервер, который использует немодные и устаревшие протоколы, может еще скажете - tcp?Современный медиасервер ОБЯЗАН изобрести ни с чем несовместимый собственный tcp, желательно уязвимый к relay-attacks, а в идеале еще к точечным dos.
Разумеется, при его реализации без raw sockets никак не обойтись!
Забавно: попытался я найти ответ на этот вопрос, а вместо этого нашлись новости за 2016 и 2017 г. почти слово-в-слово совпадающие с этой.Вообще, похоже что для всякого изврата типа AVTP.
Протоколы в локальной сети для обмена аудио
Для этого UDP достаточно. Ну может UDPLite, тоже отдельный тип сокета, доступный всем пользователям.
Для проприетарных протоколов андроида?
Linux — это безопасно.(с)
Точнее, открытый код безопаснее закрытого. В открытом-то вероятность обнаружить каку значительно больше. Когда находят, то это становится публично доступным, исправление наступает быстро.
Что делают все эти свидетели раста в топиках про сишный, богомерзкий линукс ?
Хотят предложить спасение.
Они уже своего Пророка выбрали?
Верно, без пророка в IT никуда. Ведь всем известно, что большинство айтишников — это инфантильные имбецилы, напрочь оторванные от реальности. Поможем нашим маленьким друзьям найти своего Джобса/Торвальдса?
Вашим маленьким друзьям-растаманам.
И это все вместо того чтобы хотяб 1 драйвер на расте написать?
С одной стороны "опять"?, А с другой, с CAP_NET_RAW ты уже рут или лицо исполняющее его обязанности, что вы так прицепились к этим неймспейсам (без которых всё равно жизни нет).Можно ли таким образом распространять бинарники с нужными правами в каком-нибудь флатпаке? Если да, то так можно замаскировать рутовые бэкдорчики.
>переполнение
>неверной последующей установке указателя на буфернет-нет! не надо переписывать на rust/Go/D! всё и так прекрасно!
Есть такое чуйство, что на чём бы не переписали, а в этом месте понадобится @unsafe.
в любой программе, надобность в unsafe можно свести к минимуму: к нескольким функциям, которые можно пометить "для особого ревью всей командой".. - значительно безопаснее, чем всё писать на опасном языке.
этот "минимум" может оказаться весьма обширен.
функции, хоть обсмотрись всей командой, работают не в чистом поле сами по себе - один фиг надо смотреть и всё вокруг и не менее пристально (что слегка портит радужную картину "посмотреть в одном месте, а остальное за нас язык сделает").
Если команда из таких людей, которым нельзя доверить "опасный" язык, то они точно в состоянии справиться с ревью?
Писать ядро на языке с принудительным гц отличная идея, далеко пойдёшь.
во всех перечисленных языках гц можно отключать или (в Go) выбирать стратегию разработки, которая не требует гц. - да, сложнее,.. но возможно.
Очень теоретически (в д, поскольку библиотека на него завязана емнип), или через содомию, которая всё равно неэффективна (го). На го уже написали "ядро" таким образом. Теоретическая возможность не гарантирует практической применимости.
Справедливости ради, в D использовать libgphobоs не обязательно. Только тогда придётся все необходимые функции самому. Но это и соотвествует ситуации писания ядер. Там, ведь, не используют стандартные библиотеки функций.
А что там останется от ди без библиотеки? Заново его изобретать только уже со своим нескучным рантаймом?
Очевидно компилятор.
Разве это не в старом д компилятор? В новом -- рантайм. /
Разве это не в старом д компилятор? В новом -- рантайм.
где писатели драйверов на расте? кто железом будет рулить?
собака лает, а караван идёт.
та идёт-идёт! Ритчи, в своё время, осознал ошибку и пошёл Limbo пилить с Plan9..
Y FreeBSD тоже шло, а что в итоге?
В итоге осталься только linux : https://www.top500.org/
миллионы не ошибаются - ога
FreeBSD так-то является самой популярной в мире игровой платформой, правда в обёртке от Sony и Nintendo. Но тут и линуксу похвастать нечем, ведь для обычного человека он пригоден к использованию только в виде Android.Выходит, что оба этих продукта до человека доходят только в огороженном формате под присмотром корпораций.
Смотрим исходники Plan 9 http://9p.io/sources/plan9/sys/src/ и... О ужас, да они же на богомерзком C!
> та идёт-идёт! Ритчи, в своё время, осознал ошибку и пошёл Limbo пилить
> с Plan9..И результат?
Вот то и оно. Пока пилил для себя и своих собственных интересов, или хотя бы чтоб с работы не выкинули (не в смысле указивки начальства дотошно исполнял, как сейчас принято у шва6одных разработчиков, а наоборот - сам придумал как из своей игрушки сделать нечто, приносящее практическую пользу соседнему, зарабатывающему, подразделению) - получался юникс.
А как вздумал показать всему миру "как надо" - практической пользы только странный малоиспользуемый драйвер наложенной файловой системы вышел, как будто предыдущих ста штук было мало.
>где писатели драйверов на расте?Тут: https://www.redox-os.org/
Мне один сисадмин-икзперт рассказывал на собеседовании, что контейнеры/виртуализация самая защищенная вещь и что не надо в случае обнаружении вирусни на сервере с хостингом переустанавливать ОС. Ну, что чудило, понял в чем ты ошибался или до сих пор строишь из себя икзперта по ИБ?
А разве это не близко к истине?
Использование контейнеров вкупе с остальным стеком DevOps радикально ускоряющим релиз и развертывание, позволит выкатить исправление в течении минимального времени и позволит не сломать им прод (что как правило гораздо хуже гипотетических уязвимостей)
devops pipeline это отличный организационный объект, которому требуется системная защита, виртуализация это только у Rутковской и фриков про безопасность, а у системщиков свои принципы (минимум кодовой базы и т.д.). возможно пост выше про это.
>А разве это не близко к истине?Какой истине? Истина в том, что если у тебя есть рут на dom0, то ничего не спасет. Затрахаешься лечить такую систему, если, конечно, ты не Рутковская и знаешь про все возможные дыры, в том числе и не опубликованные.
>DevOps
Читать нужно внимательней. Написал же, что сервер для хостинга. Публичного хостинга. И если кто-то извне с рутом в domU использует уязвимость в сабже, получает контроль на dom0, то см. выше что будет.
Мне просто интересно как этот чудень оправдывался бы перед директором со словами "ну, я думал, что это нецеленаправленная атака", поэтому в domU я систему "почистил", ну а в dom0 все вроде нормально (угу, логи-хуеги все как надо почистили и естественно ничего не обнаружил).
В случае, если вирусня не вылезла в dom0, действительно не надо. Но у такого эксперта вряд ли хватит квалификации понять, вылезла ли.
Давай порядок действий как опеределить влезли в dom0 или нет. Просто опиши шаги, которые нужно выполнить как минимум.