Re: [devel] __libc_enable_secure в openssl libcrypto

["Dmitry V. Levin" <ldv@altlinux.org>]

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