[devel] __libc_enable_secure в openssl libcrypto

[devel] __libc_enable_secure в openssl libcrypto

[Mikhail Novosyolov]

Попробовал собрать AppImage на основе библиотек из Альта. AppImage - это такая штука, где сбандлены необходимые для работы программы библиотеки, но libc используется системная, что позволяет и программу запускать в разных дистрибутивах, и системные плагины NSS использовать. Для этой цели собрал в сизиф пакет linuxdeployqt.

Оказалось, что libcrypto.so.10 (я делал на основе p8, то же самое будет относиться и к сизифу) использует внутренний в glibc интерфейс __libc_enable_secure, который не выведен наружу в других дистрибутивах.

Это сделано патчем openssl-owl-alt-issetugid.patch:
> --- openssl/crypto/uid.c
> +++ openssl/crypto/uid.c
> @@ -77,8 +77,12 @@ int OPENSSL_issetugid(void)
>  # include OPENSSL_UNISTD
>  # include <sys/types.h>
>  
> +extern int __libc_enable_secure;
> +
>  int OPENSSL_issetugid(void)
>  {
> +    if (__libc_enable_secure)
> +        return 1;
>      if (getuid() != geteuid())
>          return 1;
>      if (getgid() != getegid())
В связи с этим возник вопрос: в Альте glibc запатчен, чтобы вывести эту внутреннюю функцию?

Используется ли она в каких-либо еще внешних потребителях?

Re: [devel] __libc_enable_secure в openssl libcrypto

[Dmitry V. Levin]

On Sat, Apr 18, 2020 at 02:21:43AM +0300, Mikhail Novosyolov wrote:
> Попробовал собрать AppImage на основе библиотек из Альта. AppImage - это такая штука, где сбандлены необходимые для работы программы библиотеки, но libc используется системная, что позволяет и программу запускать в разных дистрибутивах, и системные плагины NSS использовать. Для этой цели собрал в сизиф пакет linuxdeployqt.
> 
> Оказалось, что libcrypto.so.10 (я делал на основе p8, то же самое будет относиться и к сизифу) использует внутренний в glibc интерфейс __libc_enable_secure, который не выведен наружу в других дистрибутивах.

Всё-таки __libc_enable_secure выведен у всех, потому что этот символ
определён в ld, а используется ещё и в libc.  Но у нас этот символ
версионирован не как у всех в GLIBC_PRIVATE, а в baseline version, что,
наверное, было не совсем правильно сделано, лучше было бы выделить для
этого отдельную версию, но потом уже поздно было это менять.

У нас в libc есть ещё несколько символов, которые широко используются
нашими пакетами, но которых пока нет в других libc:
__strlcat_chk
__strlcpy_chk
strlcat
strlcpy

> Это сделано патчем openssl-owl-alt-issetugid.patch:
> > --- openssl/crypto/uid.c
> > +++ openssl/crypto/uid.c
> > @@ -77,8 +77,12 @@ int OPENSSL_issetugid(void)
> >  # include OPENSSL_UNISTD
> >  # include <sys/types.h>
> >  
> > +extern int __libc_enable_secure;
> > +
> >  int OPENSSL_issetugid(void)
> >  {
> > +    if (__libc_enable_secure)
> > +        return 1;
> >      if (getuid() != geteuid())
> >          return 1;
> >      if (getgid() != getegid())
> В связи с этим возник вопрос: в Альте glibc запатчен, чтобы вывести эту внутреннюю функцию?

Да, коммит 730399f767758a200256d7eb20f74d2310ab973b.

> Используется ли она в каких-либо еще внешних потребителях?

Как минимум ещё в libtinfo.


-- 
ldv

Re: [devel] __libc_enable_secure в openssl libcrypto

[Mikhail Novosyolov]

18.04.2020 02:54, Dmitry V. Levin пишет:
> On Sat, Apr 18, 2020 at 02:21:43AM +0300, Mikhail Novosyolov wrote:
>> Попробовал собрать AppImage на основе библиотек из Альта. AppImage - это такая штука, где сбандлены необходимые для работы программы библиотеки, но libc используется системная, что позволяет и программу запускать в разных дистрибутивах, и системные плагины NSS использовать. Для этой цели собрал в сизиф пакет linuxdeployqt.
>>
>> Оказалось, что libcrypto.so.10 (я делал на основе p8, то же самое будет относиться и к сизифу) использует внутренний в glibc интерфейс __libc_enable_secure, который не выведен наружу в других дистрибутивах.
> Всё-таки __libc_enable_secure выведен у всех, потому что этот символ
> определён в ld, а используется ещё и в libc.  Но у нас этот символ
> версионирован не как у всех в GLIBC_PRIVATE, а в baseline version, что,
> наверное, было не совсем правильно сделано, лучше было бы выделить для
> этого отдельную версию, но потом уже поздно было это менять.
>
> У нас в libc есть ещё несколько символов, которые широко используются
> нашими пакетами, но которых пока нет в других libc:
> __strlcat_chk
> __strlcpy_chk
> strlcat
> strlcpy
>
>> Это сделано патчем openssl-owl-alt-issetugid.patch:
>>> --- openssl/crypto/uid.c
>>> +++ openssl/crypto/uid.c
>>> @@ -77,8 +77,12 @@ int OPENSSL_issetugid(void)
>>>  # include OPENSSL_UNISTD
>>>  # include <sys/types.h>
>>>  
>>> +extern int __libc_enable_secure;
>>> +
>>>  int OPENSSL_issetugid(void)
>>>  {
>>> +    if (__libc_enable_secure)
>>> +        return 1;
>>>      if (getuid() != geteuid())
>>>          return 1;
>>>      if (getgid() != getegid())
>> В связи с этим возник вопрос: в Альте glibc запатчен, чтобы вывести эту внутреннюю функцию?
> Да, коммит 730399f767758a200256d7eb20f74d2310ab973b.
>
>> Используется ли она в каких-либо еще внешних потребителях?
> Как минимум ещё в libtinfo.

У меня получилось собрать работающую на других дистрибутивах AppImage-подобную структуру на основе библиотек из p8, в т.ч. Qt5 оттуда, путем сборки openssl без патча openssl-owl-alt-issetugid.patch. Но наличие таких нюансов стало неприятной неожиданностью, и вот почему.

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

Больше всего интересует вопрос отечественной блобятинки, т.е. различных программных изделий, выпускаемых и используемых в рамках импортозамещения. Большинство их разработчиков не очень хорошо умеют упаковывать программы под Линукс, как с точки зрения сборки исполняемых файлов, так и с точки зрения создания RPM-пакетов или иных форм дистрибуции. В результате некоторые из них поддерживают только 1-2 отечественных дистрибутива, теряя часть пользователей, некоторые пытаются собирать по пакету под каждый дистрибутив, тратя на это огромное количество ресурсов. Это плохо и для разработчиков ПО, и для разработчиков дистрибутивов, которые вынуждены иметь с ним дело. Единственным выходом из ситуации я вижу попытки рекомендовать разработчикам собирать универсальные исполняемые файлы или пакеты с грамотно сбандленными библиотеками и грамотно прописанные зависимости в RPM, например, не libgnomekeyring, a libgnome-keyring.so.0()(64bit). Была мысль, что многим будет гораздо проще не
изобретать сложную систему сборки с частичной статической линковкой, а собирать с системными библиотеками в какой-нибудь ОС, а затем упаковывать AppImage, это очень просто. AppImage-подобную структуру можно положить в RPM-пакет, зная про AutoReq, AutoProv и др. И вот здесь встает вопрос, насколько помешают такие фокусы. Соберут в Альте - не заработает в других дистрибутивах. Тот же openssl настолько часто используется и однозначно будет сбандливаться, что Альт можно сразу не рекомендовать для сборки AppImage-подобных пакетов. А вот если собрать ПО на другом дистрибутиве, то есть небольшая вероятность возникновения проблем в Альте. Думаю, что нужно сильно постараться, чтобы их поймать, т.к. внутренний API __libc_enable_secure заведомо не стоит использовать, но, может быть, есть другие подобные нюансы.

Re: [devel] __libc_enable_secure в openssl libcrypto

[Michael Shigorin]

On Mon, Apr 27, 2020 at 11:30:47AM +0300, Mikhail Novosyolov wrote:
> Единственным выходом из ситуации я вижу попытки рекомендовать
> разработчикам собирать универсальные исполняемые файлы или
> пакеты с грамотно сбандленными библиотеками и грамотно
> прописанные зависимости в RPM, например, не libgnomekeyring,
> a libgnome-keyring.so.0()(64bit).

Тянет на небольшой образовательный центр, как мне кажется.
Хотя ИСП РАН может оказаться при делах, глядишь, сделают
"русский LSB" ;-)

> Была мысль, что многим будет гораздо проще не изобретать
> сложную систему сборки с частичной статической линковкой,
> а собирать с системными библиотеками в какой-нибудь ОС,
> а затем упаковывать AppImage, это очень просто.

Чревато невоспроизводимостью, поскольку будет искушать
что-нить напихать/допилить вручную (особенно в аврал).

> AppImage-подобную структуру можно положить в RPM-пакет,
> зная про AutoReq, AutoProv и др. И вот здесь встает вопрос,
> насколько помешают такие фокусы. Соберут в Альте - не
> заработает в других дистрибутивах. Тот же openssl настолько
> часто используется и однозначно будет сбандливаться, что Альт
> можно сразу не рекомендовать для сборки AppImage-подобных
> пакетов. А вот если собрать ПО на другом дистрибутиве, то есть
> небольшая вероятность возникновения проблем в Альте.

Думаю так:

- если тяп-ляп, то собирать надёжней всего на чём-то вроде
  centos6 -- оно достаточно дубовое и консервативное по части
  ABI, чтобы на обратной совместимости работало более-менее
  везде (варианты сборки под более развесистые/заточенные
  наборы интерфейсов мне кажутся прогрессирующей рулеткой);

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

Кстати, Вы слышали про http://wiki.etersoft.ru/korinf?

> Думаю, что нужно сильно постараться, чтобы их поймать, т.к.
> внутренний API __libc_enable_secure заведомо не стоит
> использовать, но, может быть, есть другие подобные нюансы.

Ещё у нас ncurses была на что-то из glibc завязана, помнится.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] __libc_enable_secure в openssl libcrypto

[Mikhail Novosyolov]

27.04.2020 11:56, Michael Shigorin пишет:
> On Mon, Apr 27, 2020 at 11:30:47AM +0300, Mikhail Novosyolov wrote:
>> Единственным выходом из ситуации я вижу попытки рекомендовать
>> разработчикам собирать универсальные исполняемые файлы или
>> пакеты с грамотно сбандленными библиотеками и грамотно
>> прописанные зависимости в RPM, например, не libgnomekeyring,
>> a libgnome-keyring.so.0()(64bit).
> Тянет на небольшой образовательный центр, как мне кажется.
> Хотя ИСП РАН может оказаться при делах, глядишь, сделают
> "русский LSB" ;-)

