LWN: Comments on "Systemd v239 released"

Systemd v239 released

k8to — Mon, 02 Jul 2018 20:11:04 +0000

Maybe enough for nginx. There are some programs which close and re-open their ports in some cases where the capability would be useful.

Systemd v239 released

Cyberax — Fri, 29 Jun 2018 18:30:19 +0000

Have you actually checked it? The PID1 code is clearly segregated from other tools.

Systemd v239 released

kloczek — Fri, 29 Jun 2018 13:05:23 +0000

Systemd has separated process which is storing logs in compressed logs.
systemd source code is so crappy that there is no proper separations between PID 1 process and other processes functionalities.

Systemd v239 released

cortana — Thu, 28 Jun 2018 09:20:45 +0000

You're quite right, thanks for ponting me in the right direction. I guess things would be a little cleaner if the sd-journal(3) functionality for reading the journal would be split into a separate library--that way libsystemd clients, most of whom would only ever want to write to the joural, wouldn't need those libraries being pulled in. But does this make any practical difference on a non-embedded system? I don't think so.

Systemd v239 released

smurf — Thu, 28 Jun 2018 07:47:05 +0000

Ideally it would get these ports passed in from systemd, thus would not need any privileges at all.

Systemd v239 released

excors — Wed, 27 Jun 2018 11:32:34 +0000

If I'm reading the build scripts correctly, libshared statically links libjournal_client, using "link_whole" so that all symbols (even unused ones) are included, because libshared intentionally wants to export the journal API (because it's commonly used functionality). The journal is what uses liblz4/liblzma.

Systemd v239 released

excors — Wed, 27 Jun 2018 11:15:32 +0000

What's wrong with using multiple compression libraries? Different compression algorithms have different tradeoffs of performance vs compression ratio, so they are useful in different situations. And sometimes they're just needed for compatibility with files or protocols that made different algorithm choices.

In systemd it looks like they compress the journal and coredumps with LZ4 if built with --enable-lz4, or fall back to XZ(/LZMA) if --enable-xz, or fall back to uncompressed. If both are enabled then both are supported for compatibility with reading old data files.

When looking at indirect dependencies, it's not surprising that the authors of library A might choose to use library B that implements feature C, while the authors of D might choose E that implements the same C. Then F comes along and wants to use both A and D, and they end up with two libraries that both implement C. Unless you want to forbid either competition between libraries or code reuse, that situation will continue to occur.

Systemd v239 released

cortana — Wed, 27 Jun 2018 10:54:41 +0000

All those libraries are in process address space.

Oh, no, how terrible.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0 242272  8952 ?        Ss   Jun19   1:12 /lib/systemd/systemd --system --deserialize 16

Anyway, I don't see anything in src/shared referring to any symbols from liblzma or liblz4, so perhaps they are pulled in at build time? These things can slip in unless you (and all your transitive dependencies) take care to link using --as-needed...

Systemd v239 released

kloczek — Wed, 27 Jun 2018 08:28:43 +0000

Bollocks.
All those libraries are in process address space.
Does't matter that some of those libraries are used not straight by PID 1 but by libraries linked with systemd.

$ objdump -x /usr/lib/systemd/systemd| grep NEEDED
NEEDED libsystemd-shared-239.so
NEEDED librt.so.1
NEEDED libseccomp.so.2
NEEDED libselinux.so.1
NEEDED libmount.so.1
NEEDED libpam.so.0
NEEDED libaudit.so.1
NEEDED libkmod.so.2
NEEDED libgcc_s.so.1
NEEDED libpthread.so.0
NEEDED libc.so.6

$ objdump -x /usr/lib/systemd/libsystemd-shared-239.so| grep NEEDED
NEEDED librt.so.1
NEEDED libcap.so.2
NEEDED libacl.so.1
NEEDED libcryptsetup.so.12
NEEDED libgcrypt.so.20
NEEDED libip4tc.so.0
NEEDED libseccomp.so.2
NEEDED libselinux.so.1
NEEDED libidn2.so.0
NEEDED liblzma.so.5
NEEDED liblz4.so.1
NEEDED libblkid.so.1
NEEDED libmount.so.1
NEEDED libgcc_s.so.1
NEEDED libpthread.so.0
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2

As you see for example libsystemd-sharedstraight used more than one compression library.

Systemd v239 released

josh — Tue, 26 Jun 2018 23:54:03 +0000

Fun. Another approach (also using /tmp/chmod for the same reason):

