[WIP] nspawn: Add --syscall-filter option #3

robertgzr · 2017-09-07T16:16:39Z

Adds a --syscall-filter option to modify nspawns default seccomp filter.
After the comments in systemd#5944 this now works similar to the SystemCallFilter=
option in unit files, but only accepts system calls.

This option takes a comma-separated list of system calls to add to the default filter.
If the first character of the list is "~", the listed system calls will be whitelisted
instead. I modify the blacklist before handling the --[drop-]capability option,
so anything there will overwrite this option.

Fixes systemd#5163

robertgzr · 2017-09-07T16:18:45Z

src/nspawn/nspawn-seccomp.c

+                r = seccomp_filter_set_add(blacklist, !whitelist, &(cap_filter_sets[i].set));
+                if (r < 0)
+                        log_debug_errno(r, "Failed to add capability to blacklist, ignoring: %m");
+                /* NULSTR_FOREACH(t, cap_filter_sets[i].set.value) { */


I wasn't sure if the custom filter should also whitelist syscalls from the capability filter sets. I'm not sure what the priorities are there.

One angle would be that we should allow to whitelist those syscalls so apps can get a proper EACCESS or whatever instead of the seccomp blocking behavior, whatever that is.

Other angle would be that if the user didn't want to keep certain capability, restricting the syscalls adds a bit more security in the case there's a bug in the capabilities implementation.

I think that if the user doesn't enable a capability but enables the syscalls it's their fault and they should be allowed to shoot themselves on the foot :)

TL;DR whitelisting is fine IMO

dongsupark · 2017-09-08T06:20:59Z

Nit: you should not write Signed-off-by in your commit message in systemd.

robertgzr · 2017-09-08T09:08:53Z

@dongsupark 👍

iaguis

Some comments.

iaguis · 2017-09-08T09:07:09Z

src/shared/seccomp-util.h


 int seccomp_filter_set_add(Set *s, bool b, const SyscallFilterSet *set);

+int seccomp_add_syscall_filter_set(scmp_filter_ctx seccomp, uint32_t default_action, const SyscallFilterSet *set, uint32_t action);


Why are we exporting this? Doesn't seem to be used outside of src/shared/seccomp-util.c

Leftover from the first PR. Removed.

iaguis · 2017-09-08T09:16:30Z

src/nspawn/nspawn-seccomp.c

+        "add_key\0"
+        "afs_syscall\0"
+        "bdflush\0"
+        "bpf\0"


This should be wrapped by

#ifdef __NR_bpf #endif

right?

iaguis · 2017-09-08T09:16:38Z

src/nspawn/nspawn-seccomp.c

+        "get_kernel_syms\0"
+        "getpmsg\0"
+        "gtty\0"
+        "kexec_file_load\0"


same ifdef thing

iaguis · 2017-09-08T09:40:16Z

src/nspawn/nspawn-seccomp.c

+                Set *syscall_filter,
+                bool whitelist
+                ) {
+


superfluous empty line

iaguis · 2017-09-08T09:47:34Z

src/nspawn/nspawn-seccomp.c

+                if (r < 0)
+                        log_debug_errno(r, "Failed to add capability to blacklist, ignoring: %m");
+                /* NULSTR_FOREACH(t, cap_filter_sets[i].set.value) { */
+                /*         if (syscall_filter && whitelist && set_contains(syscall_filter, t)) { */


Does this work for removing @ groups?

iaguis · 2017-09-08T10:00:45Z

src/nspawn/nspawn.c

+                                        return log_oom();
+
+                                if (invert)
+                                        /* Apply default filter and the ones listed */


isn't this the other way around? if invert we're whitelisting so we're excluding the syscalls listed from the filter

The comment was wrong 😛

I was going by this https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=
And there it acts as a whitelist by default and as a blacklist when you invert with ~

iaguis · 2017-09-08T10:15:31Z

src/nspawn/nspawn.c

+
+                                r = set_put(arg_syscall_filter, t);
+                                if (r == 0)
+                                        return 0;


why are we returning here? IIUC, when set_put() returns 0 it means the key already exists so we can just ignore and continue the loop

iaguis · 2017-09-08T10:34:40Z

src/nspawn/nspawn-seccomp.c

+                r = seccomp_filter_set_add(blacklist, !whitelist, &(cap_filter_sets[i].set));
+                if (r < 0)
+                        log_debug_errno(r, "Failed to add capability to blacklist, ignoring: %m");
+                /* NULSTR_FOREACH(t, cap_filter_sets[i].set.value) { */


One angle would be that we should allow to whitelist those syscalls so apps can get a proper EACCESS or whatever instead of the seccomp blocking behavior, whatever that is.

Other angle would be that if the user didn't want to keep certain capability, restricting the syscalls adds a bit more security in the case there's a bug in the capabilities implementation.

I think that if the user doesn't enable a capability but enables the syscalls it's their fault and they should be allowed to shoot themselves on the foot :)