Звучит прикольно, но вряд ли осуществимо и интересно всем сторонам в достаточной степени.

Да и решение проблемы нужно еще вчера, а не очередной стандарт.

>
>> Была мысль, что многим будет гораздо проще не изобретать
>> сложную систему сборки с частичной статической линковкой,
>> а собирать с системными библиотеками в какой-нибудь ОС,
>> а затем упаковывать AppImage, это очень просто.
> Чревато невоспроизводимостью, поскольку будет искушать
> что-нить напихать/допилить вручную (особенно в аврал).

Воспроизводимость зависит только от желания сделать воспроизводимым.

>
>> AppImage-подобную структуру можно положить в RPM-пакет,
>> зная про AutoReq, AutoProv и др. И вот здесь встает вопрос,
>> насколько помешают такие фокусы. Соберут в Альте - не
>> заработает в других дистрибутивах. Тот же openssl настолько
>> часто используется и однозначно будет сбандливаться, что Альт
>> можно сразу не рекомендовать для сборки AppImage-подобных
>> пакетов. А вот если собрать ПО на другом дистрибутиве, то есть
>> небольшая вероятность возникновения проблем в Альте.
> Думаю так:
>
> - если тяп-ляп, то собирать надёжней всего на чём-то вроде
>   centos6 -- оно достаточно дубовое и консервативное по части
>   ABI, чтобы на обратной совместимости работало более-менее
>   везде (варианты сборки под более развесистые/заточенные
>   наборы интерфейсов мне кажутся прогрессирующей рулеткой);

