Kali Linux теперь можно запускать в контейнере на macOS Sequoia

Kali Linux теперь можно запускать в контейнере на macOS Sequoia

Kali Linux теперь можно запускать в контейнере на macOS Sequoia

Хорошие новости для специалистов по ИБ и исследователей: теперь на macOS Sequoia с чипами Apple Silicon можно запускать Kali Linux прямо в изолированном контейнере, используя новую систему контейнеризации от Apple. Это что-то вроде ответа на Windows Subsystem for Linux (WSL2), только в мире macOS.

Apple представила новую контейнерную платформу на WWDC 2025. С её помощью можно быстро и безопасно запускать Linux-дистрибутивы в виртуализированной среде — без сложных настроек и лишнего софта.

Чтобы начать работу, нужно установить CLI-клиент контейнеров через Homebrew:

brew install --cask container
container system start

А дальше — просто запускаем Kali:

container run --rm -it kalilinux/kali-rolling

Если нужно работать с файлами из локальной папки, пригодится такой вариант:

container run --remove --interactive --tty --volume $(pwd):/mnt --workdir /mnt docker.io/kalilinux/kali-rolling:latest

Но без нюансов не обошлось. Во-первых, всё это работает только на Apple Silicon — на Intel-машинах не поддерживается. Во-вторых, как отмечает команда Kali, сейчас у контейнеров могут быть проблемы с сетью: IP не назначается, интернет недоступен. Kali рекомендует следовать советам Apple, если столкнулись с такими багами.

Эксперт по кибербезопасности Taha Ex также предупреждает: если для ваших задач нужно аппаратное взаимодействие (например, доступ к USB-устройствам), в контейнере это не заработает — он изолирован от железа.

Тем не менее возможность в пару команд поднять Kali на macOS — пусть и с ограничениями — это удобный способ быстро приступить к анализу безопасности без установки отдельных виртуалок или двойной загрузки.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

Основная сессия запустила субагента, который решил очистить собственные временные файлы, но сформировал лишнюю команду рекурсивного удаления.

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

Через 120 секунд задача автоматически перешла в фон. Агент запросил остановку и получил сообщение об успехе, однако, судя по описанным изменениям файловой системы, удаление продолжалось. Вероятное объяснение — дочерний процесс пережил остановку задачи.

Проверка тоже оказалась поверхностной: агент посмотрел на названия папок верхнего уровня, которые могли сохраняться, пока их содержимое исчезало.

Пользователь сообщил о потере проектов за несколько месяцев, инструментов разработки, SSH-ключей и учетных данных. В корзине удаленные файлы не оказались. Обращение помечено как ошибка высокого приоритета с потерей данных.

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

RSS: Новости на портале Anti-Malware.ru