Можно ли запретить руту операции с блочными устройствами

А просто не запускать «вирусню» (хотя бы из-под рута) не вариант?

Будто действительно важные данные у тебя хранятся не на хомяке

А просто не запускать «вирусню» (хотя бы из-под рута) не вариант?

Лучше вообще на другой железке.

https://askubuntu.com/questions/867746/prevent-dd-from-destroying-ssd-or-hdd

ну я только такие костыли нашел, но они не спасут от echo > /dev/sda

А просто не запускать «вирусню» (хотя бы из-под рута) не вариант?

Будто действительно важные данные у тебя хранятся не на хомяке

Логика вышла из чата…

Причём тут хомяк к руту?

какую задачу ты пытаешься решить?

если твой ssd прямо сейчас перестанет подавать признаки жизни - какая разница какие у тебя там будут защиты?

от всего в мире не защититься
можно только уменьшить вероятность остаться ни с чем

делай бекапы в разные места
проверяй эти самые бекапы

вероятность того что что-то случится со всеми бекапами одновременно в 10 точках планеты - крайне низка

а вместо придумывания велосипедов - лучше заняться чем-то полезным

вероятность того что что-то случится со всеми бекапами одновременно в 10 точках планеты - крайне низка

Это если они будут офлайновые, а онлайновые опять может уничтожить троян ? :(

метеорит тоже может прямо сейчас упасть на землю, что поделать

ну у тебя ее и не было. рут не нужен чтобы твои персональные данные потереть, ключи там от сервера… или своровать

ну у тебя ее и не было.

Я задал вполне логичный вопрос.

рут не нужен чтобы твои персональные данные потереть, ключи там от сервера… или своровать

В правильном направлении мыслишь. Теперь попробуй соотнести это со своим вопросом в первом сообщении и понять, что тебе нужно на самом деле.

это ты перечитай и пойми, что я интересовался можно ли как-то защитить бекапы на других дисках от порчи

бекапы
других дисках

\0

это не бекапы
это просто файлики на других дисках

«срочные дела - никогда не бывают важными, а важные - срочными»

если вы просто копируете файлы на «другие диски» на той же машине - значит бекапируемые данные для вас не так важны

а если они не так важны, зачем вообще их копировать и что-то запрещать руту

Я всё прочитал и понял. Но смысла в этом нет.

1. Бэкапы на других дисках — не полноценные бэкапы.
2. Защитить их от того, от чего предполагается в изначальном вопросе, можно просто не запуская трояны. Хотя бы от рута.
3. Запрещать конкретные команды было бы всё равно бесполезно, потому что испортить файлы можно просто перенаправив в них вывод любой команды.

это просто файлики на других дисках

толи дело файлики в «облаках», которые тебе могут обратна не отдать из-за sanctions или личных убеждений какого-то транс-оленя

метеорит тоже может прямо сейчас упасть на землю, что поделать

Вероятность метеорита во много раз меньше вероятности поймать трояна. А если распределить бэкапы по разным точкам на планете, как ты предлагал, то небольшие метеориты не страшны для всех бэкапов в целом одновременно в отличии от троянов.

если вы просто копируете файлы на «другие диски» на той же машине - значит бекапируемые данные для вас не так важны

А как ты предлагаешь?

это ты перечитай и пойми, что я интересовался можно ли как-то защитить бекапы на других дисках от порчи

Отключить от компа ? :)

копируй в свои_облака, свои другие_сервера

если у тебя все данные в хранятся физически в одном месте - в электросети будет скачек и все ssd сгорят или загорится что-то внутри системника - что будешь делать?

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

на съемном носители все. заканчивай. а я лишь убедился в невозможности

если у тебя все данные в хранятся физически в одном месте - в электросети будет скачек и все ssd сгорят или загорится что-то внутри системника - что будешь делать?

Чем проверить проводку (комментарий)

Обратная сторона Эльбруса (комментарий)

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

Можно реплицировать на несколько ZFS серверов, и у некоторых половину зеркал пула обычно хранить в отключенном состоянии, а подключать их для resilvering только изредка раз в месяц и потом опять отключать. Тогда хотя бы не потеряешь данные максимум месячной давности, даже если выгорит проводка во всем подъезде от отгорания нуля и т.п., впрочем, ЛАТР или трансформатор 220В->110В - тоже прекрасная защита.