Думаю, пытаться стандартизировать сборочную среду не нужно, т.к. потребности разные, одно дело собрать hello world, другое дело - что-то сложное и требующее поддержку современных стандартов C++, например.

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

> - если учиться делать по уму, то учиться собирать "нативно"
>   (в плане ABI) на альте весьма полезно для получения заодно
>   и покрытия автоматическим контролем качества упаковки
>   от нашего инструментария -- что может быть полезно на
>   любом другом как минимум линуксе.
>
> Кстати, Вы слышали про http://wiki.etersoft.ru/korinf?

Нет (или забыл), но видел реализацию в wine@etersoft.  Собирать кучу разных пакетов vitlav@ легко, потому что он в этом хорошо разбирается, а вот для типового разработчика ПО это очень сложная процедура, ему надо собрать один раз и чтобы работало везде. И не по RPM под каждый дистрибутив, а один универсальный RPM + DEB + AppImage/tgz.

(если бы кто-нибудь разработчкам разного ПО рассказал про %_build_binary_file_digest_algo 1, то в p8 не мучились бы так сильно с зависимостями от rpmlib)

Re: [devel] __libc_enable_secure в openssl libcrypto

[Michael Shigorin]

On Mon, Apr 27, 2020 at 02:01:03PM +0300, Mikhail Novosyolov wrote:
> Да и решение проблемы нужно еще вчера, а не очередной стандарт.

