Don't assume libselinux.so.1 to be present in the target systems

[probonopd]

qutebrowser/qutebrowser#1912 (comment)

[probonopd]

In kdenlive-16.12-alpha1-x86_64, the issue is

kdenlive-16.12-alpha1-x86_64/usr/lib/qt5/plugins/platforms/libqxcb.so

loads

kdenlive-16.12-alpha1-x86_64/usr/lib/libEGL.so.1 and/or
kdenlive-16.12-alpha1-x86_64/usr/lib/libglapi.so.0

Since the latter two are bundled from a CentOS system, they depend on libselinux.

But not all users appreciate that:
qutebrowser/qutebrowser#1912 (comment)
https://kdenlive.org/2016/10/kdenlive-packages-available-for-testing/

For example, on Manjaro Linux:

Getting the following error in Manjaro KDE:

This application failed to start because it could not find or load the Qt platform plugin “xcb”
in “”.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, xcb.

Reinstalling the application may fix this problem.
/tmp/.mount_NBF2EU/AppRun: line 49: 2322 Aborted (core dumped) kdenlive $@

Deleting libEGL.so.1 from the AppImage is a workaround for Arch Linux, but then the AppImage might refuse to run, e.g., on Fedora 23 (to be verified).

So the question is, can these libraries be rebuilt without the need for libselinux, or could we have some dummy selinux replacement library that does nothing.

Of course we could just bundle libselinux inside the AppImage but this is not recommended as it would draw in additional dependencies.

Please comment here if you have an idea how to solve this.

[probonopd]

https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds says

preload a dummy libselinux that makes all child processes think that SELinux is disabled

Where can we get this?

[probonopd]

@darealshinji can you do a dummy libselinux.so.1 similar to what you did on #127? Thanks :-)

[darealshinji]

Try to build this as a shared library:
gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c

But I'd say if selinux is not available in all distros the AppImage should not include anything depending on it in the first place. The current kdenlive AppImage release is 16.12.2. Maybe it's no longer an issue there?

[probonopd]

It's an issue in the Subsurface AppImage and other ones built on Travis CI and many first-time AppImage users have been complaining (because Subsurface is linked as an example on the AppImage homepage), so a thousand thanks for your hint. :+1

[darealshinji]

What happens if the libselinux.so.1 file from the build system will be bundled with the AppImage?

[probonopd]

That would also be an option, but adding to the size of the AppImage.

[darealshinji]

Well, it's only about 120k uncompressed...

[crapp]

What is the current state of this problem? i have a Qt application for what I wanted to create an AppImage using linuxdeployqt. I am using a centos7 based docker image to build the application and the AppImage. Unfortunately I ran in the same issue with libselinux on ArchLinux. Should I switch to a different build system (for example debian or ubuntu)?

[probonopd]

When you compile on Ubuntu, your binaries won't have a dependency on libselinux. Although I am almost sure there must be an easier way to achieve the same without switching the entire build operating system.

[probonopd]

Possibly removing libselinux-devel using yum before compiling could do the trick. May be worth a try.

[darealshinji]

Try to figure out with libraries have a dependency on libselinux and install them as non-selinux builds from another repository. That might help.

[crapp]

@probonopd I wasn't able to remove selinux without breaking the system. As this build system was docker based it wasn't that difficult to move to ubuntu:trusty. LinuxDeployQt works perfectly there and the generated AppImage seems to work on most distributions (have only checked a few myself). Thanks for bringing AppImage and linuxdeployqt to us!

[probonopd]

@crapp glad it is working for you; feel free to add your software to https://github.com/probonopd/AppImageKit/wiki/AppImages.

[phcerdan]

Hey, facing this in Archlinux, with an AppImage generated in a local docker, derived from ubuntu:xenial.

QT_DEBUG_PLUGINS=1 ./app-x86_64.AppImage

I got:

