Re: [systemd-devel] Antw: Re: [systemd‑devel] [EXT] Proposal to extend os‑release/machine‑info with field PREFER_HARDENED_CONFIG
Let me list the counter arguments to the proposal (to include a new field PREFER_HARDENED_CONFIG) so far: * The packages should be deploying a secure configuration by default. Counter-argument: Yes, but they don't. There are obviuosly competing interests and sometimes convenience wins. Nonetheless package maintainers would probably appreciate the option to provide a hardened configuration. * System administrators should you use automated tools to configure their systems securely. Counter-argument: Yes, they should. But imagine that your puppet/chef/ansible recipes would become 75% superfluous because the packages are installed using the secure default and your remaining recipes can deal with your real system idiosyncracies instead of boilerplate hardening. * There is no one-size fits all and I don't want to harden my system anyway. Counter-argument: This is not about individual user's needs. It's about large-scale critical infrastructure setups that have hardening requirements galore. And this is about upstream. Solve problems at the root at install time. As has been pointed out in one post "Systemd is about Managing systems after installation increases complexity and adds state and configuration management issues. * "you're going to need tools to manage *that* anyway. Then why not use the same tool(s) to simply manage the machines?" Counter-argument: There is nothing to "manage". You just deploy a hardenend config instead of the default one. It's fire and forget. The work-load to achieve the hardening is distributed across all package maintainers who can opt-in to provide a more secure configuration if they like. While the availability of a hardened configuration is the responsiblity of the package, the implementation of how the secure configuration is copied is the responsibility of the package-manager-developers, who can implement this field at their own pace. There will be probably competition across linux distributions who manages secure configurations best. Right now, there is no support for hardening a system. All the tools and hardening guidelines are adhoc and difficult to maintain while the distributions evolve. It'd be an easy way out for package creators and maintainers that want to offer more secure defaults, but cannot because it might break compatibility and convenience expectations. PS. I concur that os-release is not the right spot for the suggested new field. But machine-info still looks viable to me. yours Stefan
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] PrivateNetwork=yes is memory costly
>>> Lennart Poettering schrieb am 09.03.2022 um 16:18 in Nachricht : > On Mo, 07.03.22 15:10, Christopher Wong (christopher.w...@axis.com) wrote: > >> Hi, >> >> >> It seems that PrivateNetwork=yes is a memory consuming >> directive. The kernel seems to allocate quite an amount of memory >> for each service (~50 kB) that has this directive enabled. I wonder >> if this is expected and if anyone has had similar experience? Despite of that I'm tempted to ask: "How many 50kB are there in a GB?" ;-) > > PrivateNetwork=yes means that a private network namespace is allocated > for the service. If you think network namespaces are too expensive in > their current implementation, please bring this up with the kernel > people, because they are a kernel concept after all, we just allocate > them if told so. > > network namespaces are an effective way to disconnect a service from > the network, if the service doesn't need it. It's probably one of the > most relevant sandboxing options we offer, since disabling the attack > surface called "network" for a service is of such major > importance. That said, if you disable the network namespace > functionality in the kernel systemd will handle this gracefully, and > not use it. If the feature is available in the kernel we will however > use it. > >> Is there any ways to reduce the usage? > > Besides turning it off? Nothing I was aware of. > > Lennart > > ‑‑ > Lennart Poettering, Berlin
Re: [systemd-devel] PrivateNetwork=yes is memory costly
On Mo, 07.03.22 15:10, Christopher Wong (christopher.w...@axis.com) wrote: > Hi, > > > It seems that PrivateNetwork=yes is a memory consuming > directive. The kernel seems to allocate quite an amount of memory > for each service (~50 kB) that has this directive enabled. I wonder > if this is expected and if anyone has had similar experience? PrivateNetwork=yes means that a private network namespace is allocated for the service. If you think network namespaces are too expensive in their current implementation, please bring this up with the kernel people, because they are a kernel concept after all, we just allocate them if told so. network namespaces are an effective way to disconnect a service from the network, if the service doesn't need it. It's probably one of the most relevant sandboxing options we offer, since disabling the attack surface called "network" for a service is of such major importance. That said, if you disable the network namespace functionality in the kernel systemd will handle this gracefully, and not use it. If the feature is available in the kernel we will however use it. > Is there any ways to reduce the usage? Besides turning it off? Nothing I was aware of. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] How to grant systemd-nspawn access to USB device?
Hello Greg and thanks for answering :) I never used strace, so I couldn't figure from the output, but further research led me to this post: http://www.pclinuxos.com/forum/index.php?topic=135714.0 So I just tried (on the host): chmod o+rw /dev/bus/usb/001/005 And it is now working. I was not expecting this to be the solution. Thank you! Kevin P. Il giorno mer 9 mar 2022 alle ore 15:50 Greg KH ha scritto: > On Wed, Mar 09, 2022 at 03:04:00PM +0100, Kevin P wrote: > > Good evening everyone. > > I would like a nspawn container on my Raspberry Pi (Raspbian, systemd > 247) > > to access a RTL2838 DVB-T USB stick. > > Inside the container, dump1090 will run and feed aircraft data (piaware > and > > adsbexchange projects). > > > > lsusb gives: > > Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 > DVB-T > > > > file /dev/bus/usb/001/005 returns: > > /dev/bus/usb/001/005: character special (189/4) > > > > And finally grep 189 /proc/devices shows: > > 189 usb_device > > > > I edited both the .nspawn file and the .service file, of which I'm > > reporting the relevant parts below. > > /etc/systemd/nspawn/ads-b.nspawn > > [Files] > > Bind=/dev/bus/usb/001/005 > > > > systemd-nspawn@ads-b.service > > [Service] > > DeviceAllow=/dev/bus/usb/001/005 rwm > > DeviceAllow=usb_device rwm > > > > However I feel like I am doing something wrong, as starting dump1090 from > > within the container returns permission denied. > > I'll gladly take any advice :) > > Odds are the program wants to access the device node for the driver, not > the "raw" USB device /dev/bus/usb/*, right? > > What does strace show is failing exactly when you run the program? > > thanks, > > greg k-h >
Re: [systemd-devel] How to grant systemd-nspawn access to USB device?
On Wed, Mar 09, 2022 at 03:04:00PM +0100, Kevin P wrote: > Good evening everyone. > I would like a nspawn container on my Raspberry Pi (Raspbian, systemd 247) > to access a RTL2838 DVB-T USB stick. > Inside the container, dump1090 will run and feed aircraft data (piaware and > adsbexchange projects). > > lsusb gives: > Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T > > file /dev/bus/usb/001/005 returns: > /dev/bus/usb/001/005: character special (189/4) > > And finally grep 189 /proc/devices shows: > 189 usb_device > > I edited both the .nspawn file and the .service file, of which I'm > reporting the relevant parts below. > /etc/systemd/nspawn/ads-b.nspawn > [Files] > Bind=/dev/bus/usb/001/005 > > systemd-nspawn@ads-b.service > [Service] > DeviceAllow=/dev/bus/usb/001/005 rwm > DeviceAllow=usb_device rwm > > However I feel like I am doing something wrong, as starting dump1090 from > within the container returns permission denied. > I'll gladly take any advice :) Odds are the program wants to access the device node for the driver, not the "raw" USB device /dev/bus/usb/*, right? What does strace show is failing exactly when you run the program? thanks, greg k-h
[systemd-devel] networkd: changing priorities of default routing poilicy lists
Hello List, Given the following commands, I am asking if there is a possible solution to achive this the "systemd way" (meaning being able to configure this entirely via networkd configs), instead of having them to put into a unit file: ip -4 rule add pref 32765 table local ip -4 rule del pref 0 ip -6 rule add pref 32765 table local ip -6 rule del pref 0 I took those from the Kernel selftest scripts to fix the routing from one VRF to the main VRF by moving the local table above the l3mdev table: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/net/forwarding/lib.sh?id=330f4c53d3c2d8b11d86ec03a964b86dc81452f5#n499 This is somewhat being explained here if this is of interest: https://stbuehler.de/blog/article/2020/02/29/using_vrf__virtual_routing_and_forwarding__on_linux.html Thank you & kind regards, Marcel Menzel
[systemd-devel] How to grant systemd-nspawn access to USB device?
Good evening everyone. I would like a nspawn container on my Raspberry Pi (Raspbian, systemd 247) to access a RTL2838 DVB-T USB stick. Inside the container, dump1090 will run and feed aircraft data (piaware and adsbexchange projects). lsusb gives: Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T file /dev/bus/usb/001/005 returns: /dev/bus/usb/001/005: character special (189/4) And finally grep 189 /proc/devices shows: 189 usb_device I edited both the .nspawn file and the .service file, of which I'm reporting the relevant parts below. /etc/systemd/nspawn/ads-b.nspawn [Files] Bind=/dev/bus/usb/001/005 systemd-nspawn@ads-b.service [Service] DeviceAllow=/dev/bus/usb/001/005 rwm DeviceAllow=usb_device rwm However I feel like I am doing something wrong, as starting dump1090 from within the container returns permission denied. I'll gladly take any advice :) Kevin P.
Re: [systemd-devel] making firewalld an early boot service
On Mi, 09.03.22 08:17, Michael Biebl (mbi...@gmail.com) wrote: > > firewalld requires D-Bus so it must be started after D-Bus. You cannot > > start it earlier. > > See above, being Type=dbus, it has an explicit > Requires/After=dbus.socket. It has After=dbus.service, not After=dbus.socket, no? That's a difference during shutdown: if you order against the service this means you can still talk via the broker on shutdown. if you only order against the socket the broker might be dead by the time you shutdown. Ideally services would be written in a style that they just exit at shutdown and don't need to tdo D-Bus anymore just to exit. But of course reality isn't always ideal. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] making firewalld an early boot service
On Mi, 09.03.22 08:49, Andrei Borzenkov (arvidj...@gmail.com) wrote: > On 09.03.2022 00:59, Michael Biebl wrote: > > Hi, > > > > I need help with firewalld issue, specifically > > https://github.com/firewalld/firewalld/issues/414 > > > > the TLDR: both firewalld.service and cloud-init-local.service hook > > into network-pre.target and have a Before=network-pre.target ordering. > > > > cloud-init-local.service is an early boot service using > > DefaultDependencies=no and before sysinit.target. > > firewalld.service via DefaultDependencies=yes get's an > > After=sysinit.target ordering. > > > > So we have conflicting requirements and a dependency loop that needs > > to be broken by systemd. > > > > Firewalld is red herring here. cloud-init.service has > > After=networking.service What is this unit? Is this a Debian thing? Lennart -- Lennart Poettering, Berlin
[systemd-devel] EFI Boot default not honered
Hi, After upgrading to 250, systemd efi boot is no longer honoring the default. Neither loader.conf default nor LoaderDefaultEntry EFI variable have any effect. Instead it defaults to the last entry (alphabetically) in the entries/ directory. Anybody els have this issue (or some ideas about it)? -Sietse
Re: [systemd-devel] making firewalld an early boot service
On Wed, Mar 9, 2022 at 10:18 AM Michael Biebl wrote: > > Am Mi., 9. März 2022 um 06:49 Uhr schrieb Andrei Borzenkov > : > > > > On 09.03.2022 00:59, Michael Biebl wrote: > > > Hi, > > > > > > I need help with firewalld issue, specifically > > > https://github.com/firewalld/firewalld/issues/414 > > > > > > the TLDR: both firewalld.service and cloud-init-local.service hook > > > into network-pre.target and have a Before=network-pre.target ordering. > > > > > > cloud-init-local.service is an early boot service using > > > DefaultDependencies=no and before sysinit.target. > > > firewalld.service via DefaultDependencies=yes get's an > > > After=sysinit.target ordering. > > > > > > So we have conflicting requirements and a dependency loop that needs > > > to be broken by systemd. > > > > > > > Firewalld is red herring here. cloud-init.service has > > > > After=networking.service > > Before=sysinit.target > > > > This is a loop which has nothing to do with firewalld. > > Afaics firewalld.service is involved here. > For one, without it installed, there is no such ordering cycle. > OK, seems networking.service has DefaultDepencies=no, so yes, without firewalld it can be moved early. > To me it looks like cloud-init.service and firewalld.service are tied > together via this cloud-init-local.service > The loop below (from the firewalld issue) does not involve cloud-init-local.service. > > > [1.643638] systemd[1]: sysinit.target: Found ordering cycle on > > cloud-init.service/start > > [1.645482] systemd[1]: sysinit.target: Found dependency on > > networking.service/start > > [1.647274] systemd[1]: sysinit.target: Found dependency on > > network-pre.target/start > > [1.649010] systemd[1]: sysinit.target: Found dependency on > > firewalld.service/start > > [1.650718] systemd[1]: sysinit.target: Found dependency on > > dbus.service/start > > [1.652294] systemd[1]: sysinit.target: Found dependency on > > basic.target/start > > [1.654033] systemd[1]: sysinit.target: Found dependency on > > sysinit.target/start > > [1.655528] systemd[1]: sysinit.target: Job cloud-init.service/start > > deleted to break ordering cycle starting with sysinit.target/start > > > > > > ... > > > > > > > > > > > I dropped the After=dbus.service polkit.service orderings, as they are > > > either socket or D-Bus activated services, added an explicit > > > After=local-fs.target ordering just to be sure and hooked it into > > > sysinit.target. > > > > > > Would you agree that making a firewall service an early boot service > > > is a good idea? > > > > Firewalld cannot be socket activated. The whole reason to have firewall > > (any firewall) startup service is to instantiate netfilter configuration > > before networking becomes available. When exactly it is done does not > > matter - it can well be done as early boot service. But it cannot be > > delayed until something contacts firewall endpoint. It must be done > > before network-pre.target. > > I don't think i said I want firewalld to become socket activated? > What I did was drop After=dbus.service and After=polkit.service. > firewald.service is a Type=dbus service, so already get's an explicit > After=dbus.socket, Requires=dbus.socket which I think should satisfy > firewalld's D-Bus requirements, no? > > > > Does the above make sense or have I missed something? > > > > > > Feedback welcome. > > > > firewalld requires D-Bus so it must be started after D-Bus. You cannot > > start it earlier. > > See above, being Type=dbus, it has an explicit Requires/After=dbus.socket. I do not see how it helps. Firewalld cannot become active before D-Bus is started. If firewalld.service is ordered before network-pre.target systemd will wait for firewalld.service to become ready before activating network-pre.target. If network-pre.target is ordered before sysinit.target and hence before D-Bus service it means deadlock. It may work with systemd-networkd which dropped DefaultDependencies and so could be arbitrarily shuffled in boot sequence, but network.service is a generic alias that normally points to the actual implementation. Can you start NetworkManager before sysinit.target?
Re: [systemd-devel] making firewalld an early boot service
e65;6602;1cOn Di, 08.03.22 22:59, Michael Biebl (mbi...@gmail.com) wrote: > I wonder if firewald should be turned into an early boot service as > well. I doubt you can do that. Thing is that firewalld uses D-Bus, and services that do D-Bus will have a hard time to run during early boot. In systemd we have some services which do D-Bus and run in early boot, specifically networkd, resolved and systemd itself. They do that by simply not doing D-Bus that early, and watching the d-bus socket so that they connect the moment it becomes available. It's ugly as fuck, though and very hard to get right, it took us quite some time to get this reasonably right and race-free. Last time I looked firewalld is a bunch of scripts around iptables/nft shell outs? I have my doubts it's going to be easy to make that work, i.e. add the glue it needs to instantly connect to D-Bus once it becomes available in a race-free fashion- > Currently it looks like this: > > [Unit] > Description=firewalld - dynamic firewall daemon > Before=network-pre.target Network management services such as networkd are early-boot services. A late boot service ordered before network-pre.target and thus networkd is hence already an ordering cycle. > After=dbus.service > After=polkit.service These two are late boot service, hence hard to move to early boot if you keep them. > I wonder if the following would make sense > > > [Unit] > Description=firewalld - dynamic firewall daemon > DefaultDependencies=no > Before=network-pre.target > Wants=network-pre.target > After=local-fs.target > Conflicts=iptables.service ip6tables.service ebtables.service > ipset.service nftables.service > Documentation=man:firewalld(1) > > [Service] > ... > [Install] > WantedBy=sysinit.target It should also have Before=sysinit.target really. > Alias=dbus-org.fedoraproject.FirewallD1.service > I dropped the After=dbus.service polkit.service orderings, as they are > either socket or D-Bus activated services, added an explicit > After=local-fs.target ordering just to be sure and hooked it into > sysinit.target. My educated guess is that they want After=dbus.service mostly for shutdown ordering, i.e. so that they can still be talked to while the system goes down or so? The thing though is: i doubt firewalld is able to handle the case where the dbus broker isn't connectible yet. > Would you agree that making a firewall service an early boot service > is a good idea? Well, I am not a fan of the firewalld concept tbh. But yes, if you buy into the idea of firewalld, then you have to make it an early boot service really, if you intend to be compatible with early boot networking. That said, I think NetworkManager is not early-boot either right now, is it? So you have to move that too. But in that case too, not sure if it can deal with D-Bus not being around. Lennart -- Lennart Poettering, Berlin
