Etienne Cordonnier 4fc8427a6c systemd: make home directory readable by systemd-coredump
In 924453c225
ProtectHome was set to true for systemd-coredump in order to reduce risk, since an attacker could craft a malicious binary in order to compromise systemd-coredump.
At that point the object analysis was done in the main systemd-coredump process.
Because of this systemd-coredump is unable to product symbolicated call-stacks for binaries running under /home ("n/a" is shown instead of function names).

However, later in 61aea456c1 systemd-coredump was changed to do the object analysis in a forked process,
covering those security concerns.

Let's set ProtectHome to read-only so that systemd-coredump produces symbolicated call-stacks for processes running under /home.

Note: it still does not work in /tmp (because of PrivateTmp=yes) and in /root (for unknown reasons).

Before the change (with minidebuginfo enabled):

    root@qemux86-64:~# /home/sleep 1000 &
    [1] 426
    root@qemux86-64:~# kill -11 $(pidof sleep)
    root@qemux86-64:~# coredumpctl info
               PID: 426 (sleep)
               UID: 0 (root)
               GID: 0 (root)
            Signal: 11 (SEGV)
         Timestamp: Fri 2024-09-06 17:25:18 UTC (3s ago)
      Command Line: /home/sleep 1000
        Executable: /home/sleep
     Control Group: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyS0.service
              Unit: serial-getty@ttyS0.service
             Slice: system-serial\x2dgetty.slice
           Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5
        Machine ID: fb279f18f2c849c59768754c7a274ee3
          Hostname: qemux86-64
           Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.426.1725643518000000.zst (present)
      Size on Disk: 16.5K
           Message: Process 426 (sleep) of user 0 dumped core.

                    Stack trace of thread 426:
                    #0  0x00007f365f3849a7 clock_nanosleep (libc.so.6 + 0xd49a7)
                    #1  0x00007f365f38f667 __nanosleep (libc.so.6 + 0xdf667)
                    #2  0x0000561fee703737 n/a (/home/sleep + 0x7737)
                    #3  0x000000003a6227c5 n/a (n/a + 0x0)
                    ELF object binary architecture: AMD x86-64
    [1]+  Segmentation fault      (core dumped) /home/sleep 1000

After the change (with minidebuginfo enabled):

    root@qemux86-64:~# /home/sleep 1000 &
    [1] 450
    root@qemux86-64:~# kill -11 $(pidof sleep)
    root@qemux86-64:~# coredumpctl info
               PID: 450 (sleep)
               UID: 0 (root)
               GID: 0 (root)
            Signal: 11 (SEGV)
         Timestamp: Fri 2024-09-06 17:30:12 UTC (4s ago)
      Command Line: /home/sleep 1000
        Executable: /home/sleep
     Control Group: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyS0.service
              Unit: serial-getty@ttyS0.service
             Slice: system-serial\x2dgetty.slice
           Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5
        Machine ID: fb279f18f2c849c59768754c7a274ee3
          Hostname: qemux86-64
           Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.450.1725643812000000.zst (present)
      Size on Disk: 16.5K
           Message: Process 450 (sleep) of user 0 dumped core.

                    Stack trace of thread 450:
                    #0  0x00007f795dd689a7 clock_nanosleep (libc.so.6 + 0xd49a7)
                    #1  0x00007f795dd73667 __nanosleep (libc.so.6 + 0xdf667)
                    #2  0x0000561965c9d737 rpl_nanosleep (sleep + 0x7737)
                    #3  0x0000561965c9d0c1 xnanosleep (sleep + 0x70c1)
                    #4  0x0000561965c985c8 main (sleep + 0x25c8)
                    #5  0x00007f795dcba01b __libc_start_call_main (libc.so.6 + 0x2601b)
                    #6  0x00007f795dcba0d9 __libc_start_main (libc.so.6 + 0x260d9)
                    #7  0x0000561965c98685 _start (sleep + 0x2685)
                    ELF object binary architecture: AMD x86-64
    [1]+  Segmentation fault      (core dumped) /home/sleep 1000

(From OE-Core rev: b8c1f999038b7cd6fc2e80ed215541c8a4d9e19f)

Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2024-09-09 17:04:15 +01:00
2024-09-06 18:39:44 +01:00
2024-09-05 21:47:22 +01:00
2024-02-19 11:34:33 +00:00
2021-07-19 18:07:21 +01:00
2023-10-19 11:31:13 +01:00

Poky

Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.

Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.

As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.

The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/

OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.

Contribution Guidelines

Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.

Where to Send Patches

As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:

OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):

BitBake (files in bitbake/):

Documentation (files in documentation/):

meta-yocto (files in meta-poky/, meta-yocto-bsp/):

If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.

CII Best Practices

Description
No description provided
Readme 251 MiB