...
Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path "/home/phc/tmp/squashfs-root/usr/bin/platforms" ...
loaded library "/home/phc/tmp/squashfs-root/usr/plugins/platforms/libqxcb.so"
QLibraryPrivate::loadPlugin failed on "/home/phc/tmp/squashfs-root/usr/plugins/platforms/libqxcb.so" : "Cannot load library /home/phc/tmp/squashfs-root/usr/plugins/platforms/libqxcb.so: (libselinux.so.1: cannot open shared object file: No such file or directory)"
This application failed to start because it could not find or load the Qt platform plugin "xcb".
Available platform plugins are: xcb.

Reinstalling the application may fix this problem.

My work in progress Dockerfile is here: https://github.com/phcerdan/FFT-from-image-compute-radial-intensity/blob/master/extra/Docker/xenial_linuxdeployqt/Dockerfile

[phcerdan]

What's the problem of bundling a libselinux.so, as @darealshinji suggested?

[darealshinji]

@phcerdan Good question. I don't know how much of an security issue it may be or if bundling it works at all (I don't know much about SELinux and what it's actually used for).

One option could be: use dlopen() to find out if libselinux.so.1 is available. If it's not, add the fake selinux library[1][2] to LD_LIBRARY_PATH

It makes me actually wonder why libselinux.so.1 isn't dlopen()ed in the first place, if applications can work without it.

[probonopd]

What's the problem of bundling a libselinux.so, as @darealshinji suggested?

Nothing, apart from it making the AppImage unneccessarily larger. Since we don't want or need its functionality, maybe we could replace it by a dummy library that resolves all of its symbols but just does nothing.

[probonopd]

Added it as an annoyance to the list of Desktop Linux Platform Issues https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues#selinux

[darealshinji]

The reason why libselinux.so.1 was blacklisted:

# sed: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory

So it depends on libpcre.so.3 which was blacklisted, but isn't anymore. I'd say libselinux.so.1 shouldn't be blacklisted anymore. Uncompressed filesize on Ubuntu is less than 200k.

[phcerdan]

Hi @probonopd,

Nothing, apart from it making the AppImage unnecessarily larger

How is this unnecessary? Isn't the aim of AppImage to generate binaries for all distros? For 200k increase, solving this issue sounds worthy, IMHO.

Not working on Arch and derivatives distros at the moment. I will try the workaround. Thanks.

[phcerdan]

Hey this workaround works in Arch:

create a fake library from this selinux_mock.c

extern int is_selinux_enabled(void)
{
  /* always return 0; this way we don't trigger any SELINUX calls */
  return 0;
}

And compile it in the folder /path with: gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c

Then execute your AppImage with:

LD_LIBRARY_PATH=/path:${LD_LIBRARY_PATH} ./MyApp.AppImage

[phcerdan]

For bundling the fake libselinux.so in docker, so Arch users can run it without any workaround:

# Generate a fake libselinux.so and bundle it in your app.
RUN echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c && \
    gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c && \
    rm selinux-mock.c && \
    mv libselinux.so.1 \
    ${APP_DIR}/usr/lib/

# Then run linuxdeployqt as usual:
RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -bundle-non-qt-libs
RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -appimage

Where ${APP_DIR}/usr/lib might change depending on the project structure.

[probonopd]

That's awesome indeed.

Maybe we could make linuxdeployqt and/or appimagetool do something like this:

echo 'H4sICGC8jlkAA2xpYnNlbGludXguc28uMQDtWF1sFFUUPrPdny7Q3dUoLi2RiQEtRieIYCpYQWph
QDBY2uiDdZx2p901+4Mzs9ASEhsRhRCSSuIDDySExESNMX0TwYfWmoLxwfqXEF8kKklRolUDKS+M         
986c0525dAIPJiamZzP7zTn3fPeee+/cmXPva+3bN0ckCUjq4Eng2kjM0zeiPXPHrAuztUCC/TfC                    
Etc3BuHyUCKIALL7z3lxXm8K60/JQYx49mwkyIsgrxl5zehPOIJdIaxHdhSv82gXcTkEMYq485Kd                    
4/cfxj1dxKUQROI9x3hxuH3JIHZge2HjMo3xEtLMcc5dwOcPYMuzXTB07kzfV8d2jh8cOvHFtbGr                    
J14f/T0NWN7AroXgzZsYYwJ9+LgtYFeSXYt85bydCPokoDaPh0aXSxDdlEz4OJvav79y9udj+zs+                                   
3X/qwqsvLP3k6J+p3779I3WrsahjNewWHio+vvIcvlKIXQ+xt4TYO9h13xz2Y8DnZjHImSDrXdd+                                   
DzQL9iq77mS9fwcHdiHaj6O/WE/G9b+5v4tdewOcFCdI0/pLlbJm2bppaxpohXLBBq2PAWhbO3do                                   
OcM0+guWbZidO9qKlbLRqfcUDa9s7hKtd0DnFejFwj6mbtujdaBfW1G3LMOCgqVZRrFQrg5oRpmT                                                     
clAs9PQqVkV5DDQjp9s6q6bHsrywmKnseiCJ+z0CW7Zv3dSmrVZWK2sDHYqwOQz+DkFtPVQbC0nu                                                     
c4bGC9cBreuXcXyygl0meyZoJ/1C2sM4eM8zyUWfvc5nn/LZoz77tM/un8IZn90/heqBK/XqkZix                                                     
QAb14Kgdm2pyjZ/Xj3vlzlqTFTkrbPafXraR3a1jd33DzoptLqpHY7s592hrD4MudeWMeviSemAm                                                     
tTfSPc4qjmLFf3U7Fzmf+T/u+a/2+Y/N1KmHP1PHft2gSpPq1zNVl3z3j0lO/oaR1cMTzk+cP9R6                                                                     
nRmh+oB6oPUcv+tifHuReqT1B6ZNGY7jTOXZX/dEbJIZpL/HOatPSS97A/vbejrBaPb9LLi9SS+4                                                                     
xi4WzylmZnU5k92Xn2cVpJcNcf/Lz7B73sZprrGo+Hjh8EhNdeuzOF+/3HCcNdyfub8I3ruPi7Sv                                                                     
A6SBjNS0KFE/LHnvc/7ueI/5u89UKrM5ld2WXri3fgg2NK5/8NHl7rLnPk+z6yCrz12zT6Uyb0ba                                                                     
GuKbWUUwL/MyL/MyL/Py/xbKp2Qh76R9xiFESuI/QKQ9AuWxDahT/roEdcrfmlCnb2sjIuVxS4Vy                                                                                   
yrlo33P1hlPh2ILJG+VeI5i0UfgDWL4A9QlEysuziLO5HuaHtF0diQbjGEVMCnyWXrjxDKO/gzqN                                                                                   
2zTqe7D8Our+HPO/ENo3i0J58pa2tnVy866uXe3ydp7Lr5TXKC08g1esvGWbtt4DSrliG0p/uar0                                                                                   
VAvF3MOFHLhaXrfyoOQGy9ZgyUPb9Er2GKZVqJQDisbKTKOoc0dQ3F2NsrtoK/0VdmMbA+zf3eQo                                                                                   
Rl7rM/WSoeVzZk3zKJpumvqg50n3r/Sabut6qdALvDpeLbPwTYvC9iyg9FZKJaNs/yvjyZ8r/uzQ                                                                                                  
niLsnIEkKug8GY35+OJ+XxV44vq4l13X2LNFfFofhE+E8EmasQ/Ep/VD2IJxUIyz+yrEVeA908Sn                                                                                                  
9UhI649EEnS+P3d88dN6IaT3BMUfEbAdvLVIOq1HQhlq8Utwc/87oXbG4cYdDeKo0L7Y/5egdibC                                                                                                  
hd6HhBQ/iTj/ZwX+cCyIGcE/I2BO4J+MBVHki/0vCXw6ByScDmmfxBLbjwcxKfiL/R9EPo1/2Hlb                                                                                                  
GP8tgX8+HsSc4C/2/23wvm30Xq6dv83tL+on2JX28el7lr1N/vsYP/Fl5Mu3yf8IgmcXtfNRTx/x                                                                                                  
rV8/n+YxL7RP5yQX0lhfSPuEHwt8+p5SA7ROwvijAp++Q9lM0E/kk0ygbXb8kC+H8MX3z5doWyXY                                                                                                           
5ZD4pTlwrm96C/K/u0X7/wDlRnoKkBcAAA==' | base64 -d - | gunzip > libselinux.so.1

