I am trying to build a software stack compiling almost everything from source down to compilers, build tools etc.
In my dependency tree glib shows up in a pretty early stage (no GTK available yet). I don’t use meson, so I try to build the latest releases that can still be built with autotools (2.58.2 and 2.58.3). The build always fails with
482 automake: error: cannot open < gtk-doc.make: No such file or directory
483 autoreconf: error: automake failed with exit status: 1
Since GTK depends on glib I cannot build GTK before having built glib. I am not interested in building the documentation, as I really just want to build glib itself. How can I disable all the gtk-doc stuff such that the build does not always fail?
This is blocking me since more than two weeks from installing other packages that depend on glib.
I tried repackaging the source tarball, removing the docs directory and all references to “docs”. This already helped, but now the build is failing due to meson related stuff, even though I use autotools for building.
…/meson.build:1812:2: ERROR: Dependency “libselinux” not found, tried pkgconfig
What’s wrong with using just autotools? Autotools works like a charm since forever and does not require a python installation like meson.
Building glib from source used to be a no-brainer taking only 2-3 minutes. Now it is becoming a real pain (like many other software projects trying to adapt exotic build systems) to install glib
You can expect that to be a lot of work. Is there any chance of reusing some pre-existing software stack for your needs, like Yocto?
That aside, the only supported versions of GLib are 2.68 and the unstable 2.69 series. GLib 2.58 is no longer supported by upstream and contains security vulnerabilities. It would be irresponsible to build anything around it at this point. Some distributions may still support it, but you’d need to pull in their security patches and base your build off what they have, not the upstream tarball.
I can’t remember the autotools setup for GLib, but iirc this error occurs because gtk-doc’s dev package is not installed.
You may also need to run autogen.sh or something like that. iirc it runs gtkdocize which copies in gtk-doc.make.
I’d be shocked if you could build a full Linux stack without using Python. Using it as a dependency of Meson is largely uncontroversial. autotools, as you are finding out, is a complete pain to use as an end user, and a pain to maintain software in as a maintainer. One symptom of this is that it produces cryptic error messages which require a lot of built-up experience to diagnose, or digging through 3 layers of generated shell code to debug in the first instance.
The build is already failing in the autoreconf step ( automake: error: cannot open < gtk-doc.make: No such file or directory) before configure is even created
GLib is used by a number of components which separate different security domains. For example, it’s used by some D-Bus system and user services which have to handle untrusted clients; it’s used by flatpak which has to handle sandboxed applications and separate them from the rest of the system; it’s used in various network-facing applications and services which have to be robust against malicious input from the network.
Unless your security model is that all the data and code you are building can be compromised and then thrown away, or that the system you’re building will never be exposed to untrusted input, you should be using up-to-date software.
GLib 2.58 also contains a number of other bugs (not security bugs) which are not going to be fixed. My take is that if you feel the need to build an entire stack, you might as well build the latest supported stable versions of things.
Also note that you will get no upstream support for bugs you encounter in GLib 2.58. It’s a bit of a stretch asking for support for building it — maintenance is done by volunteers. Please, use the latest version.
I try to fully separate the software stack from the Operating system running on the servers (in the best case only relying on libc). Therefore stuff that is run by users should never get in touch with any part of the operating system apart from libc. This particular glib installation will only be used by other software compiled from source in user space, running in user space. This separation resolves many problems.
But I get your point. I will try to get along with meson
There are a lot of privilege boundaries which are not the kernel/user-space boundary in a modern Linux system, and I hope you have considered them. However, I am not here to analyse your security model and you haven’t asked me to, so I’ll stop here.
Please say if you have questions about how to build GLib 2.68 with Meson and people here will be happy to help.
There are a lot of privilege boundaries which are not the kernel/user-space boundary in a modern Linux system, and I hope you have considered them. However, I am not here to analyse your security model and you haven’t asked me to, so I’ll stop here.
Now I am getting curious about this. Can you please name one example? The only way that I am aware of for privilege escalation purely happening in user space are rowhammer attacks, where attackers flip bits in the memory.
User process A sends crafted malicious data to a process B running as another user (for example, a system service running as root), which hits a bug in process B (typically an out-of-bounds read on an array). With a bit of crafting, the malicious data can sometimes be written such that it can cause process B to execute attacker-provided code (as part of the payload), or other arbitrary code already loaded into the process which could be used to gain further privileges.
Essentially, in the general case, any interface where two processes with different privileges (either running as different users, or sandboxed differently, or with different capabilities as per setcap()) interact, is a security boundary which needs to not be exploitable.
Here is a recent example of a privilege escalation bug which is entirely in userspace, but can be used to get the attacker root privileges. It uses a timing attack rather than a malicious payload, but is a good example of the kind of bug which is routinely fixed in newer versions of software and not in unsupported versions.
If such an attack is based on a software package installed in user space, then how would updating that software package (in user space) prevent the attack, as every user on the system could just compile the old version of that package in the home direcory and exploit it the same way?
I think that these kind of attacks can only be prevented by keeping the OS up to date (preventing system services from being vulnerable to such attacks).
Yes, you’re correct; it’s the code which is used by the system service which needs to be kept up to date; in other words, code on the more privileged side of the privilege boundary.
I’m wondering if you’re using a different definition of ‘user space’ to me. The definition I’m using is “anything that’s not the kernel”; are you defining it to be “anything that’s running as a non-privileged user”? Traditionally, system services are understood to be running in user space (not kernel space), even though they run with higher privileges than, say, a user’s graphical text editor.
You are of course right with your definition of user space and I was using the term wrongly. I should maybe rather say non-system space than user space for all installations that live outside of the OS.
On our systems we have sysadmins taking care that the system is always up to date. I am then in charge for setting up a software stack in non-system locations that should depend only minimally on libraries provided by the operating system (in an ideal world that would only be libc). Therefore I mentioned that having an older version of glib living outside of the operating system in non-system locations should not cause the security to be lowered.
I could manage to make the package manager that I am using to compile software from source code to work with meson and ninja and with these changes I could successfully install version 2.68.3 with GCC 4.8.5, 6.3.0, 8.2.0 and Intel 19.1.0.
The security of the user account running the vulnerable glib is lowered. You should assume that it is vulnerable to arbitrary remote code execution if you are not able to keep up with CVE response yourself.
Trying to avoid meson is really a bad idea. You’re going to be on glib 2.58 forever I guess. Whatever, good luck to you.
Please say if you have questions about how to build GLib 2.68 with Meson and people here will be happy to help.