К тому, что тут тоже есть оптимизация "вкороткую" и "вдолгую".

> >> собирать с системными библиотеками в какой-нибудь ОС,
> >> а затем упаковывать AppImage, это очень просто.
> > Чревато невоспроизводимостью
> Воспроизводимость зависит только от желания сделать
> воспроизводимым.

Чтоб желать, надо понимать; чтоб сделать, надо научиться.

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

Такие библиотеки окажутся у каждого свои; что хуже, у них-то
как раз скорее всего окажутся более развесистые зависимости
на системные библиотеки, которые вряд ли совпадут по soname
и/или ABI, если не предпринимать к тому мер.

Ср.: http://bugzilla.altlinux.org/36998

> > Кстати, Вы слышали про http://wiki.etersoft.ru/korinf?
> Собирать кучу разных пакетов lav@ легко, потому что он в этом
> хорошо разбирается, а вот для типового разработчика ПО это
> очень сложная процедура, ему надо собрать один раз и чтобы
> работало везде. И не по RPM под каждый дистрибутив, а один
> универсальный RPM + DEB + AppImage/tgz.

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

Вы бы взялись такое сертифицировать на совместимость?
Я -- нет.  Разве что жёстко выпуск с выпуском, что дорого.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] __libc_enable_secure в openssl libcrypto

[Anton Farygin]

On 27.04.2020 11:30, Mikhail Novosyolov wrote:
>   А вот если собрать ПО на другом дистрибутиве, то есть небольшая вероятность возникновения проблем в Альте. Думаю, что нужно сильно постараться, чтобы их поймать, т.к. внутренний API __libc_enable_secure заведомо не стоит использовать, но, может быть, есть другие подобные нюансы.

Есть вот такие нюансы, по которым тоже пока движения нету:
https://bugzilla.altlinux.org/show_bug.cgi?id=38163

Re: [devel] __libc_enable_secure в openssl libcrypto

[Dmitry V. Levin]

