Безопасность SIP-телефонии и, в частности, Ekiga

А можно как-то чтобы соответствующим образом не чмодить все файлы, к которым не хочешь допускать пользователя, из-под которого будет работать скайп, задать запрет доступа самому этому юзеру? Или все-таки придется задавать каждому из этих файлов настройки командой chmod xx0?

Предпочтительнее в таких случаях использовать средства мандатного контроля доступа.

Или все-таки придется задавать каждому из этих файлов настройки командой chmod xx0?

Чмод сам по себе не поможет, нужно и chown сделать ещё, иначе пользоваель из-под которого надо запустить, сам сможет сделать обратно chmod a+rwx {} :)

Мандатный контроль доступа – конечно, штука хорошая, но я еще не настолько продвинутый пользователь Линукс :)
Зачем менять владельца файлов, если я запускаю скайп из-под отдельного пользователя, а файлы принадлежат другим пользователям? Как пользователь, в котором запускается скайп, сможет в этом случае изменить мой настройки chmod 700?
И как мне защитить другие файлы от чтения, те же /var /proc и /tmp? Боюсь что для разных файлов необходимы разные значения chmod, и что если задать им chmod 700 это приведет к некорректной работе системы, если не хуже.

Зачем менять владельца файлов, если я запускаю скайп из-под отдельного пользователя, а файлы принадлежат другим пользователям?

Я сказал на случай, когда запускаете из-под своего же пользователя, а не отдельного.

И как мне защитить другие файлы от чтения, те же /var /proc и /tmp? Боюсь что для разных файлов необходимы разные значения chmod, и что если задать им chmod 700 это приведет к некорректной работе системы, если не хуже.

Поидее на такой случай есть chroot, но любая иксовая программа из чрута вылезет, так что всё равно не поможет. Ещё есть restricted shell, и запрет на исполнение посторонних бинарей кому попало, монтирование разделов с nosuid, noexec... в общем, это очень длинный вопрос. Городить огород можно, но стандартных решений (к стыду Linux) до сих пор нет. Можно ещё порыться по слову sandbox. Можно заюзать отдельную виртуальную машину под Skype. Я изначально говорил о минимуме: о запрете ему читать ~/ основного пользователя – это достигается легко. Запретить читать сетевые настройки и вообще информацию об ОС – уже намного труднее... тут уж кто во что горазд.

Боюсь что для разных файлов необходимы разные значения chmod, и что если задать им chmod 700 это приведет к некорректной работе системы, если не хуже.

Да, настраивать при исследовании надо так, чтобы влияло только на Skype. Тогда от силы Skype не будет работать, но не более того.

1. Возможно ли шифрование при звонках на гор. телефоны от говорящего и до оконечного узла в оупносоурсовых ресурсах телефонии, как в скайп? Т.е. чтобы прослушать могли только на гор. или моб. телефоне.
Если нет, почему не разрабатывают?
2. Есть ли оупносоурсные средства it-телефонии, в которых также как в Skype'е нельзя напрямую узнать IP с которым идёт общение, чтобы это выглядело как общение с абонентом через прокси?

Если отдельные иксы, из под которых запускать skype, запускать из-под открытых иксов через Xnest, насколько это снизит безопасность в описанной схеме решения?
P. S. Смысл в том, чтобы видеть скайп на том же дисплее, без необходимости переключаться между виртаульными дисплеями комадной Alt-Ctl-Fn

на такой случай есть chroot, но любая иксовая программа из чрута вылезет

Кстати и не иксовая тоже. Эндрю Мортон где-то в рассылке говорил, что чрут предназначен для разработки (сборки дистров, кросскомпиляции), а не для безопасности, и "укреплённые" версии чрута никуда включаться не будут.

Оказалось, что gdmflexiserver у меня запускает вторые, третьи и т.д. иксы из-под пользователя – я всегда это делал из-под рута, а тут случайно запустил, и запустилось.
При этом, все процессы Xorg принадлежат руту. Это как раз тот случай, когда "любая иксовая программа из чрута вылезет"?!
И чем это может быть опасно? Следует ли мне изменить настройки, чтобы gdmflexiserver запускался только из-под рута?

