Re: Контролируем частоту ядер процессора

[yuri . nefedov]

On Thu, 15 Sep 2016, Pavel Ammosov wrote:


On Thu, Sep 15, 2016 at 09:26:39PM +0300, Grigory Fateyev wrote:

Недавно установил Debian stretch на новый ноут с i7 Skylake.

[..]

То есть частота мониторится железом и никакой настройки не
требуется. Я прав?


Последние несколько лет частоту на процессорах не регулируют, используется
механизм "race to idle" - процессор работает на номинальной частоте, а при
отсутствии задач уходит в idle вместо снижения частоты.

В ядре Linux за это отвечает параметр CONFIG_X86_INTEL_PSTATE, включенный в 
Debian
Всякие cpufreqd/thermald и прочие больше не нужны.



  А если хочется в фоне задачу гонять?

Ю.

Re: Контролируем частоту ядер процессора

[Pavel Ammosov]

On Thu, Sep 15, 2016 at 09:26:39PM +0300, Grigory Fateyev wrote:
> Недавно установил Debian stretch на новый ноут с i7 Skylake.
[..]
> То есть частота мониторится железом и никакой настройки не
> требуется. Я прав?

Последние несколько лет частоту на процессорах не регулируют, используется 
механизм "race to idle" - процессор работает на номинальной частоте, а при
отсутствии задач уходит в idle вместо снижения частоты.

В ядре Linux за это отвечает параметр CONFIG_X86_INTEL_PSTATE, включенный в 
Debian
Всякие cpufreqd/thermald и прочие больше не нужны.

Re: Контролируем частоту ядер процессора

[yuri . nefedov]

On Thu, 15 Sep 2016, Grigory Fateyev wrote:


Добрый день!

Недавно установил Debian stretch на новый ноут с i7 Skylake.
Хотел настроить мониторинг частоты ядер процессора, но
традиционный способ с cpufrequtils не работал, были доступны
два governer: powersave и performance. После некоорго гугления,
выяснил, что новыем intel ядра работют через intel_pstate
драйвер. Вот вывод:

# cpupower -c 0 frequency-info
analyzing CPU 0:
 driver: intel_pstate
 CPUs which run at the same hardware frequency: 0
 CPUs which need to have their frequency coordinated by software: 0
 maximum transition latency:  Cannot determine or is not supported.
 hardware limits: 800 MHz - 3.50 GHz
 available cpufreq governors: performance powersave
 current policy: frequency should be within 800 MHz and 3.50 GHz.
 The governor "powersave" may decide which speed to use
 within this range.
 current CPU frequency: 800 MHz (asserted by call to hardware)
 boost state support:
   Supported: yes
   Active: yes

То есть частота мониторится железом и никакой настройки не
требуется. Я прав?



 А если добавить "intel_pstate=disable" ?

 (
 /etc/default/grub
 GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable"
 )

Ю.

Re: Контролируем частоту ядер процессора

[Tim Sattarov]

On 15/09/16 02:26 PM, Grigory Fateyev wrote:
>
> То есть частота мониторится железом и никакой настройки не
> требуется. Я прав?
Недавно задавался таким же вопросом и пришел к тому же выводу.
дополнительных schedulers для этих процов не доступно.

Re: ищу планировщик, todo-лист на замену BSD calendar

[Victor Wagner]

On Thu, 15 Sep 2016 20:30:16 +0700
Denis  wrote:

> Ищу софтину, способную заменить для меня BSD calendar для ведения
> todo-листа
> 
> Обязательные требования:
> 
>   * интерфейс командной строки
>   * возможность создавать подзадачи
>   * возможность настраивать повторяемость по различным формулам, в
> частности: n-ая суббота каждого месяца,
>   * настраивать зависимость задач друг от друга (т.е. зависимая задача
> не появляется в листе, пока не будет выполнена задача, от которой
> она зависит)
> 
> Сам неспеша ищу замену. Попробовал taskwarrior и cursecal, оба не 
> удовлетворяют 3-му условию (нельзя настроить повторяемость например
> по 3-им субботам каждого месяца), что очень нравится в BSD календаре

Ну во-первых, есть в debian пакет bsdmainutils, а в нем calendar. Это
не тот самый BSD-шный календарь?

А как насчет возможностей  pal? 


