[systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
>>> Juan Guerrero schrieb am 11.12.2020 um 13:31 >>> in Nachricht : > Good morning; > > A question can someone help me with this issue: the file */proc/kcore* has > a size of 140G. How can I fix it, I must restart the server or is there > another way to solve it? > kernel-uek-2.6.39-400.211.1.el6uek > > evidence sections: > > 1.- the size of the kcore file > > 140737486266368 /proc/kcore Here too, but what is the problem (1G RAM): # ll /proc/kcore -r 1 root root 140737477885952 Dec 14 08:26 /proc/kcore ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
>>> Topi Miettinen schrieb am 11.12.2020 um 12:46 in Nachricht <27796c04-249e-6cf0-c3e1-0fd657a82...@gmail.com>: > On 11.12.2020 12.46, Jarkko Sakkinen wrote: >> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote: >>> On 9.12.2020 2.15, Jarkko Sakkinen wrote: On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: As a further argument, I just did this on a Fedora system: $ find /dev ‑perm /ugo+x ‑a \! ‑type d ‑a \! ‑type l No results. So making /dev noexec doesn't seem to have any benefit. >>> >>> It's no surprise that there aren't any executables in /dev since >>> removing MAKEDEV ages ago. That's not the issue, which is that >>> /dev is a writable directory (for UID=0 but no capabilities are >>> needed) and thus a potential location for constructing unapproved >>> executables if it is also mounted exec (W^X). >> >> UID 0 can just change mount options, though, unless SELinux or similar is > used. And SELinux can protect /dev just fine without noexec. > > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also SELinux > is not universal and the policies might not contain all users or services. > > ‑Topi What's the data that supports having noexec /dev anyway? With root access I can then just use something else like /dev/shm mount. Has there been out in the wild real world cases that noexec mount of would have prevented? For me this sounds a lot just something that "feels more secure" without any measurable benefit. Can you prove me wrong? >>> >>> I don't think security works that way. An attacker has various methods to >>> choose from, some are more interesting than others. The case where rw,exec >>> /dev would be interesting would imply that easier or more common avenues >>> would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or >>> /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP approach >>> with no need for any file system access is getting more common. It does not >>> mean that it would not be prudent to block the relatively easy approaches >>> too, including /dev. >> >> What if we add a new mount option "chrexec", which allows exec >> for character devices (S_IFCHR). > > I think devices are a bad match for SGX because devices haven't been > executable and SGX is actually an operation for memory. So something > like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX) > would be much more natural. Even better would be something that > conceptully also works for AMD version (either with the same flags or > MFD_SGX / MFD_whatever_the_AMD_version_is). +1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service kills application differently on shutdown vs on stop
14.12.2020 05:08, John пишет: > If I call systemctl to shutdown or reboot, the effect is that it does > not honor kodi-x11.service's ExecStop= line which results in an > unclean exit of kodi and of data loss since kodi writes out some data > when it exits. By contrast, calling systemctl to stop the service > works as expected. > > Does anyone with more knowledge that I understand the differences with > respect to this aspect of stopping a service as it relates to: > > 1) systemctl stop kodi-x11 (which behaves as expected) > 2) systemctl reboot (which does not behave as expected) > > Here is kodi-x11.service: > > [Unit] > Description=Kodi standalone (X11) > After=remote-fs.target systemd-user-sessions.service If your application creates user session, on shutdown systemd will stop existing sessions and it happens independently of your service. > network-online.target nss-lookup.target sound.target bluetooth.target > polkit.service upower.service mysqld.service > Wants=network-online.target polkit.service upower.service > Conflicts=getty@tty1.service > > [Service] > User=kodi > Group=kodi > EnvironmentFile=-/etc/conf.d/kodi-standalone > PAMName=login > TTYPath=/dev/tty1 > Environment=WINDOWING=x11 > ExecStart=/usr/bin/xinit /usr/bin/kodi-standalone -- :0 -quiet -nolisten tcp > vt1 > ExecStop=/usr/bin/killall --user kodi --exact --wait kodi-x11 > Restart=on-abort > StandardInput=tty > StandardOutput=journal > > [Install] > Alias=display-manager.service > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] service kills application differently on shutdown vs on stop
If I call systemctl to shutdown or reboot, the effect is that it does not honor kodi-x11.service's ExecStop= line which results in an unclean exit of kodi and of data loss since kodi writes out some data when it exits. By contrast, calling systemctl to stop the service works as expected. Does anyone with more knowledge that I understand the differences with respect to this aspect of stopping a service as it relates to: 1) systemctl stop kodi-x11 (which behaves as expected) 2) systemctl reboot (which does not behave as expected) Here is kodi-x11.service: [Unit] Description=Kodi standalone (X11) After=remote-fs.target systemd-user-sessions.service network-online.target nss-lookup.target sound.target bluetooth.target polkit.service upower.service mysqld.service Wants=network-online.target polkit.service upower.service Conflicts=getty@tty1.service [Service] User=kodi Group=kodi EnvironmentFile=-/etc/conf.d/kodi-standalone PAMName=login TTYPath=/dev/tty1 Environment=WINDOWING=x11 ExecStart=/usr/bin/xinit /usr/bin/kodi-standalone -- :0 -quiet -nolisten tcp vt1 ExecStop=/usr/bin/killall --user kodi --exact --wait kodi-x11 Restart=on-abort StandardInput=tty StandardOutput=journal [Install] Alias=display-manager.service ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
