[systemd-devel] Antw: Re: [systemd‑devel] [EXT] Proposal to extend os‑release/machine‑info with field PREFER_HARDENED_CONFIG
>>> Peter Hoeg schrieb am 17.02.2022 um 07:07 in Nachricht <87k0duvvtv@hoeg.com>: >>> I think os‑relesase describes the operating system, not policies. >> >> You are right. Perhaps machine‑info would be a better fit than os‑release. > > To what extent a machine is locked down is a policy choice. There are > already loads of tools available to manage policy so this really doesn't > belong here and if you want to ensure that your fleet of machines are locked > down through something like PREFER_HARDENED_CONFIG=1, you're going to need > tools to manage *that* anyway. Then why not use the same tool(s) to simply > manage the machines? And what exactly should it do? Also: Do you really believe in "one size fits all" security-wise? If (at all), then the parameter should be "SECURITY_POLICY=name" (where name is one of the predefined policies). And most of all, selecting a different policy does not make it a different OS. Regards, Ulrich Windl > > It's 2022 ‑ nobody should be doing this by hand.
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] [RFC] systemd‑resolved: Send d‑bus signal after DNS resolution
>>> Lennart Poettering schrieb am 16.02.2022 um 18:59 in Nachricht : > On Mi, 16.02.22 12:13, Dave Howorth (syst...@howorth.org.uk) wrote: > >> > This could be used by applications for auditing/logging services >> > downstream of the resolver, or to update the firewall on the system. >> >> Perhaps an example use case would help but I'm not clear how a DNS >> resolution would usefully cause a state change in the firewall without >> some further external guidance? > > Yeah, I am not sure I grok the relationship to firewalls here, > either. Updatign firewalls asynchronously based on DNS lookups sounds > wrong to me... Unless you want to implement nice backdoors ;-) > > Lennart > > ‑‑ > Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Q: Perform action for reboots happen too frequently?
>>> Lennart Poettering schrieb am 16.02.2022 um 18:17 in Nachricht : > On Mi, 16.02.22 14:09, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> Hi! >> >> I wonder: Is it possible with systemd to detect multiple reboots >> within a specific time interval, and react, like executing some >> systemctl command (that is expected to "improve" things)? With >> "reboots" I'm mainly thinking of unexpected boots, not so much the >> "shutdown ‑r" commands, but things like external resets, kernel >> panics, watchdog timeouts, etc. > > The information why a system was reset is hard to get. Some watchdog > hw will tell you if it was recently triggered, and some expensive hw > might log serious errors to the acpi pstore stuff, but it's all icky > and lacks integration. Lennart, you got me wrong: I don't want to filter on the reasons of the (re)boot, but I just wanted to rule out any possible solution that stores information during an orderly shutdown/reboot ;-) > > A safe approach would probably to instead track boots where the root > fs or so is in dirty state. Pretty much all of today's file systems > track that. In the past (when there are a few logins only) I would have been tempted to use "last" to grep for boots, but if there are many (automated) logins, those boots may be "rolled out" and thus won't be counted possibly. > > It sounds like an OK feature to add to the systemd root fs mount logic > to check for the dirty flag before doing that and then using that is > hint to boot into a target other than default.target that could then > apply further policy (and maybe then go on to enter default.target). > > TLDR: nope, this does not exist yet, but parts of it sound like > worthwile feature additions to systemd. Something very primitive: a) Increment some counter on every boot, and reset that counter after some time. b) Check the counter and if it is >= some threshold, execute a one-shot command Could systemd help with a) and b)? Regards, Ulrich > > Lennart > > ‑‑ > Lennart Poettering, Berlin
Re: [systemd-devel] Restart=on-failure and SuccessAction=reboot-force causing reboots on every exit of Main PID
Hi, The minimal file with which I was able to reproduce the issue is: [Unit] Description="Example" SuccessAction=reboot-force [Service] Type=simple ExecStart=/bin/false Restart=on-failure I can reproduce it both on my buildroot system with systemd 247 and fresh Fedora 35 minimal install with v249.9-1.fc35 . After commenting out "Restart=on-failure" the reboots are not happening, and the service is "failed" as expected. Commenting out "SuccessAction=reboot-force" but leaving "Restart=on-failure" not commented causes the service to restart without a system reboot, as expected. Michał
[systemd-devel] Antw: [EXT] Re: Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG
>>> Stefan Schröder schrieb am 16.02.2022 um 18:11 in Nachricht <1487454823.169440.1645031460...@webmail.strato.com>: ... > There are reasons why the (...) decide not to ship > with 'hardened' defaults. ... As said before, in most cases "comfortable" and "secure" contradict. For example: It's hard to tell a former Windows user that he/she/it cannot read syslog as normal user, so many "easy" configurations allow that. OTOH, when using SSH-login and you enter your password where you should have entered your user name, your password will be logged in syslog. For a multi-user system you don't want other users see your password, then (well if aware the user would change the password after that anyhow). This is just one example: Other examples: Require root (or other privileged user) to: * configure a network (use WLAN) * shutdown the system * mount a CD/DVD/USB disk * use graphics acceleration * use the clipboard (yes, seriously) * use the webcam * use a specific printer ... Some people really don't want that type of "security". Most people don't even want to authenticate, but just turn off the computer (or wake it up). Regards, Ulrich