This was made by

echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c
gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c 
strip libselinux.so.1
ls -l selinux-mock.c 
gzip libselinux.so.1
base64 libselinux.so.1.gz

How is this unnecessary? Isn't the aim of AppImage to generate binaries for all distros? For 200k increase, solving this issue sounds worthy, IMHO.

You have just delivered the proof that it is unneccessary to ship the full library, haven't you? Now, could the mock be made a bit more clever, and "route through" (e.g., using dlopen()) the original library if it is installed on the target system? After all, I assume it does something on systems with SELinux enabled.

[phcerdan]

That's great!

You have just delivered the proof that it is unneccessary to ship the full library, haven't you?

Well, yes, but if bundling a small library solves all these workarounds... . What's the matter with 200k? Maybe it doesn't work at all to bundle the library, and this fake is a good solution, with selinux enabled or disabled.

After all, I assume it does something on systems with SELinux enabled.

Good point indeed, does it do something? selinux archwiki. I have no idea about selinux, how secure is it to execute a binary from a 3rd party for selinux to matter though?

[probonopd]

The question is, will an AppImage that contains the mock library run on a system that has SELinux in "enforcing" mode at all.

[phcerdan]

I have no way to access such a SElinux system, but I would love to find out.

[probonopd]

The easiest way to find out would probably be to run a Fedora Live ISO.

According to https://fedoraproject.org/wiki/FedoraLiveCD, it

Uses SELinux in enforcing mode and other security features by default.

(It is the first thing I always disable when running Fedora...)

[phcerdan]

Cool, will test it in a VM.

[Conan-Kudo]

This is completely idiotic. Both major LSMs (AppArmor and SELinux) have userspace libraries that applications link into. If your library chain includes libselinux.so.1 or libapparmor.so.1, then just pull it in. It does literally nothing if there's no SELinux/AppArmor available, and will provide security enhancements if there is.

As far as I know, the only dependency of both libraries is libpcre and glibc.

[probonopd]

Sorry for being ignorant here, but in order for the security to work, AppArmor and SELinux require the "suspect" application to "cooperate" by linking to these libraries? Don't think this provides any real security then, since the AppImage could ship some random fake "AppArmor" or "SELinux" library. If that is true, then the best advice would be to disable AppArmor and SELinux when building, and if this is not possible (e.g., because the source code is not available), then ship a dummy library.

I might be wrong though. If so, please correct me.

[Conan-Kudo]

@probonopd The AppArmor and SELinux libraries are basically programmer's interfaces to kernel ioctls and common utils functions. They don't do much and the real meat is still in the kernel itself. That's why the soversion of the libraries hasn't changed in almost a decade.

[probonopd]

Which means that the security of AppArmor and SELinux works regardless of wheter the application links the corresponding libraries, do I understand you right @Conan-Kudo?

[Conan-Kudo]

@probonopd Yep. Lots of things are confined without userspace level integration. The userspace integration just lets the library/app itself do cool things and be smarter.

[ShalokShalom]

And how to get it working on distros without those libs?

[Conan-Kudo]

Just bundle the libraries and leave it be. They don't hurt anything.

[darealshinji]

Yes, please! Otherwise AppImages are likely to not run on distros like Arch.

--- a/excludelist
+++ b/excludelist
@@ -79,16 +79,6 @@
 # Workaround for:
 # Application stalls when loading fonts during application launch; e.g., KiCad on ubuntu-mate
 
-libselinux.so.1
-# Workaround for:
-# sed: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory
-# Some distributions, such as Arch Linux, do not come with libselinux.so.1 by default.
-# The solution is to bundle a dummy mock library:
-# echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c
-# gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c 
-# strip libselinux.so.1
-# More information: https://github.com/AppImage/AppImages/issues/83
-
 # The following are assumed to be part of the base system
 # Removing these has worked e.g., for Krita. Feel free to report if
 # you think that some of these should go into AppImages and why.