1. Возможно ли шифрование при звонках на гор. телефоны от говорящего и до оконечного узла в оупносоурсовых ресурсах телефонии, как в скайп? Т.е. чтобы прослушать могли только на гор. или моб. телефоне.

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

2. Есть ли оупносоурсные средства it-телефонии, в которых также как в Skype'е нельзя напрямую узнать IP с которым идёт общение, чтобы это выглядело как общение с абонентом через прокси?

Можно самому собрать подобную схему типа VPN+SIP. Если же выхотите готовго централизованного решения, да ещё и с заземлением – то да, этого нет. Единственный вариант – захламлять тор голосовым трафиком, но я не уверен что это в принципе будет работать, ибо пропускная способность низкая и не стабильная. В данном случае предпочтительнее будет общаться с абонентом через jabber+tor+gnupg.

Если отдельные иксы, из под которых запускать skype, запускать из-под открытых иксов через Xnest, насколько это снизит безопасность в описанной схеме решения?

Мне сдаётся, что существенно. Потенциально, раз вы из-под своего пользователя можете получить доступ к, то и злоумышленная программа запущенная под вашим юзером сможет.

P. S. Смысл в том, чтобы видеть скайп на том же дисплее, без необходимости переключаться между виртаульными дисплеями комадной Alt-Ctl-Fn

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

При этом, все процессы Xorg принадлежат руту. Это как раз тот случай, когда "любая иксовая программа из чрута вылезет"?!

Нет. Здесь это происходит "легитимно" через механизмы типа "суидности"/sudo (юз гугл чтоб узнать это).

И чем это может быть опасно?

В случае конкретных программ про которые вы спрашиваете ничего подсказать не могу, т.к. никогда с ними работал. Общаяже схема такова:

1. Поглядите к каким файлам/данным может получить доступ ваш юзер. Например, по умолчанию он обычно имеет доступ (без пароля) к содержимому почту, истории браузера, IM, всем файлам в домашнем каталоге, к чтению всех сетевых настроек (ifcocnfig, route, netstat, /etc/rc.conf) и т.д., но зато не имеет доступа к файлам типа /etc/passwd.shadow или /root/* или /home/другой_юзер.
2. Учтите, что потенциально любая из программ, которая выполняется под вашим юзером, может получить доступ ко всем данным перечисленным в пункте 1 (часто ей это и впрямь жизненно необходимо), и слить эти данные налево.
3. Сделайте выводы и ищите пути выхода. Запускать особо зловещие программы под отдельными иксами и отдельным юзером – самое простое, хотя и неудобное, решение, но зато "искаропки".

Запускать из-под другого юзера на свои иксы?

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

adhoc – перекидывать файлы под рутом от одного юзера к другому.
Иначе – да, через группы. Например, создаётся группа extra, которая и назначается всем файлам (не знаю как это настроить автоматически, видимо через vipw, прописав дефолтной группу extra юзеру, и umask), создаваемым skype-пользователем. Далее обычный рабочий юзер делается членом группы extra через редактирование /etc/groups.

Вот это

включить скай-юзера в группу рабочего юзера, также разрешив запись и чтение группе?

точно ни к чему делать.

Иначе – да, через группы. Например, создаётся группа extra, которая и назначается всем файлам (не знаю как это настроить автоматически, видимо через vipw, прописав дефолтной группу extra юзеру, и umask), создаваемым skype-пользователем.

А чем хуже может быть включить дополнительно позьзователя mainuser также в группу skypeuser, а не создавать отдельную группу для обоих пользователей? (Причем файлы-то под mainuser создаются как принадлежащие пользователю mainuser и группе mainuser, и со значением umask 077 к тому же).

А чем хуже может быть включить дополнительно позьзователя mainuser также в группу skypeuser, а не создавать отдельную группу для обоих пользователей?

Я имел в виду следующее: создание юзера стандартными средствами (useradd) обычно(?) не подразумевает создания одноименной группы. Для обычных юзеров группой по умолчанию является users, для кого-то – wheel, если было указано явно, для остальных – ещё какие-то служебные. Ну а так, здесь можно много чего неаворотить – вы и сами не хуже разбираетесь. Лично меня интуитивно смутило добавление небезопасного пользователя в группу безопасного: мало ли.. где и что можно произойти, так что лучше гайки закручить сразу :)