Вопросы Теги

безопасность debian / и т.д. полномочия

Если Вы разрабатываете для встроенной платформы, это не основано на i386 аппаратных средствах, необходимо будет кросс-скомпилировать. Проект Emdebian обеспечивает наборы инструментальных средств для разработки для многой архитектуры (ARM, m68k, MIPS и больше) на ПК (i386 или amd64). Это означает под Debian, можно просто добавить, что репозитории и Кв. - добираются, устанавливают набор инструментальных средств для цели (целей) по Вашему выбору.

5
07.03.2011, 03:08
5 ответов

Полномочия по умолчанию прекрасны, и необходимые. Если бы Вы, например, не оставили passwd мир читаемым, то большая связанная с пользователем функциональность прекратила бы работать. Файл, такой как/etc/shadow не должен быть (и не), читаемый мир.

Доверяйте ОС для разбираний в этом, если Вы не знаете очень хорошо, что ОС является неправильной.

7
27.01.2020, 20:32
  • 1
    (... и если Вы идете, смешивая с полномочиями в / и т.д., имейте альтернативный способ возвратить его - даже установка неправильных полномочий там могла сделать Вашу ОС незагрузочной) –   05.03.2011, 13:20

Почти весь конфигурационный файл должен быть читаемым миром, как Вы ожидаете, что Ваши приложения считают их иначе?

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

Единственный важный файл, о котором я могу думать, которые не имеют мирового читаемого разрешения, является/etc/shadow, любят указанный в других комментариях.

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

Существует также укрепить пакет, которые создают некоторые интересные зависимости и запрещают установку известных уязвимых пакетов.

4
27.01.2020, 20:32

Все швы, прекрасные кроме phpmyadmin каталог. Действительно старайтесь защитить файлы, таким образом, mysql пароль не просачивается.

2
27.01.2020, 20:32
  • 1
    я проверил его и кажется, что phpmyadmin настроил это правильно, файл (конфигурация-db.php) в этой папке, которая содержит пароль, не читаем миром. Спасибо за резкость :) –   06.03.2011, 01:02

passwd потребности быть миром, читаемым так, чтобы несколько инструментов могли работать правильно. Несмотря на его имя, пароли не хранятся там, они хранятся в /etc/shadow файл, который должен иметь полномочия -rw-------. passwd- файл вероятен резервное копирование. Все другие "файлы" являются каталогами и содержат конфигурационные файлы.

1
27.01.2020, 20:32

Давайте предпримем шаги назад: Если тем пользователям только нужен доступ к их корневым каталогам, большинство FTP-серверов имеет некоторую конфигурацию, устанавливающую, это только предоставляет доступ к тому каталогу, и больше нигде (обычно при помощи chroot).

Например, в ProFTPd, это - директива DefaultRoot:

<VirtualHost myhost.example.com>
  DefaultRoot ~
</VirtualHost>

http://www.proftpd.org/docs/faq/linked/faq-ch5.html#AEN524

1
27.01.2020, 20:32
  • 1
    Да Вы правы, и я действительно использую это, althrough я - испуганная загрузка людей сценарий PHP для доступа к файловой системе (я действительно думаю, что suphp отключил это через), –   06.03.2011, 01:00
  • 2
    @Danny Hiemstra: Насколько я вижу, suPHP может быть настроен, чтобы сделать аналогично, с помощью chroot директива: suphp.org/DocumentationView.html?file=CONFIG –   06.03.2011, 11:51

Теги

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