Single user mode via ssh

В работающей системе понизить securelevel нельзя. Доступа к консоли, как я понимаю, нет (IPMI?)? Можно попробовать в /etc/rc.conf.local переписать kern_securelevel в 0. Это по сути шелл скрипт, поэтому то, что выполняется позже, должно заместить значение.

Single user mode via ssh

Невозможно. В Single user отрабатывают только критические rc-скрипты, никаких long-running (syslogd, cron, sshd не запускаются; так же не настраивается сеть и не монтируются файловые системы, кроме / в read-only).

понижать securelevels

Невозможно. В рантайме можно только повысить, без возможности вертать всё взад.

Сформулируй нормально проблему. securelevel и single-user mode это не особо связанные друг с другом вещи. За тем исключением что в сингл-юзере обычно securelevel не настраивается, как и многое другое. Что именно тебе нужно?

вертать

возвращать

То есть про securelevels на VPS можно забыть, ок. Важная в общем-то фича, но в нынешних реалиях бесполезная.

В Single user отрабатывают только критические rc-скрипты, никаких long-running (syslogd, cron, sshd не запускаются; так же не настраивается сеть и не монтируются файловые системы, кроме / в read-only).

Как будто нельзя это изменить. Только зачем? Автор не сказал что он хочет по сути.

Как будто нельзя это изменить.

Можно, только от сингла в этом случае ничего не останется, и целесообразнее тогда сразу в мульти грузиться.

Дочитай до конца:

chflags schg на /etc/rc.conf

Single user загружается всегда в securelevel -1, на сколько я знаю, и там можно переставлять левел. Если возможности загрузиться в single user нет, то и возможности использовать эти левелы нет.

=> левелы на VPS отпадают.

Я и говорю: зачем? Когда @untitl3d объяснит суть вопроса - всё станет намного проще. А пока «хочу сингл юзер через ssh», «хочу понизить securelevel с помощью chflags» (что за бред вообще?) - ничего не ясно.

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

Дочитай до конца:
chflags schg на /etc/rc.conf

Ты поставил chflags schg /etc/rc.conf и не можешь его снять из-за того что в нём прописан securelevel 2? Или что? Выражайся яснее.

На всякий случай: securelevel это run-time переменная, она не лочится бут-лоадером на старте, но у неё особые правила перезаписи: можно переключить на более высокий, но не наоборот. То, что прописано в конфигах - просто выставляется стартовыми скриптами с помощью sysctl штатным способом (можно sysctl kern.securelevel=1 из командной строки набрать с тем же успехом).

Возможно ли, к примеру, в FreeBSD на VPS понижать securelevels установив chflags schg на /etc/rc.conf?

Ты поставил chflags schg /etc/rc.conf и не можешь его снять из-за того что в нём прописан securelevel 2? Или что? Выражайся яснее.

да

Возможно: настройка из rc.conf применяется скриптом /etc/rc.d/securelevel (можешь посмотреть, там тупо

sysctl kern.securelevel=${kern_securelevel}

Так что если хочешь защитить этот режим от выключения - надо скорее всего ставить schg на много чего в /boot, /bin, /sbin и /etc, а также на сами эти директории (иначе их могут переименовать и создать вместо них хакнутые). Возможно ещё /usr/local/etc. Или, может быть проще - смонтировать / в read-only и переставлять на read-write только для технических работ (обновлений ОС итд).

После таких мер ты его точно не снимешь без доступа к системной консоли. Правда я так и не понял, хочешь ты этого или наоборот. Если речь про удалённый сервер без физического доступа (в т.ч. через ip-kvm), то обычно предполагается, что подобный «бекдор» для системного администратора, позволяющий снять на время securelevel, намеренно оставляется. Да, это в итоге серьёзно понижает его пользу, но даже так он может теоретически защитить от ряда проблем.

------------------------

И ещё, возможно тебя заинтересует: securelevel можно прописывать джаилам. И хотя доступа к корневой файловой системе у них по идее и так нет, но тем не менее:

1) может найтись способ выхода из chroot-а (точнее, они и сейчас есть если не очень внимательно подходить к настройке джаилов) и доступ появится, но джаиловый securelevel никуда не исчезнет и будет мешать вредоносному софту делать некоторые вещи

2) можно оставить «системный» рутовый доступ, тщательно его защитить от всего, а всё остальное запустить в джаиле с securelevel-ом но в корнем в / (т.е. без chroot-а)

3) возможно, и внутри обычного джаила это всё не помешает

Спасибо за развернутый ответ.

Мой вопрос заключался в том, целесообразно ли использовать securelevels на VPS. Single user mode тут просто к слову, что если всё захардлочить, то снять локи можно будет только там, а на VPS в него не зайти по всей видимости.

Я так понял, что смысла нет по вышеуказанным тобой причинам.

rc.local отрабатывает последним, потому если securelevel уже повышен, то обратного пути нет.

На VPS часто есть VNC.

Буквально сегодня на aquinas.su своей виртуалке с фряхой (они не предоставляют фряху, но если вежливо попросить…) диски fsck’ал из сингла по VNC.

А умолчальный securelevel во фре — 0, так что не парься по этому поводу.

Только что проверил, скрипт в /usr/local/etc/rc.d/ работает, если там понизить и снять лок с rc.conf.

Не очень понял, как графический протокол поможет зайти в single user mode?

rc.conf.local это продолжение rc.conf

Про rc.local никто не писал, хотя он никак не последний, но наверно позже чем securelevel да.

Там этих мест куда можно вписать конфиг полно, и со временем всё больше становится. Ещё есть /etc/rc.conf.d/*

У всех виртуалок есть графический клиент на уровне гипервизора, вопрос лишь в том даёт ли доступ к нему хостер.

Для этого на хосте должен стоять VNC-сервер, тогда твоя виртуалка будет доступна на этапе загрузки BIOS (seabios) или UEFI (tianocore), а соответственно ты увидишь loader и сможешь делать всё то, что можешь делать локально (только настроек самого BIOS/UEFI у виртуалки нет).

rc.conf.local это не скрипт, и в манах гномко написано, чтобы логику в него не пихали. Для скриптоты и логики существует rc.local.

А rc.conf.d/ — это про конфиги rc-скриптов. Конфиги оттуда сорсятся в соответствии с загружаемым rc-скриптом.

И что? Вообще это таки скрипт, но я нигде этого не писал. Я писал только что там можно переопределить параметры rc.conf, заменив настройку securelevel на другую в обход schg на rc.conf.

А rc.conf.d/

defaults/rc.conf, defaults/vendor.conf, rc.conf, rc.conf.local и rc.conf.d/* это всё одно и тоже, независимо от того как они где называются, с единственной разницей что rc.conf.d/ сорсятся выборочно в зависимости от того какой сервис запускается, а остальные всегда.