У pal есть возможность настроить события по третьим субботам каждеого
месяца. И даже - по последним субботам каждого месяца, даже независимо
от того, сколько в месяц попадает суббот.

Правда, по-моему там плохо с зависимостями.


Что касается taskwarrior, то в jessie он очень старый. Когда я захотел
его попробовать, пришлось бэкпортить из stretch, поскольку главная фича
taskwarrior на мой взгляд - синхронизация.


> 
> жду советов не в виде списка ссылок на различный софт по теме
> (гуглить умею сам), а на софт, который вы лично использовали и
> знаете, что перечисленным выше требованиям он удовлетворяет
> 



-- 
   Victor Wagner 

Контролируем частоту ядер процессора

[Grigory Fateyev]

Добрый день!

Недавно установил Debian stretch на новый ноут с i7 Skylake.
Хотел настроить мониторинг частоты ядер процессора, но
традиционный способ с cpufrequtils не работал, были доступны
два governer: powersave и performance. После некоорго гугления,
выяснил, что новыем intel ядра работют через intel_pstate
драйвер. Вот вывод:

# cpupower -c 0 frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 800 MHz - 3.50 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3.50 GHz.
  The governor "powersave" may decide which speed to use
  within this range.
  current CPU frequency: 800 MHz (asserted by call to hardware)
  boost state support:
Supported: yes
Active: yes

То есть частота мониторится железом и никакой настройки не
требуется. Я прав?

[DONE] wml://security/2016/dsa-36{69,70}.wml

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3669.wml2016-09-15 22:46:04.0 
+0500
+++ russian/security/2016/dsa-3669.wml  2016-09-15 22:49:51.705311138 +0500
@@ -1,13 +1,14 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Dawid Golunski of LegalHackers discovered that the Tomcat init script
- -performed unsafe file handling, which could result in local privilege
- -escalation.
+Давид Голунский из LegalHackers обнаружил, что 
сценарий инициализации Tomcat
+выполняет небезопасную обработку файлов, 
что может приводить к локальному
+повышению привилегий.
 
- -For the stable distribution (jessie), this problem has been fixed in
- -version 7.0.56-3+deb8u4.
+В стабильном выпуске (jessie) эта проблема 
была исправлена в
+версии 7.0.56-3+deb8u4.
 
- -We recommend that you upgrade your tomcat7 packages.
+Рекомендуется обновить пакеты tomcat7.
 
 
 # do not modify the following line
- --- english/security/2016/dsa-3670.wml2016-09-15 22:47:20.0 
+0500
+++ russian/security/2016/dsa-3670.wml  2016-09-15 22:51:18.420013493 +0500
@@ -1,15 +1,16 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Dawid Golunski of LegalHackers discovered that the Tomcat init script
- -performed unsafe file handling, which could result in local privilege
- -escalation.
+Давид Голунский из LegalHackers обнаружил, что 
сценарий инициализации Tomcat
+выполняет небезопасную обработку файлов, 
что может приводить к локальному
+повышению привилегий.
 
- -For the stable distribution (jessie), this problem has been fixed in
- -version 8.0.14-1+deb8u3.
+В стабильном выпуске (jessie) эта проблема 
была исправлена в
+версии 8.0.14-1+deb8u3.
 
- -For the unstable distribution (sid), this problem will be fixed soon.
+В нестабильном выпуске (sid) эта проблема 
будет исправлена позже.
 
- -We recommend that you upgrade your tomcat8 packages.
+Рекомендуется обновить пакеты tomcat8.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX2t+cAAoJEF7nbuICFtKlG7EQAIW0NQleUEm45ljzRmpo2go7
448BE189ZAFiGr+Ke5TkmN7cPZF++/nRjcSypNe9nLu/JkU3AbVB5yk0F8yc+hfV
qTCo5crMPxk6cGARdXDyrhY68j5yH6/lhu8CHwbxOqZzEhWk2q9R+xomcMacqH2g
/6AH0pyIWsCP05xyBpcqV4HvfHKCzmurOSd7qi4X4zK7XlOwhyDgzrPr+crvJPMt
244l8VaU4SCSraFDhvusJIb53U4/oGuYAV30wiPRirw2arQ+rScSTvWhHKBwMdFm
c8zcBCeNw67VKVM0Y3qbwSmJwMwyHM8WcBErHprtB8wMEVxeNKu6AWZehyDA/eQS
XnZHfb42WZSuwovIObkaQER5/Rlv9zupLrS9qz6NlrTo1QplieE1iq6St+RMpQPh
j8lDT7nys+5HbKxIyPaoD6vyAohvqwEN2Vho/b7DVHk4z226NfJEv1CLydYsKtPd
8b23HZj7dGeBSs3/KjTA8bO/eAxlqkgjFCWFtyLYv1rnqZbnCj86VoZY2RxZ6dKU
px6SI7cTEOaJ7ZGECCDyEEQwxLHnFfYPjeIQRyNSNkdADI/rihDVtXBr2vzTnFCE
UA148NcVjpLr0O7lwyLtd+RCPAYelyyIRYfS4ksSQ5Z9R51RUlgggw2iUkguFE3L
7VhJ3wi5Gv6bB1CPO6Nz
=AYD1
-END PGP SIGNATURE-

