Подстановочный сертификат и XCA

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

  • переключитесь на root, чтобы запустить unshare
  • переключитесь обратно на обычного пользователя, чтобы запустить bash (хотя кажется, что вы не используете никаких bashisms, поэтому вы также можете запустить sh , который был бы более переносимым и возможно, более легковесный)
  • несколько раз переключитесь обратно на root в этой bash оболочке, чтобы делать более привилегированные вещи

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

sudo unshare -m sh -c '
        mount --bind "$1" "$1";
        mount --make-private "$1";
        exec sudo -u "#$SUDO_UID" -g "#$SUDO_GID" sh -c "
                sudo -K;
                <unprivilegied program here>
        "
' - "$MOUNT_DIR"

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

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

sudo unshare -m /usr/local/bin/script-that-does-the-rest-of-the-work

Кроме того, это упростит написать свои правила sudo для разрешенных команд, которые трудно написать с использованием моего предложения, если вы не разрешите пользователю вообще запускать любую команду, что равносильно предоставлению им полного корневого доступа. В этом случае вам нужно разрешить команду unshare -m sh -c <огромный блок> "$ MOUNT_DIR" , которую довольно сложно написать Cmnd_Alias ​​.

0
11.04.2019, 01:20
2 ответа

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

1
28.01.2020, 02:15

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

Это означает, что этот сертификат нельзя использовать для выпуска новых сертификатов.

Если вы собираетесь выпускать сертификаты только для -домашнего использования, вам следует создать новый самоподписанный -сертификат для использования в качестве корневого сертификата ЦС. Я не знаком с XCA, но обычно в программном обеспечении CA для этого есть какой-нибудь инструмент.

Если вы собираетесь выпускать сертификат для использования внешними сторонами, я настоятельно рекомендую вам обратиться в компанию, которая знает PKI, чтобы помочь вам правильно настроить его. Это не просто и не дешево.

5
28.01.2020, 02:15

Теги

Похожие вопросы