TL;DR whitelisting is fine IMO

robertgzr · 2017-09-08T14:53:23Z

src/nspawn/nspawn-seccomp.c

+        if (r < 0)
+                return log_debug_errno(r, "Failed to add default filter to blacklist: %m");
+
+        /* Filter out syscalls by capabilities but retain the ones on the list */


@iaguis I add the "capability syscalls" to the blacklist first...

robertgzr · 2017-09-08T14:54:10Z

src/nspawn/nspawn-seccomp.c

+                char *t;
+
+                SET_FOREACH(t, syscall_filter, i) {
+                        if (t[0] == '@') {


... and it now supports filter sets

robertgzr · 2017-09-08T14:58:41Z

src/nspawn/nspawn-seccomp.c

-                { 0,              SCMP_SYS(add_key)             }, /* keyring is not namespaced */
-                { 0,              SCMP_SYS(afs_syscall)         }, /* obsolete syscall */
-                { 0,              SCMP_SYS(bdflush)             },
+static const SyscallFilterSet nspawn_default_blacklist = {


I would move this into here
https://github.com/kinvolk/systemd/blob/master/src/shared/seccomp-util.c#L270
and document it here
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=

This would make it much easier to find the reason for the bug we had originally.
Going to ask that in the PR.

Adds a --syscall-filter option to set custom system call filters. After the comments in systemd#5944 this now works similar to the `SystemCallFilter=` option in unit files. This option takes a comma-separated list of system calls to allow. If the first character of the list is "~", the listed system calls will be blocked instead. Filter sets beginning with '@' are also supported. This overwrites nspawn default blacklist and the `--[drop-]capability` options Fixes systemd#5163

In general we'd leak anything that was allocated in the first parsing of netdev, e.g. netdev name, host name, etc. Use normal netdev_unref to make sure everything is freed. --- command --- /home/zbyszek/src/systemd/build2/test-network --- stderr --- /etc/systemd/network/wg0.netdev:3: Failed to parse netdev kind, ignoring: wireguard /etc/systemd/network/wg0.netdev:5: Unknown section 'WireGuard'. Ignoring. /etc/systemd/network/wg0.netdev:9: Unknown section 'WireGuardPeer'. Ignoring. NetDev has no Kind configured in /etc/systemd/network/wg0.netdev. Ignoring /etc/systemd/network/br0.network:13: Unknown lvalue 'NetDev' in section 'Network' br0: netdev ready ================================================================= ==11666==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f3a314cf238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238) #1 0x7f3a30e71ad1 in free_and_strdup ../src/basic/string-util.c:870 #2 0x7f3a30d34fba in config_parse_ifname ../src/shared/conf-parser.c:981 #3 0x7f3a30d2f5b0 in next_assignment ../src/shared/conf-parser.c:155 #4 0x7f3a30d30303 in parse_line ../src/shared/conf-parser.c:273 #5 0x7f3a30d30dee in config_parse ../src/shared/conf-parser.c:390 #6 0x7f3a30d310a5 in config_parse_many_files ../src/shared/conf-parser.c:428 #7 0x7f3a30d3181c in config_parse_many ../src/shared/conf-parser.c:487 systemd#8 0x55b4200f9b00 in netdev_load_one ../src/network/netdev/netdev.c:634 systemd#9 0x55b4200fb562 in netdev_load ../src/network/netdev/netdev.c:778 systemd#10 0x55b4200c607a in manager_load_config ../src/network/networkd-manager.c:1299 systemd#11 0x55b4200818e0 in test_load_config ../src/network/test-network.c:128 systemd#12 0x55b42008343b in main ../src/network/test-network.c:254 systemd#13 0x7f3a305f8889 in __libc_start_main (/lib64/libc.so.6+0x20889) SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). -------

Previous code was using the basename(id->fragment_path) which returned incorrect result if the unit was an instance. For example, assuming that no instances of "template" have been created so far: $ systemctl enable template@1 Created symlink from /etc/systemd/system/multi-user.target.wants/[email protected] to /usr/lib/systemd/system/[email protected]. $ systemctl is-enabled [email protected] disabled $ systemctl status [email protected] ● [email protected] - openQA Worker #3 Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled) [...] Here the unit file states reported by "status" and "is-enabled" were different.

==14==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200055fa9c at pc 0x0000005458f1 bp 0x7ffc78940d90 sp 0x7ffc78940d88 READ of size 1 at 0x60200055fa9c thread T0 #0 0x5458f0 in dhcp6_option_parse_domainname /work/build/../../src/systemd/src/libsystemd-network/dhcp6-option.c:555:29 #1 0x54706e in dhcp6_lease_set_domains /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-lease.c:242:13 #2 0x53fce0 in client_parse_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:984:29 #3 0x53f3bc in client_receive_advertise /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1083:13 #4 0x53d57f in client_receive_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1182:21 #5 0x7f0f7159deee in source_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3042:21 #6 0x7f0f7159d431 in sd_event_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3455:21 #7 0x7f0f7159ea8d in sd_event_run /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3512:21 systemd#8 0x531f2b in fuzz_client /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:44:9 systemd#9 0x531bc1 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:53:9 systemd#10 0x57bec8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:570:15 systemd#11 0x579d67 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:479:3 systemd#12 0x57dc92 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:707:19 systemd#13 0x580ca6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:838:5 systemd#14 0x55e968 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6 systemd#15 0x551a1c in main /src/libfuzzer/FuzzerMain.cpp:20:10 systemd#16 0x7f0f701a082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) systemd#17 0x41e928 in _start (/out/fuzz-dhcp6-client+0x41e928)

==14==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020001c761a at pc 0x000000540abc bp 0x7ffd0caf2c50 sp 0x7ffd0caf2c48 READ of size 2 at 0x6020001c761a thread T0 #0 0x540abb in client_parse_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:849:73 #1 0x53f3bc in client_receive_advertise /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1083:13 #2 0x53d57f in client_receive_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1182:21 #3 0x7f71d8c3eeee in source_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3042:21 #4 0x7f71d8c3e431 in sd_event_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3455:21 #5 0x7f71d8c3fa8d in sd_event_run /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3512:21 #6 0x531f2b in fuzz_client /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:44:9 #7 0x531bc1 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:53:9 systemd#8 0x57bef8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:570:15 systemd#9 0x579d97 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:479:3 systemd#10 0x57dcc2 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:707:19 systemd#11 0x580cd6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:838:5 systemd#12 0x55e998 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6 systemd#13 0x551a4c in main /src/libfuzzer/FuzzerMain.cpp:20:10 systemd#14 0x7f71d784182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) systemd#15 0x41e928 in _start (/out/fuzz-dhcp6-client+0x41e928)

This is a follow-up to 8857fb9 that prevents the fuzzer from crashing with ``` ==220==ERROR: AddressSanitizer: ABRT on unknown address 0x0000000000dc (pc 0x7ff4953c8428 bp 0x7ffcf66ec290 sp 0x7ffcf66ec128 T0) SCARINESS: 10 (signal) #0 0x7ff4953c8427 in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35427) #1 0x7ff4953ca029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029) #2 0x7ff49666503a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:805:9 #3 0x7ff496614ecf in safe_close /work/build/../../src/systemd/src/basic/fd-util.c:66:17 #4 0x548806 in server_done /work/build/../../src/systemd/src/journal/journald-server.c:2064:9 #5 0x5349fa in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journald-kmsg.c:26:9 #6 0x592755 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15 #7 0x590627 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:480:3 systemd#8 0x594432 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:708:19 systemd#9 0x5973c6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:839:5 systemd#10 0x574541 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6 systemd#11 0x5675fc in main /src/libfuzzer/FuzzerMain.cpp:20:10 systemd#12 0x7ff4953b382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) systemd#13 0x420f58 in _start (/out/fuzz-journald-kmsg+0x420f58) ```

We would not send the property because we'd call sd_bus_get_current_message() which would return NULL. If there is no message, we cannot support /self or /auto, but things are still OK if a path with a session name is given. Traceback when the issue is triggered: #2 we'd call sd_bus_get_current_message() here, which would return NULL, and session_object_find() would immediately return 0. #3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0) at ../src/login/logind-session-dbus.c:620 #4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37 #5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110, prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163, names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088 #6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291 #7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active") at ../src/login/logind-session-dbus.c:730 systemd#8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249 systemd#9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361 systemd#10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395 systemd#11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0) at ../src/login/logind.c:588 systemd#12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828 systemd#13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241 systemd#14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3299 systemd#15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186 systemd#16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234 systemd#17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244 Fixes systemd#13437. Bug introduced in 3b92c08.

core: factor root_directory application out of apply_working_directory

Fixes: oss-fuzz#22208 ``` test/fuzz/fuzz-calendarspec/oss-fuzz-22208... ../src/shared/calendarspec.c:666:48: runtime error: signed integer overflow: 2147000000 + 1000000 cannot be represented in type 'int' #0 0x7f0b9f6cc56a in prepend_component ../src/shared/calendarspec.c:666 #1 0x7f0b9f6cd03a in parse_chain ../src/shared/calendarspec.c:718 #2 0x7f0b9f6cea1c in parse_calendar_time ../src/shared/calendarspec.c:845 #3 0x7f0b9f6d1397 in calendar_spec_from_string ../src/shared/calendarspec.c:1084 #4 0x401570 in LLVMFuzzerTestOneInput ../src/fuzz/fuzz-calendarspec.c:17 #5 0x401ae0 in main ../src/fuzz/fuzz-main.c:39 #6 0x7f0b9e31b1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #7 0x40122d in _start (/home/fsumsal/repos/systemd/build/fuzz-calendarspec+0x40122d) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/calendarspec.c:666:48 in ``` (cherry picked from commit c07f18f)

We'd try to map a zero-byte buffer from a NULL pointer, which is undefined behaviour. src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60: runtime error: applying zero offset to null pointer #0 0x7f6ff064e691 in find_part /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60 #1 0x7f6ff0640788 in message_peek_body /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3283:16 #2 0x7f6ff064e8db in enter_struct_or_dict_entry /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3967:21 #3 0x7f6ff06444ac in bus_message_enter_struct /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4009:13 #4 0x7f6ff0641dde in sd_bus_message_enter_container /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4136:21 #5 0x7f6ff0619874 in sd_bus_message_dump /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-dump.c:178:29 #6 0x4293d9 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bus-message.c:39:9 #7 0x441986 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15 systemd#8 0x44121e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3 systemd#9 0x443164 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7 systemd#10 0x4434bc in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3 systemd#11 0x42d2bc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6 systemd#12 0x42978a in main /src/libfuzzer/FuzzerMain.cpp:19:10 systemd#13 0x7f6fef13c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) systemd#14 0x407808 in _start (out/fuzz-bus-message+0x407808) (cherry picked from commit b17af3e)

``` p11-kit-0.23.20-1.fc32.x86_64 pam-1.3.1-26.fc33.x86_64 xz-libs-5.2.5-1.fc33.x86_64 zlib-1.2.11-21.fc32.x86_64 (gdb) bt lvalue=0x560e10 "SendOption", ltype=2, rvalue=0x560e1b "11:string", data=0x561e20, userdata=0x561cd0) at ../src/network/networkd-dhcp-common.c:580 table=0x4392e0 <network_network_gperf_lookup>, section=0x560ef0 "DHCPv4", section_line=14, lvalue=0x560e10 "SendOption", rvalue=0x560e1b "11:string", flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:132 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, section=0x7fffffffc9f8, section_line=0x7fffffffc9a0, section_ignored=0x7fffffffc99d, l=0x560e10 "SendOption", userdata=0x561cd0) at ../src/shared/conf-parser.c:270 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:395 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:452 dropin_dirname=0x7fffffffcbd0 "veth99.network.d", sections=0x4f3a18 "Match", lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:511 (gdb) q A debugging session is active. Inferior 1 [process 118718] will be killed. ``` ``` $ printf '[DHCPv4]\nSendOption=1:uint8' >crash $ ./out/fuzz-network-parser ./crash INFO: Seed: 1158717610 INFO: Loaded 2 modules (199728 inline 8-bit counters): 136668 [0x7faf3e91a930, 0x7faf3e93bf0c), 63060 [0xadf190, 0xaee7e4), INFO: Loaded 2 PC tables (199728 PCs): 136668 [0x7faf3e93bf10,0x7faf3eb51cd0), 63060 [0xaee7e8,0xbe4d28), ./out/fuzz-network-parser: Running 1 inputs 1 time(s) each. Running: ./crash Assertion 's' failed at src/basic/parse-util.c:458, function int safe_atou8(const char *, uint8_t *)(). Aborting. ==5588== ERROR: libFuzzer: deadly signal #0 0x51811e in __sanitizer_print_stack_trace (/home/vagrant/systemd/out/fuzz-network-parser+0x51811e) #1 0x46b921 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/out/fuzz-network-parser+0x46b921) #2 0x44ded6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (/home/vagrant/systemd/out/fuzz-network-parser+0x44ded6) #3 0x44df9d in fuzzer::Fuzzer::StaticCrashSignalCallback() (/home/vagrant/systemd/out/fuzz-network-parser+0x44df9d) #4 0x7faf3d6d7b1f (/lib64/libpthread.so.0+0x14b1f) #5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624) #6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8) #7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9 systemd#8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9 systemd#9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21 systemd#10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32 systemd#11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16 systemd#12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21 systemd#13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21 systemd#14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16 systemd#15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13 systemd#16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16 systemd#17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8) systemd#18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505) systemd#19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449) systemd#20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6) systemd#21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) systemd#22 0x42c4fd in _start (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4fd) NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` (cherry picked from commit 1eb7342)

This lets the libc/xcrypt allocate as much storage area as it needs. Should fix systemd#16965: testsuite-46.sh[74]: ==74==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f3e972e1080 at pc 0x7f3e9be8deed bp 0x7ffce4f28530 sp 0x7ffce4f27ce0 testsuite-46.sh[74]: WRITE of size 131232 at 0x7f3e972e1080 thread T0 testsuite-46.sh[74]: #0 0x7f3e9be8deec (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec) testsuite-46.sh[74]: #1 0x559cd05a6412 in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:818:21 testsuite-46.sh[74]: #2 0x559cd058fb03 in create_home /systemd-meson-build/../build/src/home/homectl.c:1112:29 testsuite-46.sh[74]: #3 0x7f3e9b5b3058 in dispatch_verb /systemd-meson-build/../build/src/shared/verbs.c:103:24 testsuite-46.sh[74]: #4 0x559cd058c101 in run /systemd-meson-build/../build/src/home/homectl.c:3325:16 testsuite-46.sh[74]: #5 0x559cd058c00a in main /systemd-meson-build/../build/src/home/homectl.c:3328:1 testsuite-46.sh[74]: #6 0x7f3e9a88b151 in __libc_start_main (/usr/lib/libc.so.6+0x28151) testsuite-46.sh[74]: #7 0x559cd0583e7d in _start (/usr/bin/homectl+0x24e7d) testsuite-46.sh[74]: Address 0x7f3e972e1080 is located in stack of thread T0 at offset 32896 in frame testsuite-46.sh[74]: #0 0x559cd05a60df in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:789 testsuite-46.sh[74]: This frame has 6 object(s): testsuite-46.sh[74]: [32, 40) 'priv' (line 790) testsuite-46.sh[74]: [64, 72) 'np' (line 791) testsuite-46.sh[74]: [96, 104) 'salt' (line 809) testsuite-46.sh[74]: [128, 32896) 'cd' (line 810) testsuite-46.sh[74]: [33152, 33168) '.compoundliteral' <== Memory access at offset 32896 partially underflows this variable testsuite-46.sh[74]: [33184, 33192) 'new_array' (line 832) <== Memory access at offset 32896 partially underflows this variable testsuite-46.sh[74]: HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork testsuite-46.sh[74]: (longjmp and C++ exceptions *are* supported) testsuite-46.sh[74]: SUMMARY: AddressSanitizer: stack-buffer-overflow (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec) It seems 'struct crypt_data' is 32896 bytes, but libclang_rt wants more, at least 33168?

C.f. 9793530. We'd crash when trying to access an already-deallocated object: Thread no. 1 (7 frames) #2 log_assert_failed_realm at ../src/basic/log.c:844 #3 event_inotify_data_drop at ../src/libsystemd/sd-event/sd-event.c:3035 #4 source_dispatch at ../src/libsystemd/sd-event/sd-event.c:3250 #5 sd_event_dispatch at ../src/libsystemd/sd-event/sd-event.c:3631 #6 sd_event_run at ../src/libsystemd/sd-event/sd-event.c:3689 #7 sd_event_loop at ../src/libsystemd/sd-event/sd-event.c:3711 systemd#8 run at ../src/home/homed.c:47 The source in question is an inotify source, and the messages are: systemd-homed[1340]: /home/ moved or renamed, recreating watch and rescanning. systemd-homed[1340]: Assertion '*_head == _item' failed at src/libsystemd/sd-event/sd-event.c:3035, function event_inotify_data_drop(). Aborting. on_home_inotify() got called, then manager_watch_home(), which unrefs the existing inotify_event_source. I assume that the source gets dispatched again because it was still in the pending queue. I can't reproduce the issue (timing?), but this should fix systemd#17824, https://bugzilla.redhat.com/show_bug.cgi?id=1899264.

When trying to calculate the next firing of 'Sun *-*-* 01:00:00', we'd fall into an infinite loop, because mktime() moves us "backwards": Before this patch: tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 ... We rely on mktime() normalizing the time. The man page does not say that it'll move the time forward, but our algorithm relies on this. So let's catch this case explicitly. With this patch: $ TZ=Europe/Dublin faketime 2021-03-21 build/systemd-analyze calendar --iterations=5 'Sun *-*-* 01:00:00' Normalized form: Sun *-*-* 01:00:00 Next elapse: Sun 2021-03-21 01:00:00 GMT (in UTC): Sun 2021-03-21 01:00:00 UTC From now: 59min left Iter. #2: Sun 2021-04-04 01:00:00 IST (in UTC): Sun 2021-04-04 00:00:00 UTC From now: 1 weeks 6 days left <---- note the 2 week jump here Iter. #3: Sun 2021-04-11 01:00:00 IST (in UTC): Sun 2021-04-11 00:00:00 UTC From now: 2 weeks 6 days left Iter. #4: Sun 2021-04-18 01:00:00 IST (in UTC): Sun 2021-04-18 00:00:00 UTC From now: 3 weeks 6 days left Iter. #5: Sun 2021-04-25 01:00:00 IST (in UTC): Sun 2021-04-25 00:00:00 UTC From now: 1 months 4 days left Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1941335.

When exiting PID 1 we most likely don't have stdio/stdout open, so the final LSan check would not print any actionable information and would just crash PID 1 leading up to a kernel panic, which is a bit annoying. Let's instead attempt to open /dev/console, and if we succeed redirect LSan's report there. The result is a bit messy, as it's slightly interleaved with the kernel panic, but it's definitely better than not having the stack trace at all: [ OK ] Reached target final.target. [ OK ] Finished systemd-poweroff.service. [ OK ] Reached target poweroff.target. ================================================================= 3 1m 43.251782] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 43.252838] CPU: 2 PID: 1 Comm: systemd Not tainted 6.4.12-200.fc38.x86_64 #1 ==[1==ERR O R :4 3Le.a2k53562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 [ 43.254683] Call Trace: [ 43.254911] <TASK> [ 43.255107] dump_stack_lvl+0x47/0x60 S[ a 43.n2555i05] panic+t0x192/0x350 izer[ :43.255966 ] do_exit+0x990/0xdb10 etec[ 43.256504] do_group_exit+0x31/0x80 [ 43.256889] __x64_sys_exit_group+0x18/0x20 [ 43.257288] do_syscall_64+0x60/0x90 o_user_mod leaks[ 43.257618] ? syscall_exit_t +0x2b/0x40 [ 43.258411] ? do_syscall_64+0x6c/0x90 1mDirect le[ 43.258755] ak of 21 byte(s)? exc_page_fault+0x7f/0x180 [ 43.259446] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 43.259901] RiIP: 0033:0x7f357nb8f3ad4 1 objec[ 43.260354] Ctode: 48 89 (f7 0f 05 c3 sf3 0f 1e fa b8 3b 00 00 00) 0f 05 c3 0f 1f 4 0 00 f3 0f 1e fa 50 58 b8 e7 00 00 00 48 83 ec 08 48 63 ff 0f 051 [ 43.262581] RSP: 002b:00007ffc25872440 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 a RBX: 00007f357be9b218 RCX: 00007f357b8f3ad4m:ffd [ 43.264512] RDX: 0000000000000001 RSI: 00007f357b933b63 RDI: 0000000000000001 [ 43.265355] RBP: 00007f357be9b218 R08: efffffffffffffff R09: 00007ffc258721ef [ 43.266191] R10: 000000000000003f R11: 0000000000000202 R12: 00000fe6ae9e0000 [ 43.266891] R13: 00007f3574f00000 R14: 0000000000000000 R15: 0000000000000007 [ 43.267517] </TASK> #0 0x7f357b8814a8 in strdup (/lib64/libasan.so.8+0x814a8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f) #1 0x7f3578d43317 in cg_path_decode_unit ../src/basic/cgroup-util.c:1132 #2 0x7f3578d43936 in cg_path_get_unit ../src/basic/cgroup-util.c:1190 #3 0x7f3578d440f6 in cg_pid_get_unit ../src/basic/cgroup-util.c:1234 #4 0x7f35789263d7 in bus_log_caller ../src/shared/bus-util.c:734 #5 0x7f357a9cf10a in method_reload ../src/core/dbus-manager.c:1621 #6 0x7f3578f77497 in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406 #7 0x7f3578f80dd8 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319 systemd#8 0x7f3578f82487 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439 systemd#9 0x7f3578fe41f1 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3007 systemd#10 0x7f3578fe477b in process_running ../src/libsystemd/sd-bus/sd-bus.c:3049 systemd#11 0x7f3578fe75d1 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3269 systemd#12 0x7f3578fe776e in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3296 systemd#13 0x7f3578feaedc in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3638 systemd#14 0x7f35791c2f68 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187 systemd#15 0x7f35791cc6f9 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808 systemd#16 0x7f35791cd830 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869 systemd#17 0x7f357abcd572 in manager_loop ../src/core/manager.c:3244 systemd#18 0x41db21 in invoke_main_loop ../src/core/main.c:1960 systemd#19 0x426615 in main ../src/core/main.c:3125 systemd#20 0x7f3577c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) systemd#21 0x7f3577c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) systemd#22 0x408494 in _start (/usr/lib/systemd/systemd+0x408494) (BuildId: fe61e1b0f00b6a36aa34e707a98c15c52f6b960a) SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). [ 43.295912] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 43.297036] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]--- Originally noticed in systemd#28579.

robertgzr requested review from alban and iaguis September 7, 2017 16:16

robertgzr commented Sep 7, 2017

View reviewed changes

robertgzr force-pushed the robertgzr/nspawn-syscall-filter-2 branch from be9b516 to 482a3a8 Compare September 8, 2017 09:08

iaguis suggested changes Sep 8, 2017

View reviewed changes

robertgzr force-pushed the robertgzr/nspawn-syscall-filter-2 branch 2 times, most recently from a3e6d4a to 865b8c5 Compare September 8, 2017 14:50

robertgzr commented Sep 8, 2017

View reviewed changes

robertgzr force-pushed the robertgzr/nspawn-syscall-filter-2 branch from 865b8c5 to 0ab4971 Compare September 11, 2017 15:58

robertgzr closed this Sep 14, 2017

vbatts pushed a commit that referenced this pull request Nov 12, 2020

Merge pull request #3 from flatcar-linux/dongsu/fix-root-dir-user

582791c

core: factor root_directory application out of apply_working_directory


		int seccomp_filter_set_add(Set s, bool b, const SyscallFilterSet set);

		int seccomp_add_syscall_filter_set(scmp_filter_ctx seccomp, uint32_t default_action, const SyscallFilterSet *set, uint32_t action);

[WIP] nspawn: Add --syscall-filter option #3

[WIP] nspawn: Add --syscall-filter option #3

Uh oh!

Conversation

robertgzr commented Sep 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dongsupark commented Sep 8, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

robertgzr commented Sep 8, 2017

Uh oh!

iaguis left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

robertgzr Sep 8, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

robertgzr commented Sep 7, 2017 •

edited

Loading

dongsupark commented Sep 8, 2017 •

edited

Loading

robertgzr Sep 8, 2017 •

edited

Loading