Re: PKI self-service

[Bogdan]

2016-09-15 18:08 GMT+03:00 Tim Sattarov :

> On 15/09/16 01:27 AM, Bogdan wrote:
> > Добрый день!
> >
> > Спасибо за ответы, судя по всему готового решения нет (что крайне
> > странно). Писать самостоятельно продукт такого рода - опасно и дорого.
> > FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> > функциональность.
> >
> FreeIPA это обертка вокруг BIND, ds389, dogtag и так далее. Как раз таки
> dogtag и выполняет функции  CA.
>

Вот к сожалению отдельно в dogtag нужного функционала нет, это просто CA,
всё остальное - внутри "комбайна".


>
> я не так давно был на конференции Hashconf, где обсуждался их новый
> продукт: Vault. в числе других задач он тоже может быть CA для организации.
> open source :)
> https://www.vaultproject.io/


Спасибо, посмотрю.



-- 
WBR,  Bogdan B. Rudas

Re: PKI self-service

[Tim Sattarov]

On 15/09/16 01:27 AM, Bogdan wrote:
> Добрый день!
>
> Спасибо за ответы, судя по всему готового решения нет (что крайне
> странно). Писать самостоятельно продукт такого рода - опасно и дорого.
> FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> функциональность.
>
FreeIPA это обертка вокруг BIND, ds389, dogtag и так далее. Как раз таки
dogtag и выполняет функции  CA.

я не так давно был на конференции Hashconf, где обсуждался их новый
продукт: Vault. в числе других задач он тоже может быть CA для организации.
open source :)
https://www.vaultproject.io/

Re: ищу планировщик, todo-лист на замену BSD calendar

[Иван Лох]

On Thu, Sep 15, 2016 at 08:30:16PM +0700, Denis wrote:
> Ищу софтину, способную заменить для меня BSD calendar для ведения todo-листа
> 
> Обязательные требования:
> 
>  * интерфейс командной строки
>  * возможность создавать подзадачи
>  * возможность настраивать повторяемость по различным формулам, в
>частности: n-ая суббота каждого месяца,
>  * настраивать зависимость задач друг от друга (т.е. зависимая задача
>не появляется в листе, пока не будет выполнена задача, от которой
>она зависит)
> 
> Сам неспеша ищу замену. Попробовал taskwarrior и cursecal, оба не
> удовлетворяют 3-му условию (нельзя настроить повторяемость например по 3-им
> субботам каждого месяца), что очень нравится в BSD календаре

https://taskwarrior.org/docs/recurrence.html

ищу планировщик, todo-лист на замену BSD calendar

[Denis]

Ищу софтину, способную заменить для меня BSD calendar для ведения todo-листа

Обязательные требования:

 * интерфейс командной строки
 * возможность создавать подзадачи
 * возможность настраивать повторяемость по различным формулам, в
   частности: n-ая суббота каждого месяца,
 * настраивать зависимость задач друг от друга (т.е. зависимая задача
   не появляется в листе, пока не будет выполнена задача, от которой
   она зависит)

Сам неспеша ищу замену. Попробовал taskwarrior и cursecal, оба не 
удовлетворяют 3-му условию (нельзя настроить повторяемость например по 
3-им субботам каждого месяца), что очень нравится в BSD календаре


жду советов не в виде списка ссылок на различный софт по теме (гуглить 
умею сам), а на софт, который вы лично использовали и знаете, что 
перечисленным выше требованиям он удовлетворяет