On Mon, Apr 27, 2020 at 11:30:47AM +0300, Mikhail Novosyolov wrote:
> 18.04.2020 02:54, Dmitry V. Levin пишет:
> > On Sat, Apr 18, 2020 at 02:21:43AM +0300, Mikhail Novosyolov wrote:
> >> Попробовал собрать AppImage на основе библиотек из Альта. AppImage - это такая штука, где сбандлены необходимые для работы программы библиотеки, но libc используется системная, что позволяет и программу запускать в разных дистрибутивах, и системные плагины NSS использовать. Для этой цели собрал в сизиф пакет linuxdeployqt.
> >>
> >> Оказалось, что libcrypto.so.10 (я делал на основе p8, то же самое будет относиться и к сизифу) использует внутренний в glibc интерфейс __libc_enable_secure, который не выведен наружу в других дистрибутивах.
> > Всё-таки __libc_enable_secure выведен у всех, потому что этот символ
> > определён в ld, а используется ещё и в libc.  Но у нас этот символ
> > версионирован не как у всех в GLIBC_PRIVATE, а в baseline version, что,
> > наверное, было не совсем правильно сделано, лучше было бы выделить для
> > этого отдельную версию, но потом уже поздно было это менять.
> >
> > У нас в libc есть ещё несколько символов, которые широко используются
> > нашими пакетами, но которых пока нет в других libc:
> > __strlcat_chk
> > __strlcpy_chk
> > strlcat
> > strlcpy
> >
> >> Это сделано патчем openssl-owl-alt-issetugid.patch:
> >>> --- openssl/crypto/uid.c
> >>> +++ openssl/crypto/uid.c
> >>> @@ -77,8 +77,12 @@ int OPENSSL_issetugid(void)
> >>>  # include OPENSSL_UNISTD
> >>>  # include <sys/types.h>
> >>>  
> >>> +extern int __libc_enable_secure;
> >>> +
> >>>  int OPENSSL_issetugid(void)
> >>>  {
> >>> +    if (__libc_enable_secure)
> >>> +        return 1;
> >>>      if (getuid() != geteuid())
> >>>          return 1;
> >>>      if (getgid() != getegid())
> >> В связи с этим возник вопрос: в Альте glibc запатчен, чтобы вывести эту внутреннюю функцию?
> > Да, коммит 730399f767758a200256d7eb20f74d2310ab973b.
> >
> >> Используется ли она в каких-либо еще внешних потребителях?
> > Как минимум ещё в libtinfo.
> 
> У меня получилось собрать работающую на других дистрибутивах AppImage-подобную структуру на основе библиотек из p8, в т.ч. Qt5 оттуда, путем сборки openssl без патча openssl-owl-alt-issetugid.patch. Но наличие таких нюансов стало неприятной неожиданностью, и вот почему.
> 
> Начнем с "обычных" пользователей. Среди них достаточно востребовано иметь возможность запускать AppImage и другие сторонние бинарные сборки в целях упрощения жизни и решения повседневных задач. Но вроде бы они особо не страдают и могут их запускать (ну, кроме заблокированного из коробки fuse, что мешает запустить AppImage, но, с точки зрения администратора корпоративных рабочих станций, мне такая блокировка из коробки скорее нравится, чем не нравится).
> 
> Больше всего интересует вопрос отечественной блобятинки, т.е. различных программных изделий, выпускаемых и используемых в рамках импортозамещения. Большинство их разработчиков не очень хорошо умеют упаковывать программы под Линукс, как с точки зрения сборки исполняемых файлов, так и с точки зрения создания RPM-пакетов или иных форм дистрибуции. В результате некоторые из них поддерживают только 1-2 отечественных дистрибутива, теряя часть пользователей, некоторые пытаются собирать по пакету под каждый дистрибутив, тратя на это огромное количество ресурсов. Это плохо и для разработчиков ПО, и для разработчиков дистрибутивов, которые вынуждены иметь с ним дело. Единственным выходом из ситуации я вижу попытки рекомендовать разработчикам собирать универсальные исполняемые файлы или пакеты с грамотно сбандленными библиотеками и грамотно прописанные зависимости в RPM, например, не libgnomekeyring, a libgnome-keyring.so.0()(64bit). Была мысль, что многим будет гораздо проще не
> изобретать сложную систему сборки с частичной статической линковкой, а собирать с системными библиотеками в какой-нибудь ОС, а затем упаковывать AppImage, это очень просто. AppImage-подобную структуру можно положить в RPM-пакет, зная про AutoReq, AutoProv и др. И вот здесь встает вопрос, насколько помешают такие фокусы. Соберут в Альте - не заработает в других дистрибутивах. Тот же openssl настолько часто используется и однозначно будет сбандливаться, что Альт можно сразу не рекомендовать для сборки AppImage-подобных пакетов. А вот если собрать ПО на другом дистрибутиве, то есть небольшая вероятность возникновения проблем в Альте. Думаю, что нужно сильно постараться, чтобы их поймать, т.к. внутренний API __libc_enable_secure заведомо не стоит использовать, но, может быть, есть другие подобные нюансы.

Вы помните такой проект LSB, и чем он фактически закончился?


-- 
ldv

Re: [devel] __libc_enable_secure в openssl libcrypto

[Mikhail Novosyolov]

27.04.2020 14:55, Dmitry V. Levin пишет:
> Вы помните такой проект LSB, и чем он фактически закончился?
В курсе.  Достаточно в разумных пределах не ломать бинарную совместимость, что в целом вполне успешно делается, но возникают нюансы.