/tmp$ cp -a /bin/ls fixed-chmod
/tmp$ cat chmod > fixed-chmod
/tmp$ ls -l fixed-chmod
-rwxr-xr-x 1 josh josh 60224 Jun 26 16:52 fixed-chmod
/tmp$ ./fixed-chmod +x chmod

Systemd v239 released

zlynx — Tue, 26 Jun 2018 22:57:15 +0000

/lib64/ld-linux-x86-64.so.2 /tmp/chmod

/tmp/chmod because I didn't want to actually chmod -x /bin/chmod. Heh.

Systemd v239 released

rahvin — Tue, 26 Jun 2018 20:20:16 +0000

His point is once the government has the ability to hit you with the iron pipe to force your compliance your only privacy is how much work it is for them to hit you with the iron pipe. Or in other words....

Your entire argument is based on the idea that you have privacy because it's too much bother to record everything and that if the companies force their hand they'll insist on that forced decoding so they can record everything. But you don't have privacy in the first case either, it's clear the government already has the power, just that you aren't interesting enough for them to use it, but other people are. That's not actually a protection on your privacy, hopefully you realize that.

The root cert that can decode all traffic has significant issues and isn't the catch all you present it as. There are significant risks with such a system, if ever implemented, because you've put a single point of failure on the entire economy and privacy of the nation. That singe cert can spy on your entire nation, it's loss would be catastrophic and protecting it would be extremely difficult.

Systemd v239 released

judas_iscariote — Tue, 26 Jun 2018 14:00:16 +0000

The way you are determining the libraries needed by PID1 is incorrect, you need to look at the ELF DT_NEEDED entries, otherwise your conclusions will be garbage. other libraries are not used by systemd but are indirect dependencies, in such case you may direct your badly thought out questions to the relevant project.

readelf --dynamic /usr/lib/systemd/systemd | grep NEEDED

Systemd v239 released

kloczek — Tue, 26 Jun 2018 11:58:41 +0000

The problems are:
1) that this list to long
2) there are several duplications functional duplicates
3) mounting and unmounting is so unique operation that putting such operations straight into PID 1 is idiotic

ad 2) For example in libc provides regular expression functions and for not so sophisticated regexps SELinux libraries choosed pcre.
Everything is linked with THREE compression libraries!!!
UTF operations are in libc and despite of this libunistring is used.
Why modules operations must be straight in PID 1? (libkmod)
Why init must be responsible for authentication? (libpam, libargon).
ACL and ext attrs?
JSON operations?
What is doing here network monitoring and network traffic dumping library? (libpcap)
What PID 1 is calculating so important that it must use FPU libm functions?

Systemd v239 released

excors — Tue, 26 Jun 2018 11:30:33 +0000

If their current implementation of censorship is so lacklustre and easily bypassed, that suggests either the government is incompetent, or under-resourced, or simply isn't aiming for comprehensive censorship. (I imagine you don't need to prevent 100% of people from hearing about some dangerous idea, if blocking 95% is sufficient to prevent that idea from snowballing and becoming a serious threat to the government. And trying to shut down the other 5% might cause significant economic harm by unintentionally blocking legitimate traffic, so they can't just implement a whitelist approach and block any traffic they don't understand.)

When technology becomes more secure, those conditions will stay the same. If the government is incompetent or under-resourced then they won't be able to keep up, and the security will be successful. If they do have the competence and resources, they'll come up with the simplest solution that works 95% of the time and can still be trivially bypassed by the 5% - just use a non-default DNS-over-TLS server, or a non-default protocol (like legacy DNS-over-UDP), or a VPN, or develop new protocols that tunnel properly-encrypted data inside the decryptable-by-government traffic (DNS-over-TLS-over-DNS-over-TLS), or whatever, because software is endlessly flexible and will always be able to bypass blacklists. You wouldn't be any worse off than you are now.

If you're in the 5%, you're only in danger if the government decides they want to change the conditions and oppress you more, and that's a political problem rather than a technological one.

Systemd v239 released

ibukanov — Tue, 26 Jun 2018 09:36:57 +0000

In quite a few cases an executable with setcap can be replaced by ambient capabilities. For example, on my system nginx runs as a user with no capabilities set on the executable yet it can listen on 80/443 ports due to ambient CAP_NET_BIND_SERVICE granted to it by systemd. This way an arbitrary instance of nginx cannot listen to privileged ports.

Systemd v239 released

lkundrak — Tue, 26 Jun 2018 07:35:20 +0000

Ah, in that case the whole library is versioned and you could just copy it next to the old one?

Systemd v239 released

