Вопросы Теги

Запуск программ в качестве корня в Интернете

Исходя из ваших последних вопросов, похоже, что у вас есть проблема XY

Вот решение sed, основанное на ответе @ Zanna на ваш предыдущий вопрос Задача XY

[ f1]

1
задан 17 February 2012 в 16:52

9 ответов

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

запуск приложения в качестве другого пользователя (возможно, пользователь root, но не обязательно) затрудняет работу другого процесс доступа к файлам, которые принадлежат / созданы этим приложением, и делать другие неприятные вещи (например, отправить сигнал KILL). Это хорошо. если у приложения есть уязвимость (то есть отправка его каким-то специально отформатированным вводом заставляет его выполнять некоторый код через переполнение буфера и т. д.) - тогда, после использования этой уязвимости, злоумышленник сможет выполнить код с привилегиями этого процесса , В этом смысле запуск приложения с привилегиями root - это BAD, потому что он будет предоставлять наивысший уровень привилегий для злоумышленника.

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

Общим решением этой проблемы является выполнение так называемых «сбросов привилегий» на запуск программы; это часто используется для запуска веб-серверов и других потенциально доступных (и доступных извне) программ. Идея проста: программа запускается с правами root, но как можно скорее она переключается на некоторую учетную запись пользователя с минимальными привилегиями (без входа в систему, chroot-ed в ее домашний каталог и т. Д.) Таким образом, даже если это скомпрометировано, это дало бы злоумышленнику очень ограниченный доступ к системе. Кроме того, другие учетные записи пользователей (кроме суперпользователя) не будут иметь доступа к файлам приложения

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

[d11 ] На самом деле, в этой ситуации я думаю, что запуск может быть , поскольку непривилегированный пользователь будет иметь больше смысла. И, конечно же, Google дает нам несколько ссылок на эту тему:

запускает приложение в качестве другого пользователя (возможно, пользователь root, но не обязательно) затрудняет для другого процесса доступ к файлам принадлежащих / созданных этим приложением, и делать другие неприятные вещи (например, отправить сигнал KILL). Это хорошо.

запускает приложение в качестве другого пользователя (возможно, пользователь root, но не обязательно) затрудняет для другого процесса доступ к файлам, которые принадлежат / созданы этим приложением, и делать другие неприятные вещи (отправить Например, сигнал KILL). Это хорошо.

Как настроить и запустить Firefox 3.0b2 как другой пользователь в Ubuntu

. Принимая эту идею до крайности (как вы предлагаете в комментарии) даст вам систему, похожую на то, как работает Android; на Android каждое приложение работает в пределах собственной учетной записи пользователя, поэтому оно имеет доступ только к собственным файлам. Вероятно, в Ubuntu есть некоторые проблемные области, то есть, если вы загрузили файл с помощью Firefox, запущенного в ограниченной учетной записи, он сможет сохранить его только в своей домашней папке, так что невозможно будет открыть файл в текстовый процессор (который работает как другой пользователь) ...

2
ответ дан 25 May 2018 в 14:12
  • 1
    Ваша информация и ссылки дали мне несколько идей. Как это звучит: Живой диск будет иметь несколько учетных записей: Пользователи учетной записи: администратор паролей торрентов браузера Каждая учетная запись будет иметь свои привилегии, установленные в соответствии с минимальным уровнем выполнения операций, которые предлагают их имена. – bambuntu 17 February 2012 в 13:14
  • 2
    У вас не будет быстрого переключения пользователей, когда все сервисы должны использоваться с этим решением: каждое приложение будет обернуто скриптом python. Питон будет к этому: 1. su usernameHere 2. выполнить соответствующее приложение 3. выйти – bambuntu 17 February 2012 в 13:17
  • 3
    Все время административный пользователь может иметь все свои приложения, работающие как разные пользователи с соответствующими привилегиями, но графически видеть их все в одной учетной записи. Вы подразумевали, что может быть более безопасным управлять браузером как пользователем без возможности иметь повышенные привилегии. Это удовлетворяет этой ситуации безопасности, но все же позволяет пользователям, которые запускают эти оболочки python, потенциально поддерживать вещи как root при необходимости. Я понимаю, что это может не решить все проблемы, но похоже, это хорошая первая линия обороны? – bambuntu 17 February 2012 в 13:17
  • 4
    Я хотел сказать, что оболочка python для запуска приложений должна подписываться как пользователь, вызывающий эти сценарии, admin, а не выходить из системы. – bambuntu 17 February 2012 в 13:25
  • 5
    Я обновил свой ответ – Sergey 17 February 2012 в 13:47

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

  • запускает приложение в качестве другого пользователя (возможно, пользователь root, но не обязательно) затрудняет для другого процесса доступ к файлам, которые принадлежат / созданы этим приложением, и делать другие неприятные вещи (например, отправить сигнал KILL). Это хорошо.
  • , если у приложения есть уязвимость (например, отправка его каким-то специально отформатированным вводом заставляет его выполнять некоторый код через переполнение буфера и т. Д.) - тогда, после использования уязвимости, злоумышленник будет иметь возможность выполнять код с привилегиями этого процесса. В этом смысле запуск приложения с привилегиями root имеет значение BAD, потому что он будет предоставлять наивысший уровень привилегий для злоумышленника.

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