--
. ''`.
: :’  :
`. `~’
  `-

Re: PKI self-service

[Коротаев Руслан]

В сообщении от [Чт 2016-09-15 12:53 +0300]
Bogdan  пишет:

> Доступные мне протоколы авторизации позволяют передавать только плейнтекст,
> либо заведомо уязвимые хэши паролей (md5 или ntlm) поверх TLS-сессии.
> Защищенность такой сессии зависит исключительно от корректности настройки
> (принудительная проверка "моего" CA) на стороне клиента, который будет
> выполнять настройки подключения сам. Honeypot и/или MitM  технически просты и
> достаточно вероятны в силу передачи данных по незащищенной и неконтролируемой
> среде. Я хочу полностью отказаться от такого типа авторизации в сервисе и
> перейти на авторизацию с использованием PKI. Вероятность успешного MitM/
> honeypot для веб-сайта раздающего сертификаты существенно меньше, чем для
> целевого сервиса.

Вы опасаетесь что с помощью MitM взломают TLS-сессию и поэтому хотите
авторизацию по сертификату клиента. Это маловероятно, конечно такое
решение надежно, но очень не удобно. Хотя если у вас клиенты технически
подкованные, например хранят сертификат и ключ на смарткарте, то да, а
так есть и другие варианты [1]. 

Кстати, вчера вы спрашивали насчет проверки отозванных сертификатов,
оказывается есть простой вариант OCSP-сервера [2] (CRL считается
устаревшим). Смысл такой, поднимаем OCSP-сервер например,
http://ocsp.example.com, прописываем его в сертификате и браузер сам
будет проверять отозванные сертификаты, детали здесь [3]. Причем
OCSP-ответы не обязательно подписывать тем же ключом что и сертификат,
можно выписать дополнительный сертификат специально для OCSP. То есть
центр сертификации может (или должен) быть не подключенным к сети, а
работу с OCSP можно доверить другой организации.

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

[1]: https://habrahabr.ru/company/dataart/blog/262817/
[2]: http://backreference.org/2010/05/09/ocsp-verification-with-openssl/
[3]: 
https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

-- 
Коротаев Руслан
https://blog.kr.pp.ru

Re: PKI self-service

[Bogdan]

2016-09-15 13:37 GMT+03:00 Victor Wagner :

> On Thu, 15 Sep 2016 12:53:06 +0300
> Bogdan  wrote:
>
> >
> > Если я правильно интерпретировал документацию. то готовое решение -
> > это Auto Enrollment в Microsoft Active Directory Certification
> > Services -
> > https://technet.microsoft.com/en-us/library/cc771107(v=ws.11).aspx
> > т.е., но к сожалению работает только с AD :/
>
> Кстати, возможно что да. Те, кому нужен security theater будут
> использовать винду.
>
>
>
> >
> > Доступные мне протоколы авторизации позволяют передавать только
> > плейнтекст, либо заведомо уязвимые хэши паролей (md5 или ntlm) поверх
> > TLS-сессии. Защищенность такой сессии зависит исключительно от
> > корректности настройки (принудительная проверка "моего" CA) на
>
> Да, ну и что? Уязвимым местом является все равно  не TLS-сессия, а
> хранение пароля или закрытго ключа на устройстве пользователя и
> возможность внедрения к нему на устройство кейлоггера.


Этот риск в целом принят. Утечка сертификат менее болезненна, т.к. страдает
только один сервис. Если утечет пароль - появляется доступ в ряд других,
заметно более важных сервисов.


>
> Использование авторизации по сертификатам как правило, снижает
> usability сильнее чем повышает security.
>
> Если сервис использует публичное доменное имя и публичный CA (хотя бы и
> startssl.com или letsencrypt), то mitm-атака, позволяющая получить хеш
> от пароля требует серьезной организационной поддержки - компрометация
> публичного CA под силу, пожалуй, только спецслужбе государства.
>
>
Понятие доменного имени в принципе не применимо к данном сервису.

Теперь по сути вопроса: для автоматизации процессов вокруг CA и
сертификатов есть несколько протоколов (СMC, CMP, SCEP) из который SCEP
выглядит наиболее "живым". Ряд CA имеют automated SCEP workflow позволяющий
в т.ч. и обрабатывать CSR без подтверждения человеком, следовательно нужен
SCEP-клиент с веб-интерефейсом, способный авторизовать конечного
пользователя LDAP, сформировать SCEP-запрос и передать результат
пользователю.
Судя по комментариям в #dogtag, требуемый интерфейс есть во FreeIPA, но это
очередной комбайн который будет не может пока интегрироваться со внешним
LDAP.



