Секретный нетбук
Собрался купить себе нетбук, хотел бы получить совет.
Цель использования – оперативная перевозка/переноска текущих данных для работы + секретный выход в интернет из внешних мест (когда надо).
Ессно, нужен видимо встроенный модуль wifi (вместе с тем, обязательно допускающий кофигурацию mac-адреса с помощью ifconfig), видимо, понадобится модуль WiMAX, но не встроенный (чтобы не палиться через него).
Соответственно, чтобы он (и все его устройства) нормально взаимодействовали с Linux (в частности, Debian).
Достаточная ОЗУ (желательно 2 – 4 ГБ), диск не менее 100 – 120 ГБ.
Ну и без "суперпродвинутых" аппаратных средств деанонимизации и шпионажа за его пользователем.
Что посоветуете?!
Ссылки
[link1] http://www.enricozini.org/2008/tips/resize-luks/
asus eee 901 с intel atom + внешний usb-диск?
м.б.
Только хотелось не внешний диск
А чтоб считал быстрее кластера не хотите? Есть субноуты типа тошибы портеж, на них ставится Linux если что, но стоимость порядка 100-150k.
Просто для нынешний времен 100 ГБ это почти ничего... Большая флешка.
А 20 ГБ примерно равно 0 (-:
Только если загадить диск HD-фильмами. Для работы (а тема мне подсказывает, что машина нужна не для игрушек) это более, чем достаточно.
Купил вышеуказанный ноут, установил Debian с шифрованным LVM.
Если я захочу менять разделы, что я должен делать? Например, там автоматически установилось /tmp как раздел, я же хочу его монтировать в ОЗУ в виде tmpfs.
Как я понял, там два физ. раздела – /dev/sda1 – где /boot, и /dev/sda2 – где lvm (как и при обычном lvm), только второй физ. раздел (не логические?) зашифрован dm-crypt.
Т.е. я могу менять разделы lvm как при работе с обычным lvm, или я должен учитывать как-то это шифрование?
Шифруется по умолчанию, емнип, DOS'овский раздел, и как потом поверх него будут нарезаны "вторичные разделы" lvm'у пофиг.
Отредактируйте /etc/fstab
Аккуратнее, а то потеряете данные. В /etc/cryptab прописано, что и как зашифровано. Если зашифрован физический том, то все логические тома в нём зашифрованы и не видны "снаружи", их можно двигать внутри него как угодно набором утилит LVM. Если зашифрованы логические тома (кстати можно совместить шифрование логических томов по отдельности внутри физического, если не критично для производительности), то надо учитывать шифрование.
В /etc/cryptab прописано, что зашифрован физический диск /dev/sda2.Значит, я могу спокойно играться с обычными утилитами LVM?
P.S. Какие могут быть проблемы с безопасностью при том, что /dev/sda1 не зашифрован? И вообще, реально ли зашифровать раздел, с которого грузишься? (Будет ли грузиться после этого система?). Или для большей безопасности можно только использовать раздел, на котором размещен /boot, на съемном носителе?
P.P.S. В случае, если зашифровать логические тома, возможно ли изменение размера разделов без потери данных? Или в любом случае надо копировать на внешний носитель, менять размер и копировать обратно?
Подмена ядра, стартового рамдиска на троянские версии, сливающие пароль, но это значит, что у противника уже есть доступ к компьютеру.
Говорят GRUB2 такое поддерживает, но это IMHO бессмыссленно, т.к. можно инфицировать сам загрузчик (GRUB2), так, чтобы он тоже сливал пароль.
Только так, если предполагается, что носитель всегда при себе, а компьютер — нет. Но могут ведь и BIOS, и аппаратную часть протроянить при физическом доступе.
Возможно, особенно в сторону увеличения. Dmcrypt специально для этого был написан с прицелом на тесную интеграцию с LVM. Простой пример[link1]. Народ часто жаловался на траблы с потерей данных, но на своём опыте не сталкивался.
Для таких целей предусмотрительно при инсталляции можно оставить значительную часть винчестера неразмеченной под логические тома внутри физического тома. По мере необходимости можно увеличивать размер существующих логических томов, а на неразмеченном пространстве создавать временные логические тома для перекидывания данных. При манипуляции с логическим томом можно по-ошибке убить только его, но маловероятно, что весь физический том со всеми логическими. Так можно обойтись и без бэкапов на внешний носитель, хотя и они не помешают.
Физические разделы, физические тома, группы томов и логические тома — это четыре разных сущности. В качестве пятой можно добавить ещё райд-массивы.
Нет, это крайне ненадёжно. Если носитель сломается, то полетит всё, что на нём – хрестоматийный пример с фэйлом, который систематически воспроизводится админами. Бэкап – только на сторонний носитель.
Речь только о бэкапе на момент изменения логических томов. А для систематических бэкапов — да, внешний.
А стоит при том, что диски криптованные, монтировать /tmp в ОЗУ? Тем более что она всего – 1 гиг (ну, можно еще модул в 1 гиг установить, правда).
Или лучше сэкономить на ОЗУ, все равно к /tmp враг сможет добраться только взломав криптование диска?
Нет, но это актуально, если /tmp не шифруется или памяти более чем достаточно (может увеличить скорость работы с системой).
Если кому-то необходимо работать с ооочень большими /tmp и swap (в которых оседают гигабайты данных), то можете завести для них логические разделы и прописать в /etc/cryptab что-то вроде (сверьтесь с man по своему дистрибутиву):
Тогда эти тома будут перешифровываться и подниматься каждый раз после перезагрузки на рэндомном ключе и на них будет заново производиться mkfs (это не так медленно как можно подумать).
Теперь в /tmp можно симлинками вынести всё временное (только осторожно, при создании каталогов в /tmp существуют жёсткие правила безопасности по правам, случайным именам, "атомарности" операции создания), что необходимо удалять при выключении (перезагрузке). Гибернация естественно работать не будет.
В UNIX если симлинк ведёт на файл к неподмонтированной файловой системе, ничего страшного не возникает. Симлинк – это, эффективно, файл, содержащий путём к файлу, на который ссылка. Права – как любой FS. Так что что здесь стоит удалять обязательно руками перед ребутом – не ясно. Весь /tmp итак полностью чистится в процессе каждого ребута.
Удалится-то оно само. Каталоги в /tmp нужно "руками", т.е. скриптом создавать.
В /tmp могут записывать все. Если злоумышленнику известно, что там будет создаваться /tmp/somelog, то он может перед этим создать в /tmp симлинк, который перенаправит /tmp/somelog на другой файл и повредит его как минимум. Регулярно публикуются уязвимости на создание предсказуемых имён в /tmp. А "атомарность" операции означает, что нельзя сначала создать файл со случайным именем, а затем поменять его права (или наоборот), как бы быстро это не было сделано. Нужно сделать обе операции одновременно, для чего можно использовать только команду mktemp (если из shell/bash).