kloczek — Mon, 25 Jun 2018 22:44:15 +0000

# awk '/\/usr/ {print $6}' /proc/1/smaps | sort | uniq
/usr/lib64/gconv/gconv-modules.cache
/usr/lib64/ld-2.27.9000.so
/usr/lib64/libacl.so.1.1.0
/usr/lib64/libargon2.so.0
/usr/lib64/libattr.so.1.1.0
/usr/lib64/libaudit.so.1.0.0
/usr/lib64/libblkid.so.1.1.0
/usr/lib64/libc-2.27.9000.so
/usr/lib64/libcap-ng.so.0.0.0
/usr/lib64/libcap.so.2.25
/usr/lib64/libcryptsetup.so.12.3.0
/usr/lib64/libdevmapper.so.1.02
/usr/lib64/libdl-2.27.9000.so
/usr/lib64/libgcc_s-8-20180502.so.1
/usr/lib64/libgcrypt.so.20.2.3
/usr/lib64/libgpg-error.so.0.24.2
/usr/lib64/libidn2.so.0.3.4
/usr/lib64/libip4tc.so.0.1.0
/usr/lib64/libjson-c.so.4.0.0
/usr/lib64/libkmod.so.2.3.3
/usr/lib64/liblz4.so.1.8.2
/usr/lib64/liblzma.so.5.2.4
/usr/lib64/libm-2.27.9000.so
/usr/lib64/libmount.so.1.1.0
/usr/lib64/libpam.so.0.84.2
/usr/lib64/libpcap.so.1.8.1
/usr/lib64/libpcre2-8.so.0.7.0
/usr/lib64/libpthread-2.27.9000.so
/usr/lib64/librt-2.27.9000.so
/usr/lib64/libseccomp.so.2.3.3
/usr/lib64/libselinux.so.1
/usr/lib64/libsepol.so.1
/usr/lib64/libudev.so.1.6.11
/usr/lib64/libunistring.so.2.1.0
/usr/lib64/libuuid.so.1.3.0
/usr/lib64/libz.so.1.2.11
/usr/lib/locale/locale-archive
/usr/lib/systemd/libsystemd-shared-239.so
/usr/lib/systemd/systemd

Systemd v239 released

comio — Mon, 25 Jun 2018 20:39:12 +0000

Very clear, thanks.

Ciao

Systemd v239 released

ibukanov — Mon, 25 Jun 2018 19:28:34 +0000

This is not necessary so. It is costly to decrypt all the traffic. So if a government can get what it needs just from meta-information, it will not bother with the information itself, so the current status-quo of open meta and encrypted content may continue for quite some time. Encrypting meta may trigger drastic backlash.

Systemd v239 released

ebiederm — Mon, 25 Jun 2018 19:04:47 +0000

Note this also affects setcap executables as well. So one of the recent trends to get away from setuid executables by replacing them with setcap executables instead will also stop functioning.

Systemd v239 released

josh — Mon, 25 Jun 2018 18:53:32 +0000

Here's a sample:

$ cat nnp.c 
#include <err.h>
#include <sys/prctl.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    if (argc < 2)
        errx(1, "Usage: nnp prog [args]");

    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) < 0)
        err(1, "prctl");

    execvp(argv[1], argv+1);
    err(1, "execvp");
}
$ gcc nnp.c -o nnp
$ cp -a /usr/bin/id id
$ sudo chown root:root id
$ sudo chmod u+s id
$ ./id -un
root
$ ./nnp ./id -un
josh
$ ./nnp bash
$ ./id -un
josh
$ sudo id
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Systemd v239 released

rgmoore — Mon, 25 Jun 2018 18:49:41 +0000

So the current push by Goggle and Facebook to encrypt all meta-information may be helpful to improve privacy in the short term at the cost of total lack of privacy in the longer term.

If the government has the power to force everyone to use the drastic measures you discuss, any measure of privacy was going to go away soon anyway.

Systemd v239 released

josh — Mon, 25 Jun 2018 18:42:45 +0000

Quoting "man prctl":

PR_SET_NO_NEW_PRIVS (since Linux 3.5)

Set the calling thread's no_new_privs bit to the value in arg2. With no_new_privs set to 1, execve(2) promises not to grant privileges to do anything that could not have been done without the execve(2) call (for example, rendering the set-user-ID and set-group-ID mode bits, and file capabilities non-functional). Once set, this bit cannot be unset. The setting of this bit is inherited by children created by fork(2) and clone(2), and preserved across execve(2).

Systemd v239 released