В общем так-то проблема на пустом месте. Те же сборочные скрипты PKGBUILD вроде выполняются в fakeroot, а root требуется только для команды install, которая перемещает собранные бинарники и конфиги куда-то в корень. Большинство прог не требует рута. Графических - вообще никакие, те они могут нанести вред как тот пакет для npm от борца за все «хорошее» и против всего «плохого» (например, запрета детям менять пол в соединенных социалистических штатах Омерики), который жителям России и Беларуси файлы с дисков поудалял, НО до моих снапшотов эти неотроцкисты-леваки не доберутся, тк они read-only и из них ничего удалить нельзя… Тут еще бы можно было припомнить Flatpak как дополнительный слой изоляции, но все пакеты для него требуют доступ к хомяку, поэтому он полностью бесполезен в плане защиты личных данных. Остаются немногочисленные утилиты, требующие root. cp, mv, find и тп откидываем сразу, так как они стандартные и почти не меняются… Остаются всякие fd, nmap, micro[penis], но в них я почему-то уверен, а rootkit скорее всего я (люблю себя) подхвачу никогда (роллинг). Итого: так как запретить руту затереть диски нельзя я буду и дальше периодически делать tar’ом бекапы хомяка на внешний SSD (тупо переходник SATA-USB купил - и любой диск становится внешним).

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

ты же у нас любишь теоризировать и сам же признаешь, что из твоего Firecracker так же можно сбежать зачем он тогда вообще нужен

https://unit42.paloaltonetworks.com/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/

http://www.freezepage.com/1696369975SJYNENJJLU

While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology’s limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environment that co-locate containers belonging to different customers. The root of the problem is the weak separation between containers when the host OS creates a virtualized userland for each container. There has been research and development focusing on designing truly sandboxed containers. Most of the solutions re-architect the boundary between the containers to fortify the isolation. This blog covers four unique projects from IBM, Google, Amazon, and OpenStack, respectively, that use different techniques to achieve the same goal, creating stronger isolation for containers. IBM Nabla builds containers on top of Unikernels, Google gVisor creates a specialized guest kernel for running containers, Amazon Firecracker is an extremely lightweight hypervisor for sandboxing applications, and OpenStack places containers in a specialized VM that is optimized for container orchestration platforms. The following overview of this state of the art research should help readers prepare for the upcoming transformation.

Сколько идиотов собралось: IBM, Amazon, Google, etc. (сарказм)

Один smilessss «самый умный» особенно по сравнению с ними или просто хочет нас одурачить (что больше походит на правду)?

данные будут похерены если оно решило похерить

И если рут одной машины мэппится на рута другой машины (что вообще не очевидно). А если на машине с блочными устройствами рут это какой-то другой обычный пользователь, то можно настроить ему права доступа на файлы.

Ты бы ещё через год ответил

Ты бы ещё через год ответил

Ты бы ещё не забыл поставить точку в конце предложения.

в то же время - если у тебя не будет дырявых сервисов - твой Firecracker становится ненужен

Да фто ви говогите!

В инструментарии для запуска изолированных контейнеров runc, применяемом в Docker и Kubernetes, найдена уязвимость CVE-2024-21626, позволяющая получить доступ к файловой системе хост-окружения из изолированного контейнера. В ходе атаки злоумышленник может перезаписать некоторые исполняемые файлы в хост-окружения и таким образом добиться выполнения своего кода вне контейнера. 

https://www.opennet.ru/opennews/art.shtml?num=60545

ты неадекватен отвечать на треды годовой давности

добавлю тебя в игнор

ты неадекватен отвечать на треды годовой давности

Почему с твоей точки зрения нельзя уточнять старые обсуждения по мере накопления информации? Или твоя задача выиграть спор наскоком, пусть даже ты неправ, главное что быстренько обделал свои делишки (обманул общественность)?

Не вижу проблем обсуждать сколько угодно давние события. Для этого кстати даже есть такая наука, называется история. :)

Уязвимость только что выявлена, btw.

добавлю тебя в игнор

Я шаз расплачусь, зачем ты так жестоко?