Пользователь
0,0
рейтинг
19 сентября 2010 в 15:51

Разработка → GRUB: Получаем полный доступ к системе

GRUB, безусловно, является самым продвинутым загрузчиком на сегодняшний день, и за это любим админами и разработчиками по всему миру. Его функционал настолько широк, что он практически монополизировал рынок загрузчиков в мире *NIX, а некоторые вообще говорили, что GRUB2 — это скорее маленькая операционная система, чем просто загрузчик. Эдакий швейцарский нож в мире загрузчиков.

Но в этот раз я хочу обратить внимание на то, что с помощью швейцарского ножа можно не только открывать консервы, но и вырезать неприличные слова на парте.

Сценарий 1: загружаемся со внешнего носителя


Ситуация, когда в BIOS заблокирована загрузка со внешних носителей, — отнюдь не редкость. Делается ли это из соображений безопасности или иных причин не так уж и важно. Важно то, что GRUB может помощь нам преодолеть этот барьер. Ниже описана последовательность действий, которая позволит нам загрузиться с флешки.
  1. Изготавливаем загрузочную флешку любым способом, например, с помощью unetbootin.
  2. Вставляем флешку и включаем компьютер.
  3. Дожидаемся появления экрана grub (иногда для того, чтобы успеть его поймать, надо держать Shift).
  4. Перед нами появляется список вариантов загрузки.
  5. Нажимаем c и входим в интерактивный режим.
  6. Теперь требуется указать носитель, с которого будем грузиться. Обычно (hd0) — это родной жесткий диск компьютера, а флешка становится (hd1). Выяснить, как назовется флешка в вашем случае, нетрудно просто опытным путем.
    Так или иначе, вводим: root (hd1) для GRUB Legacy или set root=(hd1) для GRUB2
  7. Просим передать управление загрузчику на указанном диске: chainloader +1
  8. Загружаемся! boot
Если вы все сделали правильно, то в результате вы успешно загрузитесь со своей флешки, несмотря на запрет в биосе. Опытным путем мне удалось выяснить, что метод не работает если ваша материнка не умеет грузиться с usb или не опрашивает устройства при каждой загрузке (как, например, на моем eee PC при включенном Boot Booster).
Лирическое отступление: этот метод мне удалось опробовать в одном из терминальных классов нашего университета, где на компах стояли в дуалбуте винда с линуксом. Прелесть того случая в том, что факультетский сервер экспортировал /home по NFS и та терминалка была занесена в разрешенные подсети. В результате, мне удалось прочитать домашние каталоги пользователей того сервера и уйти так никем и незамеченным.

Сценарий 2: получаем консоль root'a


Опять-таки, ситуация, когда пароль рута не сообщают конечным пользователям компьютера, ни у кого удивления не вызывает. Однако все тот же GRUB поможет нам это досадное ограничение обойти. В отличие от предыдущего способа, удобного для доступа в духе «незаметно пришел, скопировал и ушел, не наследив», этот способ удобнее для внесения нужных нам изменений в установленную систему. Кроме того, для этого нам уже не нужны никакие флешки.
  1. Аналогично, добираемся до списка вариантов загрузки.
  2. Выбираем нужный нам вариант.
  3. Входим в режим редактирования. Здесь есть небольшие отличия между GRUB Legacy и GRUB2. В GRUB2 после нажатия клавиши e мы сразу попадаем в режим редактирования, а в GRUB Legacy нужно нажать e первый раз, выбрать строку для редактирования и еще раз нажать e.
  4. Выбираем строку, которая начинается со слова linux или kernel.
  5. Удаляем из нее слова quiet и splash, если они есть, и дописываем в конец single init=/bin/bash
  6. Если у нас GRUB2, то сразу жмем Ctrl+X, а если GRUB Legacy — Esc и потом b
В результате мы загрузимся в рутовую консоль безо всяких паролей и ненужных вопросов.

Защита?


И GRUB2, и GRUB Legacy предоставляют возможность ограничить доступ к интерактивному режиму и редактированию с помощью директивы password. Подробности описаны в руководстве по GRUB2 и GRUB Legacy. В обоих случаях манипуляции весьма просты и не требуют много времени.

Баян!