Общим решением этой проблемы является выполнение так называемых «привилегий» на запуск программы; это часто используется для запуска веб-серверов и других потенциально доступных (и доступных извне) программ. Идея проста: программа запускается с правами root, но как можно скорее она переключается на некоторую учетную запись пользователя с минимальными привилегиями (без входа в систему, chroot-ed в ее домашний каталог и т. Д.) Таким образом, даже если это скомпрометировано, это дало бы злоумышленнику очень ограниченный доступ к системе. Кроме того, другие учетные записи пользователей (кроме суперпользователя) не будут иметь доступа к файлам приложения

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

На самом деле, в этой ситуации я думаю, что запуск веб-браузера в качестве непривилегированного пользователя будет иметь больше смысла. И, конечно, Google дает нам несколько ссылок на эту тему:

Приняв эту идею до крайности (как вы предлагаете в комментариях), вы получите система, похожая на работу Android; на Android каждое приложение работает в пределах собственной учетной записи пользователя, поэтому оно имеет доступ только к собственным файлам. Вероятно, в Ubuntu есть некоторые проблемные области, то есть, если вы загрузили файл с помощью Firefox, запущенного в ограниченной учетной записи, он сможет сохранить его только в своей домашней папке, так что невозможно будет открыть файл в текстовый процессор (который работает как другой пользователь) ...

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

2
ответ дан 4 August 2018 в 17:32

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

  • запускает приложение в качестве другого пользователя (возможно, пользователь root, но не обязательно) затрудняет для другого процесса доступ к файлам, которые принадлежат / созданы этим приложением, и делать другие неприятные вещи (например, отправить сигнал KILL). Это хорошо.
  • , если у приложения есть уязвимость (например, отправка его каким-то специально отформатированным вводом заставляет его выполнять некоторый код через переполнение буфера и т. Д.) - тогда, после использования уязвимости, злоумышленник будет иметь возможность выполнять код с привилегиями этого процесса. В этом смысле запуск приложения с привилегиями root имеет значение BAD, потому что он будет предоставлять наивысший уровень привилегий для злоумышленника.

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

Общим решением этой проблемы является выполнение так называемых «привилегий» на запуск программы; это часто используется для запуска веб-серверов и других потенциально доступных (и доступных извне) программ. Идея проста: программа запускается с правами root, но как можно скорее она переключается на некоторую учетную запись пользователя с минимальными привилегиями (без входа в систему, chroot-ed в ее домашний каталог и т. Д.) Таким образом, даже если это скомпрометировано, это дало бы злоумышленнику очень ограниченный доступ к системе. Кроме того, другие учетные записи пользователей (кроме суперпользователя) не будут иметь доступа к файлам приложения

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

На самом деле, в этой ситуации я думаю, что запуск веб-браузера в качестве непривилегированного пользователя будет иметь больше смысла. И, конечно, Google дает нам несколько ссылок на эту тему:

Приняв эту идею до крайности (как вы предлагаете в комментариях), вы получите система, похожая на работу Android; на Android каждое приложение работает в пределах собственной учетной записи пользователя, поэтому оно имеет доступ только к собственным файлам. Вероятно, в Ubuntu есть некоторые проблемные области, то есть, если вы загрузили файл с помощью Firefox, запущенного в ограниченной учетной записи, он сможет сохранить его только в своей домашней папке, так что невозможно будет открыть файл в текстовый процессор (который работает как другой пользователь) ...

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