-- 
WBR,  Bogdan B. Rudas

[DONE] wml://{security/2016/dsa-3668.wml}

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3668.wml2016-09-15 17:25:40.0 
+0500
+++ russian/security/2016/dsa-3668.wml  2016-09-15 17:27:53.372261126 +0500
@@ -1,16 +1,17 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -It was discovered that there was a CSRF vulnerability in mailman, a
- -web-based mailing list manager, which could allow an attacker to obtain
- -a user's password.
+Было обнаружено, что в mailman, программе для 
управления списками рассылки
+через веб, имеется CSRF-уязвимость, которая 
может позволить злоумышленнику получить
+пароль пользователя.
 
- -For the stable distribution (jessie), this problem has been fixed in
- -version 1:2.1.18-2+deb8u1.
+В стабильном выпуске (jessie) эта проблема 
была исправлена в
+версии 1:2.1.18-2+deb8u1.
 
- -For the unstable distribution (sid), this problem has been fixed in
- -version 1:2.1.23-1.
+В нестабильном выпуске (sid) эта проблема 
была исправлена в
+версии 1:2.1.23-1.
 
- -We recommend that you upgrade your mailman packages.
+Рекомендуется обновить пакеты mailman.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX2pPMAAoJEF7nbuICFtKlfCYP/1mT6ihKqYOB6yZSdU5fv67X
uryiN/zN0+dEUhqISFJf6vOX7gM4+eeaB7QLYWXq8SfSm6QFemiK0OWxJ9rl48Sc
I5pOGUJN4o89v4NELF8y4Mr266CwCd5ppCcRiSigiW9Psj/odE9cSkQdg4uJ4J1C
1JO69Q9/eIzCYYDwub1I3IZ5guLz7kThiQ+2cPyMVAuC4pnGZ9RBCdi7rOMhEoqd
NGu793NscQFc+JdqWkaDMre3KS+zi67AA9xpyoiC4oSsFMWsNELULFuHlfAieCp5
mtYXVIEAoLQe2cIjxdAlA+XeZ63w3X3GNQS3Ttbx9qK2Hp4qpSpT6B7xf0AFfQTs
FQtlXcnG8yMc2nmM09UmFc3EYCoLDMvKiSIKop9HtTCIvgQpYxnK0H9PvaK4OX/h
RqmjaS8ingQFvSynMQp5d7NQ/Bme+mKpaBtHJeaL10I5jsSLssoNN5FL8QxDdF9R
U14AUIf3qsB+l9JP2WqSlJxl8zpl/BgH/Ja8TW+SOq+9YNZGReQvRSamPLiQLM/7
USu6uzBj+j0ELoiE09LNA+K/usjmVuyPJYB77VVjZ3b9m6T23b6uD+TJqskypNtk
TK2luTa+V3lAz6xysY2Suv7I0bC2dJdGaMy6xZ1ibuqrERKmrbyQXMwoMpoFaAJh
CbP8NWaPc4bz01w9mear
=GAKV
-END PGP SIGNATURE-

Re: PKI self-service

[Bogdan]

2016-09-15 9:04 GMT+03:00 Victor Wagner :

> On Thu, 15 Sep 2016 08:27:40 +0300
> Bogdan  wrote:
>
> > Добрый день!
> >
> > Спасибо за ответы, судя по всему готового решения нет (что крайне
> > странно). Писать самостоятельно продукт такого рода - опасно и дорого.
>
> Не то чтобы опасно и дорого. При предполагамемом (да и более высоком)
> уровне безопасности это пишется за полдя. Скорее как раз именно потому
> что трудно придумать решение, отвязанное от регламентов конкретной
> организации, тиражируемых продуктов и нет. Проще сделать свой,
> заточенный под свою схему безопасности, чем адаптировать процессы
> управления персоналом к готовому.
>
> > FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> > функциональность.
>
>
> Готового решения нет потому, что заявленный регламент работы
> противоречит базовым представлениям о безопасности тех, кто работает с
> криптографией.
>