В общем, да, ничего нового я не сказал — все это можно нагуглить, например так. Однако, проблема от этого меньше не становится, наоборот. Более того, если с января в школа действительно поставят linux, то желающих считерить или просто «похакать терминалку» станет на порядок-другой больше. И не стоит недооценивать школьников — найдутся и те, кто умеют гуглить. Если же принять во внимание лирическое отступление, которое я сделал в первой части, то тут еще и поле для утечки данных. Думаю, каждый сможет придумать еще пару способов применения.
Александр @Volmontovich
карма
70,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (80)

  • +2
    Спасибо, вечером обязательно попробую!
  • +3
    многие (да почти все) загрузчики позволяют войти в SINGLE USER mode. На той же мак оси снос рутового пароля занимает минуты 2.
    • 0
      загрузчик FreeBSD позволяет просто из меню загрузиться в сингле.
      вообще, проблема актуальна «для школьнегов» :) т.е. для профита нужен прямой доступ к компьютеру/серверу. в случае же с веб-серверами — это не актуально.
      защита проста, достаточно отключить загрузку с флешек и сети и запаролить БИОС. ну и GRUB тоже. дабы не соблазнять школьнегов ;)
  • +2
    Еще один вывод — шифруйте домашние каталоги. Благо дело сейчас эту опцию использовать просто.
    • +6
      По моему вывод должен быть — устанавливайте пароль на редактирование grub где это нужно. Как, написано допустим тут itshaman.ru/articles/14/password-grub и много где еще.
      • 0
        Потому и было сказано «ещё один». Потому как важность защиты груба паролем — вывод из данной статьи первый и очевидный. :)
    • НЛО прилетело и опубликовало эту надпись здесь
      • +13
        orly?
        • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Вот-вот. Последний раз когда проделывал такую историю с grub на шифрованный раздел. А сейчас многие дистрибутивы шифруют его по умолчанию. Хотя с шифрованием тоже надо быть осторожным.
      Но все равно автору спасибо на статью.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      О том-то и речь: возможность совершенно не секретная, но о ней никто не задумывается. В то же время, чем это может грозить — тоже несложно догадаться.
      • +5
        Почему «никто»? Я традиционно стою на позиции «доступ к консоли==физический доступ». В этом случае любые телодвижения глупы. (ровно так же, любой мудак, дорвавшийся до консоли сервера может сделать Alt-SysRq-K(H) и положить все сервисы).

        Если же мы начинаем изобретать полумеры в виде «доступ к консоли но не рут», то тут остаётся шаманить. Но правильное решение — обеспечение недоверенной сети для загрузки с установлением доверенных соединений по её окончании. Любые запаивания системников всё равно обходятся.
  • 0
    В школе очень удобно использовать удалённую загрузку для проведения тестов. Даже если ученик получит рутовый шелл на своей машине, то это абсолютно ничего ему не даст.
    • +1
      Зато он может попытаться скомпрометировать учетку преподавателя. Естественно, при правильных настройках оси и системы тестирования, это ему не даст, но когда вы последний раз видели грамотно настроенную сеть в школе?
      • 0
        Зачем в образе системы, предназначенном для удалённой загрузки, учётная запись преподавателя?
        • 0
          Если есть единый сервер авторизации (виндовый домен, к примеру), то на нем будет и учетка преподавателя. Если на компьютере преподавателя в локальную копию профиля в авторан накидать троянцев, то компрометация будет осуществлена. Вообще, все сильно зависит от конкретных настроек, так что гадать — дело неблагодарное.
          • 0
            Авторан, виндовый домен…
            Тут как бы про Linux в школе и удаленный бут говорят.
            • 0
              Я знаю, что пример не вполне корректный для школы. Но это реальная ситуация в наших универских терминалках.
          • 0
            Если бы я такую конструкцию (в виндах) делал, то разумеется, профили бы персонала лежали на DFS-шаре, а не локально.
  • –6
    Казалось бы — каким образом этот топик относится к информационной безопасности? Так же, как и ростоянный совет «делайте пароли сложными»?
    • 0
      Смотрите лирическое отступление.
  • 0
    насколько я помню, init=/bin/bash давал не полный доступ, а рид-онли. во всяком случае, изменения не сохранялись
    • +1
      незабываем примаунтить корень на чтение/запись :)
      /sbin/mount -wu /
  • +9
    Да в общем совершенный баян конечно. GRUB ничего особенного не умеет такого, просто надо ставить на него пароль, если вы не хотите, чтобы в ваш компьютер через него могли влезть. Single mode — это вообще особенность Linux, а не GRUB, кстати.
  • 0
    А если на GRUB поставить пароль?
    • 0
      Собственно, именно это и надо делать. Именно об этом и топик.
  • 0
    Штатные средства:
    1) Загрузиться с отдельного носителя, смонтировать систему и сделать в нее chroot.
    2) Штатному загрузчику передать параметр.

    О чем переживаем?
    Запретить загрузчику принимать параметры (GRUB это умеет).

    А вообще:
    «Как много нам открытий чудных...»
    Но не нужно о каждом писать пост на Хабре ;)
    • 0
      Начнем с того, что не все загрузчики позволяют грузиться со внешних носителей, в обход ограничений BIOS. Пример — isolinux и его брат syslinux. А GRUB позволяет.
      Во-вторых, я и говорю о том, что если загрузчик позволяет редактировать параметры загрузки, то эту возможность надо защищать.
      В-третьих, прежде чем написать эту статью, я пол года наблюдал эту проблему в самых разных организациях. Из виденного мною за эти пол года ни один админ так и не поставил пароль на GRUB.
      • +5
        Пол-года, срок, несомненно, огромадный…
        Но это:
        1) Не секрет. (Просто нужно читать документацию)
        2) Не баг. (Потому как штатная ситуация)
        3) Не закладка злобных программистов.

        Это нормальный, штатный режим работы.

        Можно было просто написать: «Граждане, мойте руки перед едой»…
      • 0
        Например в линуксовом mbr есть режим загрузки со всего, что он определил

        4. The boot process
        ~~~~~~~~~~~~~~~~~~~

        When the MBR is first loaded it waits for a configurable length of
        time (1 second by default), monitoring the keyboard, for key presses.
        If the MBR detects a key press, it will interrupt the boot process,
        and display it's prompt. Otherwise, it will load the first sector of
        the default partition, and execute it. If a disk error occours, the
        MBR will display it's prompt.

        4.1 The boot prompt
        ~~~~~~~~~~~~~~~~~~~

        The boot prompt looks something like this:

        14FA:

        This is the list of valid keys which may be pressed. This means that
        partitions 1, and 4 can be booted, also the first floppy drive
        (F). The 'A' means that 'advanced' mode may be entered, in which any
        partition may be booted. The prompt for this mode looks like this:

        1234F:

        поддерживаю предыдущего оратора :)
  • +5
    Тема security при наличии физического доступа к машине слегка надуманная. Потому что нет никакой security. Поэтому в GRUB и есть этот ключик про доступ root-ом: нет смысла защищаться.
    • +2
      Вопрос лишь в том, насколько плотный физический контакт нужен для получения доступа к данным. Одно дело — быстро загрузиться с флешки, и совсем другое — разворотить системник, которые, кстати, нередко опечатывают.
    • 0
      Шифруем ФС, паролируем всё открытое.
      Не 100% защиты, но пару лет(а то и десяток) при больших объемах на раскодировку потратят.
      За это время инфа уже станет не актуальной как минимум.
      Так что смысл есть и он обоснован.
      • 0
        Угум. Только шифрование винта никакого отношения к запуску системы из-под рута или не из-под рута не имеет.
        • +1
          > Тема security при наличии физического доступа к машине слегка надуманная. Потому что нет никакой security. Поэтому в GRUB и есть этот ключик про доступ root-ом: нет смысла защищаться.

          По предложениям:
          Тема security при наличии физического доступа не надуманная, можно защитится и при таком доступе.
          Она есть, какая я уже написал.
          Смысл защищатся есть, root доступ далеко не панацея.

          Угум.
          • –2
            Не скучно спорить без контекста? :)
            • +1
              Может вам и скучно.
              Но я не спорил.
              Я констатировал некорректность ваших утверждений, обосновав каждое свое слово.
  • +1
    Вижу в этом топике много людей, рассуждающих о том, что этот пост баянист и вообще описан в man. Но у меня есть вопрос к тем людям, у которых на вход в линукс (а точнее в графическую среду) стоит пароль: а Вы выполнили меры предосторожности против такой ситуации?
    Особенно феерично ответ «нет» будет смотреться на фоне того, что на вход пароль должен стоять у всех, ибо иначе это не linux-way.
    • 0
      При наличии физического доступа к машине, никакой безопасности быть не может. Разве что зашифровать ключевые данные, хотя это не спасёт от их порчи.
      • 0
        А я всегда считал, что при запрете внешних носителей, пароле на bios и на вход в ОС, безопасность практически 100%, можно разве что утащить винчестер, но это могут случайно обнаружить.
        Физический доступ — он может быть и ограниченным клавой, мышей и монитором.
        • +1
          Пароль на биос и запрет внешних носителей снимается перетыканием перемычки на материнке. Нужно как минимум опечатывать корпус.
          • +3
            Я лично как-то (когда делал такие корпуса на склад и обнаружил, что слажал с конструкцией) цеплял CDюк засунув руку в дырку от вынутых 5.25" устройств (расклёпывать лениво было). В принципе, можно на спор сделать «сброс настроек биоса проволочкой через вентиляционные отверстия».

            Но нужно ли? Физический доступ = недоверенное устройство на том уровне, на котором есть физический доступ.
        • 0
          И что приходим, со своей клавой, монитором и мышкой и системником. Делаем копию диска и идем домой читать.
          • +1
            Ребят, это конечно же весело, но давайте представим такую ситуацию:
            Вы устроились на работу, специально, чтобы вынести некоторую информацию из некоторой компании. На входе вас проверяют на подозрительную ерунду типа мышек, клав и мониторов. И на выходе так же. Ничего не принести, не вынести. Корпус опечатан, запрет на загрузку с внешних носителей, пароль на биос.
            Но это ерунда — у вас то есть физический доступ. Правда он ограничен. Жестоко ограничен.
            А теперь представьте, что вам повезло, и кое-какой индюк не удосужился поставить пароль на grub.
            А теперь представьте, что в роли этого индюка — вы. Хотите быть индюком? То-то же!

            Лишняя информация о возможной уязвимости — это хорошо. Даже если это баян с вашей точки зрения.
            • –1
              Мышку, клаву и монитор вам дадут на работе. Их не нужно будет вносить. Да ну и что по вашему нельзя пронести на работу микросхему от флешки и загрузиться с нее? Если важный раздел с данными не зашифрован. Соответственно ваш пароль на груб не будет никого защищать.
    • +1
      нет :) пароль на вход стоит, но он не для ограничения доступа того, кто имеет физический доступ он стоит, а чтобы:
      а) был повод лишний раз подумать «а оно мне надо» перед запуском команды из под sudo/gksu
      б) ограничить удалённый доступа (sshd проброшен на vps, чтобы в любой момент мог зайти на домашний комп, например, с работы, а периодически к sshd пытаются коннектиться)
  • –6
    > И не стоит недооценивать школьников
    М-да. Да, не стоит их недооценивать, некоторые могут и хабр читать, а некоторым, представляете, может быть обидно про себя такое читать.
  • 0
    Вспомнил как регулярно получал рутовский suid-ный исполняемый файл шелла через single user mode в FreeBSD.
    • 0
      ну там проще, /etc/ttys
      # If console is marked «insecure», then init will ask for the root password
      # when going to single-user mode.
      console none unknown off insecure
  • 0
    во freebsd тоже можно в однопользовательский режим зайти без проблем, если он не отключен.
  • 0
    Не редко биосы позволяют выбирать устройство для загрузки (чаще всего по F8), даже если на сам вход в биос стоит пароль. Тут загрузочной флешкой можно что угодно сделать.

    На Windows XP тоже есть похожая уловка (не уязвимость в прямом смысле), на которую часто попадаются пользователи. Оригинальная система (не сборка с автоустановкой) перед первым входом в систему просит ввести до пяти имён пользователей, причём пропустить этот шаг нельзя. После создания хотя бы одного пользователя встроенный администратор автоматически скрывается с экрана приветствия. Далее пользователь ставит пароль на свою учётную запись и уверен, что в систему никто кроме него не зайдёт, ведь на экране приветствия только одна учётная запись с паролем. Однако достаточно нажать Ctrl+Alt+(Del*2), как тут же вместо экрана приветствия покажется классическое окно входа в систему; вводим туда «Администратор» (на русской системе, или, соответственно, Administrator на английской), Enter и всё — права получены за считанные секунды.
    • 0
      > Не редко биосы позволяют выбирать устройство для загрузки (чаще всего по F8), даже если на сам вход в биос стоит пароль. Тут загрузочной флешкой можно что угодно сделать.

      В случае запрета внешних носителей — нет.
      А вообще, обычно в тех местах где заботятся о безопасности просто некуда вставлять флешки. И диски. А у некоторых мало того, что корпус на замке, так еще и пустые pci слоты залиты какой то дрянью.
    • 0
      Если есть возможность загрузиться со своего носителя, то в ХР о пароле можно забыть.
      msv1_0.dll правится за 5 минут. И все пароли по боку. Причем до некоторого момента будет абсолютно незаметно.
      • 0
        Всё гораздо проще.
        • 0
          Скорее всего эта сборка тоже самое делает. Есть еще варианты простого сброса пароля. До сих пор где-то образ валяется, как память об эникейском прошлом :) Но это заметно и используется когда легально нужно пароль сбросить.

          В целом, как писали выше, защитить данные может только шифрование.
    • +4
      О, да это был грандиозный фэйл в безопасности WinXP.
      Что интересно, первоначально в голом WinXP (без сервиспаков) этот создаваемый по умолчанию при установке системы юзер Администратор/Administrator (со всеми админскими привилегиями, но при этом с пустым паролем) мог использоваться не только для локального интерактивного входа в систему, но и для удалённого доступа.
      Т.е. с любой другой машины в локальной сети можно было подключать диски этой машине (ADMIN$, C$, D$ ...), удалённо запускать/останавливать любые службы, удалённо подключаться к системному реестру и вообще делать любой Remote Code Execution ат имени юзера Администратор/Administrator с пустым паролем.

      Ну т.е. просто сканируешь локальную сеть на наличие WinXP-машин с пустым паролем админа, а дальше делаешь с ними удалённо всё, что захочешь: копируешь/удаляешь данные, подсаживаешь любой троян/руткит/keylogger, устанавливаешь/удаляешь запускаешь/останавливаешь любые приложения/сервисы, имеешь удалённую командную строку и т.д. Просто рай для кул-хацкеров.

      Эту ситуацию Microsoft решил исправить в SP1 для WinXP. Но вместо того, чтобы пересмотреть модель безопасности и запретить существование в системе учётных записей с пустым паролем (или хотя бы не создавать по умолчанию админского юзера с пустым паролем), они просто добавили в систему политику, по которой для юзеров с пустыми паролями запрещался удалённый доступ к системе по сети.
      Проблема с кул-хацкерами, которые ломились по сети на машины с WinXP с пустым паролем админа, как бы пропала, но локальный доступ от админа с пустым паролем всё равно остался. Т.е. и локально можно было залогиниться админом с пустым паролем, или локально выполнить от админа с пустым паролем любой произвольный код (хоть через тот же runas) — любой примитивный вирус, запущенный от непривилегированного пользователя, мог получить полный админский доступ к системе.
      • 0
        а помните фишку с подменой стандартной заставки на cmd.exe? это тоже было чудо
        • +2
          да помним, конечно…
          — и подмену дефолтовой заставки logon.scr на произвольный исполняемый файл (хоть cmd.exe, хоть что угодно ещё). А заставка эта запускалась по умолчанию от имени SYSTEM, если на этапе логина в систему никем не логиниться и не проявлять клавиатурно-мышиную активность 10-15 минут.
          — и загрузку с флопика/CD на базе DOS + NTFSDOS с последующим патчем библиотеки виндового криптопровайдера (msv1_0.dll), о чём уже написали выше. Что позволяло потом залогиниться в систему под любым существующим юзером без ввода его пароля. Пропатчил библиотеку, вошёл в Windows под любым юзером, сделал от его имени что угодно, потом опять грузишься с флопика/CD, делаешь откат патча. В результате у всех сохраняются старые пароли, механизм проверки паролей восстанавливается, и совсем уж явных признаков несанкционированного доступа нет.
          — и запуск командной консоли от имени юзера System (у которого полномочий больше, чем у обычного админа) через scheduled tasks.
          Пишешь в командной строке at 10:30 cmd.exe /interactive и добавляется задание, которое в указанное время (в данном примере в 10:30) запустит cmd.exe от имени Local System. (синтаксис точно не помню, возможно ключ /interactive нужно указывать сразу после at)

          Да и много прочих ляпов в безопасности Windows, которые сходу и не вспомнишь, но их было немало.
          • 0
            Ностальгия, да?
  • +3
    В Виндах есть смешнее уязвимость. По-умолчанию пользователь может создавать файлы в корне диска (даже не админ). Часть сервисов по причине кривых рук указывает путь к файлу сервиса без кавычек (например, c:\program files\intel system monitoring\monitor.exe). Если положить файл c:\program.exe в корень диска, то он будет запущен с правами сервиса (чаще всего system). Дальше вопрос техники.
    • +2
      >> пользователь может создавать файлы в корне диска
      по умолчанию не может

      >> Если положить файл c:\program.exe в корень диска
      винда скажет что это плохо и предложит его переименовать
      • +2
        Может. Проверьте сами. Не знаю как в новомодных системах, а в windows XP — может. Такая дурацкая предустановка.
        • +3
          нет, не может:

          • +2
            папки в корне они могут создавать, а файлы нет.
          • 0
            А может быть у вас лицензионная версия или максимально приближенная к оригинальной, поэтому все хорошо с этой точки зрения?
            • +2
              лицензионная версия от не лицензионной технически ничем не отличаются.
              • –1
                Просто на пиратки в большинстве случаев навешивается всякая ерунда вкупе с модификациями некоторых файлов и изменением реестра.
                • +1
                  Когда на хабре говорят «всякая ерунда» (подразумевающая «что-то такое, чего я не знаю и не понимаю) я понимаю, что хабр уже не тот.

                  Извините, если вы, как технический специалист, не понимаете что делают обычно системы активации в пиратских версиях, что вы делаете на хабре?
                  • 0
                    Это что, стало постыдным, не знать подробностей конкретной реализации системы активации? Или вы имеете в виду что-то другое и я что-то недопонял?
                    • 0
                      вы все правильно говорите, но будем считать что мы говорим именно о не модифицированной windows xp, на %systemdrive% которой расположена ntfs.
                • 0
                  на этот случай в самой ОС есть средства восстановления прав —

                  support.microsoft.com/kb/313222/ru

                • 0
                  Вы, наверное, про «сборки от ...», но тут, как говорится, сам себе злой Буратино. Чисто же пиратская копия винды ничем не отличается от лицензионной, на то она и копия :)
  • +2
    Напомню тезис, который мне вбивали в голову при обучении: «Любая защита данных должна начинаться с ограничения физического доступа или невозможности его использования».

    А именно — Закрыть на замок\опечатать корпус, выдрать внешние носители (CD, DVD, etc), выключить в BIOS загрузку со всего, кроме HDD1 (особенно по сети и USB) и запаролить его, запаролить GRUB.

    Ну и разумеется сервера с реально ценными данными должны стоять в серверной с крепкой дверью и сигнализацией.

    До тех пор, пока это не сделано — не нужен даже GRUB, достаточно отцепить и унести в кармане HDD. А потом спокойно подключить его к своей машине и слить все, что нужно.

    Шифрование, сложные ключи и т.д. — это хорошо. Но во-первых не спасет от уничтожения данных, во-вторых — при наличии неограниченного времени и прямых рук ломается большая часть подобных защит, особенно «кустарных».
    • 0
      Как показывает практика, крепкие двери и сигнализация не спасает от несанкционированного доступа со стороны государственных структур даже в государственных структурах же. Тем более неограниченное время редкая роскошь
  • 0
    >> пользователь может создавать файлы в корне диска
    по умолчанию не может

    >> Если положить файл c:\program.exe в корень диска
    винда скажет что это плохо и предложит его переименовать
  • 0
    >рынок загрузчиков в мире *NIX

    Помойму неуместный термин. Какой рынок? Кто, что и кому продаёт?
  • 0
    Как и многие, считаю проблему надуманной. Безопасности это нисколько не вредит, потому что если есть доступ к физической консоли, то сделают что угодно. А если будет желание испортить всё-всё-всё, то даже загружаться в single user не станут — трахнут ломом по системнику.
    А чтобы данные не утекли, то /home стоит просто напросто зашифровать. А эти «уязвимости»(А точнее — возможности) граба описаны в мануале — собственно, совсем не секрет.

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