История изменений

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

sysctl kern.securelevel=${kern_securelevel}

). Этот скрипт запускается из /etc/rc, а /etc/rc, в свою очередь - программой /sbin/init, та - ядром, а ядро - бут-лоадером. Ты можешь в любое место этой цепочки прописать патч, который предотвратит выполнение указанного sysctl-а. Или можешь куда-нить вставить конфиг kern_securelevel=0 (как выше предложили в rc.conf.local наверно сработает). Или можешь подменить саму программу sysctl чтобы она не делала этого, когда её попросит об этом скрипт.

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

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

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

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

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

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

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

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

sysctl kern.securelevel=${kern_securelevel}

). Этот скрипт запускается из /etc/rc, а /etc/rc, в свою очередь - программой /sbin/init, та - ядром, а ядро - бут-лоадером. Ты можешь в любое место этой цепочки прописать патч, который предотвратит выполнение указанного sysctl-а. Или можешь куда-нить вставить конфиг kern_securelevel=0 (как выше предложили в rc.conf.local наверно сработает). Или можешь подменить саму программу sysctl чтобы она не делала этого, когда её попросит об этом скрипт.

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

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

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

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

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

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

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

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

sysctl kern.securelevel=${kern_securelevel}

). Этот скрипт запускается из /etc/rc, а /etc/rc, в свою очередь - программой /sbin/init, та - ядром, а ядро - бут-лоадером. Ты можешь в любое место этой цепочки прописать патч, который предотвратит выполнение указанного sysctl-а. Или можешь куда-нить вставить конфиг kern_securelevel=0 (как выше предложили в rc.conf.local наверно сработает). Или можешь подменить саму программу sysctl чтобы она не делала этого, когда её попросит об этом скрипт.

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

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

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

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

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

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

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

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

sysctl kern.securelevel=${kern_securelevel}

). Этот скрипт запускается из /etc/rc, а /etc/rc, в свою очередь - программой /sbin/init, та - ядром, а ядро - бут-лоадером. Ты можешь в любое место этой цепочки прописать патч, который предотвратит выполнение указанного sysctl-а. Или можешь куда-нить вставить конфиг kern_securelevel=0 (как выше предложили в rc.conf.local наверно сработает). Или можешь подменить саму программу sysctl чтобы она не делала этого, когда её попросит об этом скрипт. Или, может быть проще - смонтировать / в read-only и переставлять на read-write только для технических работ (обновлений ОС итд).

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

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

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

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

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

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

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

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

sysctl kern.securelevel=${kern_securelevel}

). Этот скрипт запускается из /etc/rc, а /etc/rc, в свою очередь - программой /sbin/init, та - ядром, а ядро - бут-лоадером. Ты можешь в любое место этой цепочки прописать патч, который предотвратит выполнение указанного sysctl-а. Или можешь куда-нить вставить конфиг kern_securelevel=0 (как выше предложили в rc.conf.local наверно сработает). Или можешь подменить саму программу sysctl чтобы она не делала этого, когда её попросит об этом скрипт.

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

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

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

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

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

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

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