[probonopd]

@darealshinji with this workaround, they will work

[Conan-Kudo]

@probonopd

The problem is that "not by default" doesn't mean it might not be there and useful. The Arch/Gentoo Hardened projects offers SELinux enablement.

Debian and SUSE both offers SELinux and AppArmor support and policies.

Red Hat/Fedora, of course, offers SELinux and Ubuntu offers AppArmor.

The dummy libraries means that applications can't detect when such things are active and automatically use them properly, which defeats the point of making applications that can secure themselves.

[darealshinji]

# Workaround for:
# sed: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory

This "workaround" is obsolete, since libpcre.so.3 is now bundled by default, as not all distros provide it themselves. Therefor there's no point IMO to exclude libselinux.

[phcerdan]

Please bundle the proper libselinux and solve all this for 200K. Hijacking the name of a library with a mock seems... not good. Or at least provide an option (on by default) to do it.

[probonopd]

Can you explain to me what that library does for your application @phcerdan?

[phcerdan]

@probonopd it is beyond the scope of my application. It is a dependency imposed by bundling my app in a SElinux system. But in short, it allows my application to run on all linux distros.

It does nothing in systems without SELinux, as people that know way more than I have stated in this conversation but allow people in SELinux systems to use their SELinux policy with the app. I think is super important to worry about privacy, and NSA, as you do, but libselinux is opensource and already present in a lot of systems for appimage to "guard/watch" about it.

[probonopd]

Again the question, do you think your application will run less secure when this library is replaced with a stub? My point is, we don't even know what it does...

[phcerdan]

Some people do know and choose to use it. I think it is beyond the scope of appimage to impose that decision.

And we should define secure, I guess you can package a super vital app with appimage and then use SELinux to enforce a policy for its usage, or whatever it does.

[darealshinji]

Please bundle it by default. AppImage distributors should decide whether they want to replace any of their libs with stubs or not. libselinux.so.1 is not available on all distros, small and portable between distros (unlike i.e. glibc). So there's no point to exclude it by default.

[probonopd]

AppImage distributors should decide whether they want to replace any of their libs with stubs or not.

I agree with that.

But for the AppImages that I make, I don't want to include NSA-originated software that I do not understand and that has no apparent use to me. This is not to say that AppImages that others make should necessarily follow the same logic.

[darealshinji]

But for the AppImages that I make, I don't want to include NSA-originated software that I do not understand and that has no apparent use to me. This is not to say that AppImages that others make should necessarily follow the same logic.

That's fine. But in this case I think you should still remove libselinux.so.1 from the excludelist as most people who build AppImages will use the same list and usually "blindly" accept it (i.e. resulting in Subsurface being incompatible with Arch).

[probonopd]

True! Doing it now.

[ShalokShalom]

@TheAssassin

there's literally no usable free GFX drivers

While there are often zero open source alternatives available for some device classes like hard drives and motherboards, is wonderful support for graphics available by AMD and Intel provides at least a bare minimum, which is enough for most users. 😃

[yelili422]

为了在docker中捆绑伪libselinux.so，Arch用户可以在没有任何解决方法的情况下运行它：

# Generate a fake libselinux.so and bundle it in your app.
RUN echo "extern int is_selinux_enabled(void){return 0;}" >> selinux-mock.c && \
    gcc -s -shared -o libselinux.so.1 -Wl,-soname,libselinux.so.1 selinux-mock.c && \
    rm selinux-mock.c && \
    mv libselinux.so.1 \
    ${APP_DIR}/usr/lib/

# Then run linuxdeployqt as usual:
RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -bundle-non-qt-libs
RUN ./squashfs-root/AppRun .${APP_DIR}/usr/share/applications/*.desktop -appimage

哪里${APP_DIR}/usr/lib可能会根据项目结构而改变。

Thanks for solved the problem of install seafile😃