2
ответ дан 7 August 2018 в 19:40

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

  • запускает приложение в качестве другого пользователя (возможно, пользователь root, но не обязательно) затрудняет для другого процесса доступ к файлам, которые принадлежат / созданы этим приложением, и делать другие неприятные вещи (например, отправить сигнал KILL). Это хорошо.
  • , если у приложения есть уязвимость (например, отправка его каким-то специально отформатированным вводом заставляет его выполнять некоторый код через переполнение буфера и т. Д.) - тогда, после использования уязвимости, злоумышленник будет иметь возможность выполнять код с привилегиями этого процесса. В этом смысле запуск приложения с привилегиями root имеет значение BAD, потому что он будет предоставлять наивысший уровень привилегий для злоумышленника.

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

Общим решением этой проблемы является выполнение так называемых «привилегий» на запуск программы; это часто используется для запуска веб-серверов и других потенциально доступных (и доступных извне) программ. Идея проста: программа запускается с правами root, но как можно скорее она переключается на некоторую учетную запись пользователя с минимальными привилегиями (без входа в систему, chroot-ed в ее домашний каталог и т. Д.) Таким образом, даже если это скомпрометировано, это дало бы злоумышленнику очень ограниченный доступ к системе. Кроме того, другие учетные записи пользователей (кроме суперпользователя) не будут иметь доступа к файлам приложения

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

На самом деле, в этой ситуации я думаю, что запуск веб-браузера в качестве непривилегированного пользователя будет иметь больше смысла. И, конечно, Google дает нам несколько ссылок на эту тему:

Приняв эту идею до крайности (как вы предлагаете в комментариях), вы получите система, похожая на работу Android; на Android каждое приложение работает в пределах собственной учетной записи пользователя, поэтому оно имеет доступ только к собственным файлам. Вероятно, в Ubuntu есть некоторые проблемные области, то есть, если вы загрузили файл с помощью Firefox, запущенного в ограниченной учетной записи, он сможет сохранить его только в своей домашней папке, так что невозможно будет открыть файл в текстовый процессор (который работает как другой пользователь) ...

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

2
ответ дан 10 August 2018 в 08:05

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

Это мое понимание что по этой причине Ubuntu обрабатывает безопасность по-разному от других дистрибутивов. Он не устанавливает пользователя root. Он устанавливает пользователя, который получает права root, когда этот пользователь, как администратор, нуждается в привилегиях root. Как только задача будет завершена или будет достигнут срок, пользователь с доступом администратора потеряет привилегии root. Это уменьшает риск получения корневого доступа к вредоносному коду.

Вот почему в Ubuntu мы не используем «su», а «sudo» перед командой в терминале.

Это документ, из которого я получу свое понимание:

Ubuntu причины для sudo а не su или root

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

Я цитирую официальный документ:

По умолчанию пароль корневой учетной записи заблокирован в Ubuntu , Это означает, что вы не можете войти в систему как Root напрямую или использовать команду su, чтобы стать пользователем Root. Однако, поскольку физическая сущность Корневой учетной записи существует, все же можно запускать программы с привилегиями на уровне корневого уровня. Здесь происходит sudo - он позволяет авторизованным пользователям (обычно «административным» пользователям, для получения дополнительной информации см. AddUsersHowto) для запуска определенных программ в качестве Root без необходимости знать пароль root.
3
ответ дан 25 May 2018 в 14:12
  • 1
    Технически пользователь root существует (это императив Linux), и его можно включить для входа в систему, но ваше понимание звучит. Лучше всего избегать работы с правами root и что Ubuntu Desktop по умолчанию не дает вам корневого входа. По этой причине. – Oli♦ 17 February 2012 в 07:53
  • 2
    Я не хотел усложнять проблему техническими вопросами. Мое собственное понимание ограничено. Он основан на том, что я прочитал по этому вопросу. – grahammechanical 17 February 2012 в 07:59
  • 3
    Итак, когда что-то требует прав root, значит ли это, что мы должны вводить sudo для запуска? Я имею в виду, что есть несколько вещей, выполняемых как root, когда мы выходим онлайн, чтобы поддерживать функциональность Ubuntu. Является ли это угрозой, поскольку тот факт, что они работают, потому что для их запуска были необходимы привилегии root? – bambuntu 17 February 2012 в 09:07
  • 4
    Если программа, использующая скрипты на локальном диске и вредоносный код, изменила эти сценарии, я мог видеть, как проблема запуска программы с правами root. Вот почему я думал, что сохранение приложения в защищенной от корня области будет защищено от такой атаки. Файлы, которые он сделал бы, были бы привилегированы только для root. Эта защита не может существовать, если программа запускается как обычный пользователь. Все привилегии будут широко открыты для служб или приложений с одинаковыми привилегиями. То, что я вижу в качестве защиты, называется угрозой безопасности. Я смущен. – bambuntu 17 February 2012 в 09:38
  • 5
    Извините, но весь второй абзац - одно большое недоразумение концепции, каждое предложение :) Цитата, которую вы указали, объясняет все гораздо лучше – Sergey 17 February 2012 в 11:00