ibukanov — Mon, 25 Jun 2018 18:11:57 +0000

Consider the current situation in Russia. The censorship block there is implemented either via IP addresses or via DNS. Since most sites are banned only by DNS resolvers at local ISPs a trivial way to circumvent that at least until recently was to use DNS resolvers outside of Russia. Yet the government has not bothered to close even this trivial hole as the block worked against the majority of population and it was enough for the government.

The moment the blocking will need to decrypt TLS sessions for most people, they will consider more drastic measures like requiring to filter based on SNI header or, when that will be encrypted according to various proposals, by requiring to install government certificates on all devices.

So the current push by Goggle and Facebook to encrypt all meta-information may be helpful to improve privacy in the short term at the cost of total lack of privacy in the longer term.

Systemd v239 released

excors — Mon, 25 Jun 2018 16:37:50 +0000

Why is DNS-over-TLS relevant in that situation? It seems like ISPs and authoritarian governments could do (and do) exactly the same things with traditional DNS, but much more easily.

Systemd v239 released

ibukanov — Mon, 25 Jun 2018 16:30:02 +0000

I am not talking about ISP doing that without user consent. Rather they can explicitly offer a discount if a user opts in. This will be like a post-office offering a discount if the receiver is OK with letters stuffed with adds.

Systemd v239 released

dbe — Mon, 25 Jun 2018 16:24:48 +0000

So about the no-new-privileges... how does that work? When a setuid binary is execd it’s immediately in its new UID... right? Maybe that’s not the case?

Systemd v239 released

admalledd — Mon, 25 Jun 2018 15:28:06 +0000

I await for it to be added to the "dirty tricks professors use on trick question tests" such as the combo:

chmod -x /bin/chmod
chattr +i /bin/chmod

Systemd v239 released

Wol — Mon, 25 Jun 2018 15:07:37 +0000

> And even with not so authoritarian countries ISP may offer discounts if a user install such certificates so ISP can inject ads into any TLS traffic.

Until somebody signs up for this and a safety-critical system falls over ... THIS REALLY HAPPENED!

Ages ago (sorry can't remember details :-) some router manufacturer thought it would be a good idea to stick ads in http traffic passing through. Until someone installed one of these routers in an environment that ran "control traffic over http". Obviously, the system started misbehaving and it came out that this is what was happening. The router was very rapidly patched to remove this behaviour.

The post office is not allowed to interfere with mail (unless they believe the law is being broken). ISPs should not interfere with traffic going over their network! Either they are common carriers, with no liability other than passing traffic through, or they take editorial control AND LIABILITY, which means they have to pay for their cock-ups!

Cheers,
Wol

Systemd v239 released

ibukanov — Mon, 25 Jun 2018 13:50:29 +0000

It depends on a longer-term effects. With authoritarian governments it may push to require that all devices has government-issues certificates that can fake any domain. And even with not so authoritarian countries ISP may offer discounts if a user install such certificates so ISP can inject ads into any TLS traffic.

Systemd v239 released

mbiebl — Mon, 25 Jun 2018 13:16:37 +0000

I think you meant libsystemd-shared, not libsystemd.
systemd-networkd does not link against libsystemd.

$ objdump -x /lib/systemd/systemd-networkd | grep NEEDED
NEEDED libc.so.6
NEEDED libsystemd-shared-239.so
NEEDED librt.so.1
NEEDED libcap.so.2
NEEDED libip4tc.so.0
NEEDED libselinux.so.1
NEEDED libidn.so.11
NEEDED libmount.so.1
NEEDED libpthread.so.0
NEEDED ld-linux-x86-64.so

Systemd v239 released

lkundrak — Mon, 25 Jun 2018 05:50:57 +0000

The symbols seem versioned. Presumably you could just drop in the new libsystemd along with the new resolved?

Systemd v239 released

Cyberax — Mon, 25 Jun 2018 04:04:56 +0000

Can you compile it statically?

Systemd v239 released

scientes — Mon, 25 Jun 2018 02:44:13 +0000

I wish it was possible to turn off the libsystemd-shared. That would make it easy to drop in systemd-resolvd 239 on a older systemd system.

Systemd v239 released

scientes — Mon, 25 Jun 2018 02:42:37 +0000

I am most excited to see DNS-over-TLS. This helps alot with privacy.

Systemd v239 released

josh — Mon, 25 Jun 2018 01:43:54 +0000

I've been looking forward to the idea of system-wide NO_NEW_PRIVS for a long time. I look forward to seeing the corresponding changes in other parts of the ecosystem to make that possible.