Если я правильно интерпретировал документацию. то готовое решение - это
Auto Enrollment в Microsoft Active Directory Certification Services -
https://technet.microsoft.com/en-us/library/cc771107(v=ws.11).aspx т.е., но
к сожалению работает только с AD :/


>
> И в тех случаях, когда такой уровень безопасности считается достаточным,
> предпочитают обходиться вообще без сертификатов и PKI.
>
> А когда PKI все же нужна, предпочитают решения, в которых есть некий
> ответственный сотрудник, который знает пассфразу от ключа УЦ и
> проверяет что тот, кто пришел за сертификатом, именно он и есть.
> (в этом случае в маленькой фирме хватит чего-то типа tinyca, gnomint,
> pyca или даже easyrsa (входит в комплект openvpn).
>
> Ведь если у нас единственный proof of authencity который
> предоставляется при получении сертификата - это пароль хранящийся LDAP,
> то зачем нужна аутентификация по сертификату, когда проще везде
> аутентифицироваться оп  тому же самому паролю?
>


Доступные мне протоколы авторизации позволяют передавать только плейнтекст,
либо заведомо уязвимые хэши паролей (md5 или ntlm) поверх TLS-сессии.
Защищенность такой сессии зависит исключительно от корректности настройки
(принудительная проверка "моего" CA) на стороне клиента, который будет
выполнять настройки подключения сам. Honeypot и/или MitM  технически просты
и достаточно вероятны в силу передачи данных по незащищенной и
неконтролируемой среде. Я хочу полностью отказаться от такого типа
авторизации в сервисе и перейти на авторизацию с использованием PKI.
Вероятность успешного MitM/honeypot для веб-сайта раздающего сертификаты
существенно меньше, чем для целевого сервиса.



> Другие модели безопасности сравнимого уровня которые широко
> распространены, это пожалуй только domain-validadated only сертификаты
> для веб-серверов. Где проверяется что подавший заявку сертификат может
> по крайней мере выложить файлик на web-сервер с именем, на которое
> выписывается сертификат.
>
> По-моему в случае описанной задачи было бы логично генерировать для
> пользователя сертификат и ключевую пару в момент заведения его в LDAP и
> выдавать ему в виде PKCS12-файла и использовать автоматизированный
> rollover. Т.е. чтобы заявку на новый сертификат пользователь подписывал
> на старом.
>
> --
>
>
>


-- 
WBR,  Bogdan B. Rudas

[DONE] wml://{security/2016/dsa-3667.wml}

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3667.wml2016-09-15 12:27:17.0 
+0500
+++ russian/security/2016/dsa-3667.wml  2016-09-15 14:21:17.560240902 +0500
@@ -1,51 +1,52 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Several vulnerabilities have been discovered in the chromium web 
browser.
+В веб-браузере chromium было обнаружено 
несколько уязвимостей.
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2016-5170;>CVE-2016-5170
 
- -A use-after-free issue was discovered in Blink/Webkit.
+В Blink/Webkit было обнаружено 
использование указателей после 
освобождения памяти.
 
 https://security-tracker.debian.org/tracker/CVE-2016-5171;>CVE-2016-5171
 
- -Another use-after-free issue was discovered in Blink/Webkit.
+В Blink/Webkit было обнаружено ещё одно 
использование указателей после 
освобождения памяти.
 
 https://security-tracker.debian.org/tracker/CVE-2016-5172;>CVE-2016-5172
 
- -Choongwoo Han discovered an information leak in the v8 javascript
- -library.
+Чунву Хань обнаружил утечку 
информации в javascript-библиотеке
+v8.
 
 https://security-tracker.debian.org/tracker/CVE-2016-5173;>CVE-2016-5173
 
- -A resource bypass issue was discovered in extensions.
+В расширения был обнаружен обход 
ограничения ресурсов.
 
 https://security-tracker.debian.org/tracker/CVE-2016-5174;>CVE-2016-5174
 
- -Andrey Kovalev discoved a way to bypass the popup blocker.
+Андрей Ковалёв обнаружил способ обх
ода блокировщика всплывающих окон.
 
 https://security-tracker.debian.org/tracker/CVE-2016-5175;>CVE-2016-5175
 
- -The chrome development team found and fixed various issues during
- -internal auditing.
+Команда разработки chrome обнаружила и 
исправила различные проблемы в ходе
+внутреннего аудита.
 
 https://security-tracker.debian.org/tracker/CVE-2016-7395;>CVE-2016-7395
 
- -An uninitialized memory read issue was discovered in the skia
- -library.
+В библиотеке skia было обнаружено чтение 
неинициализированной
+памяти.
 
 
 
- -For the stable distribution (jessie), these problems have been fixed in
- -version 53.0.2785.113-1~deb8u1.
+В стабильном выпуске (jessie) эти проблемы 
были исправлены в
+версии 53.0.2785.113-1~deb8u1.
 
- -For the testing distribution (stretch), these problems will be fixed 
soon.
+В тестируемом выпуске (stretch) эти проблемы 
будут исправлены позже.
 
- -For the unstable distribution (sid), these problems have been fixed in
- -version 53.0.2785.113-1.
+В нестабильном выпуске (sid) эти проблемы 
были исправлены в
+версии 53.0.2785.113-1.
 
- -We recommend that you upgrade your chromium-browser packages.
+Рекомендуется обновить пакеты 
chromium-browser.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX2mgRAAoJEF7nbuICFtKl17sP/A1kqStyyIO/O1Q1bOIZO666
mk1kYK93JNxx3XamdNmmZjxiaNTMmMOkSUBAiBbQ4T/FDgWKwZlVXi7t2fsut6vy
mqci+iBts7jjrgNAmCUuwTEnt1TXu8EiV3AU/GHTNscRL/fSlRC8aHhalTZr22qp
Hi5g970nmm1VGxTTZGgW48marX9GnW258VtSANwm39v+FRtqjN177LnpjSVfNl29
2iMY3/De4CEmW45kbhIXedx+La+iR/3BlTHHkX25xdcCQlysbE0hqdIM5SNFncPy
3Jn5sakxItF+/S1MpZLcCehBEoJh9tMoU9B7LGkyrOsjqf2sf8Hw0bF4qLCpm8AP
3MJTwT3tUr3fCQOilzpTQZeJfIUJNe9+jdKrNV03LrBBVBX88dRGcdvJHTZwEV3s
+WtHEcxGf0t7xb9amWjydPCABUI+atOPGqkayk47nrL8f+sLERf3ctBnKgRNUoHD
8HokhD2M5OqFZ07UPuZDB5dTmyS8vA44VTEC/9+YxHs8e/u69Xtx7DEknhnQEbPR
/9P+DEO/MHUryvMItQxsAGhtTpZPklwU2j0KkDCaSxyB3VXB6jd3DIb2ah79t+xm
7oItUS1feowlRThlKANsTPRG1hD8buwcct6qNEwjR3D+cL/knYlEddWFjW8eGRui
0+VRqDcxqqOJfh71iuPu
=c/ie
-END PGP SIGNATURE-

Re: PKI self-service

[Victor Wagner]

On Thu, 15 Sep 2016 08:27:40 +0300
Bogdan  wrote:

> Добрый день!
> 
> Спасибо за ответы, судя по всему готового решения нет (что крайне
> странно). Писать самостоятельно продукт такого рода - опасно и дорого.

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

> FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> функциональность.


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

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

А когда PKI все же нужна, предпочитают решения, в которых есть некий
ответственный сотрудник, который знает пассфразу от ключа УЦ и
проверяет что тот, кто пришел за сертификатом, именно он и есть.
(в этом случае в маленькой фирме хватит чего-то типа tinyca, gnomint,
pyca или даже easyrsa (входит в комплект openvpn).

Ведь если у нас единственный proof of authencity который
предоставляется при получении сертификата - это пароль хранящийся LDAP, 
то зачем нужна аутентификация по сертификату, когда проще везде
аутентифицироваться оп  тому же самому паролю?

Другие модели безопасности сравнимого уровня которые широко
распространены, это пожалуй только domain-validadated only сертификаты
для веб-серверов. Где проверяется что подавший заявку сертификат может
по крайней мере выложить файлик на web-сервер с именем, на которое
выписывается сертификат.

По-моему в случае описанной задачи было бы логично генерировать для
пользователя сертификат и ключевую пару в момент заведения его в LDAP и
выдавать ему в виде PKCS12-файла и использовать автоматизированный
rollover. Т.е. чтобы заявку на новый сертификат пользователь подписывал
на старом. 

--