Нет, это не очень хорошая идея. Это может сломаться, и это может позволить эскалации root.

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

1
ответ дан 25 May 2018 в 14:12
  • 1
    Я хочу убедиться, что мы имеем в виду то же самое, когда говорим «running as root». Если я вхожу в систему с sudo su и запускаю процесс, это то же самое, что использовать sudo для запуска программы? Оба считают, что они выполняются как root? Если да, то работает что-нибудь с sudo угрозой? Даже менеджер пакетов? Должен ли мы запускать диспетчер пакетов? – bambuntu 17 February 2012 в 08:57
  • 2
    Да, в обоих случаях процесс имеет uid=0, т. Е. Работает как root. Менеджер пакетов должен запускаться от root до системных файлов chaneg; нет ничего плохого в этом, или, например, запустить vim как root для изменения файлов в /etc. Существует много ошибок при запуске случайных программ с правами root, если они не предназначены или предназначены для использования таким образом, и им не нужна эскалация привилегий. – poolie 17 February 2012 в 10:29
  • 3
    Что делать, если программа не имеет врожденных недостатков кодирования. Например, я имею в виду простой «привет мир», скрипт. Я пытаюсь понять, что мне нужно для защиты. Есть ли что-то, что нужно сделать для защиты «привет мир!»? сценарий только потому, что он запускается как root? Или проблема в кодировании программ, например, скажем, например, запуск скрипта из файлов, которые непривалимые процессы могут читать и писать? В этой ситуации процесс запуска root может быть обманут в код, который является разрушительным. Итак, какая из двух? – bambuntu 17 February 2012 в 10:48
  • 4
    См. ответ Сергея . – poolie 17 February 2012 в 10:56
  • 5
    poolie, спасибо за ссылки, см. мое сообщение выше, это также направлено вам. – bambuntu 17 February 2012 в 13:21

Нет, это не очень хорошая идея. Это может сломаться, и это может позволить эскалации root.

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

1
ответ дан 6 August 2018 в 02:07

Нет, это не очень хорошая идея. Это может сломаться, и это может позволить эскалации root.

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

1
ответ дан 10 August 2018 в 08:05

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

Это мое понимание что по этой причине Ubuntu обрабатывает безопасность по-разному от других дистрибутивов. Он не устанавливает пользователя root. Он устанавливает пользователя, который получает права root, когда этот пользователь, как администратор, нуждается в привилегиях root. Как только задача будет завершена или будет достигнут срок, пользователь с доступом администратора потеряет привилегии root. Это уменьшает риск получения корневого доступа к вредоносному коду.

Вот почему в Ubuntu мы не используем «su», а «sudo» перед командой в терминале.

Это документ, из которого я получаю свое понимание:

Ubuntu причины для sudo, а не su или root

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

Я цитирую официальный документ:

По умолчанию пароль учетной записи root заблокирован в Ubuntu. Это означает, что вы не можете войти в систему как Root напрямую или использовать команду su, чтобы стать пользователем Root. Однако, поскольку физическая сущность Корневой учетной записи существует, все же можно запускать программы с привилегиями на уровне корневого уровня. Здесь происходит sudo - он разрешает авторизованным пользователям (обычно «административным» пользователям, для получения дополнительной информации см. AddUsersHowto), чтобы запускать определенные программы в качестве корня без необходимости знать пароль root.

3
ответ дан 10 August 2018 в 08:05

Другие вопросы по тегам:

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