19:32:11 <sumpfralle3> #startmeeting
19:32:11 <MeetBot> Meeting started Wed Jan  8 19:32:11 2020 UTC.  The chair is sumpfralle3. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:32:11 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:32:33 <sumpfralle3> It is Wednesday again - time for our weekly IRC meeting ...
19:36:20 <sumpfralle3> h01ger: I prepared a set of changes for munin's Debian packaging. I was struggling a while with the autopkgtest, but finally I came to the conclusion, that the issue should be based on my local testing setup (with lxc). I tested it a lot, but failed to find the problem (with rebooting into sysvinit). I assume, that it will work on real infrastructure. Would you mind uploading it in the current
19:36:21 <sumpfralle3> state or do you have another idea?
19:39:01 <h01ger> happy to upload
19:39:12 <h01ger> also hi & little time :)
19:44:08 <sumpfralle3> great - I pushed my changes to the branch in the munin repository. Hopefully enjoy your little time :)
19:45:03 <h01ger> thanks & you too!
19:45:10 <h01ger> you might need to remember me to upload
19:48:59 <sumpfralle3> no problem - I happily ping you every day :)
19:50:46 <h01ger> :)
20:05:13 <TheSnide> hi
20:06:57 <sumpfralle3> hello
20:07:07 <sumpfralle3> I hope, you had nice and refreshing holidays?
20:07:22 <TheSnide> yep
20:08:26 <TheSnide> btw, just wanted to speak about deb#939339
20:08:55 <sumpfralle3> since it is related: did you take a look at https://github.com/munin-monitoring/munin/pull/1261?
20:09:13 <TheSnide> no, but looking now :)
20:09:44 <TheSnide> aha.. that's awesome.
20:11:10 <TheSnide> anyway, for what's worth, i would tend to agree with Laurence on the "Beware of the Leopard" part
20:11:19 <sumpfralle3> But it was a bit of pain to work around the environment variable issues. Maybe you have some hints regarding the code quality. My perl is thin ...
20:11:50 <TheSnide> sumpfralle3: bah, code quality can always be improved later.
20:12:01 <sumpfralle3> :)
20:12:45 <sumpfralle3> I could imagine, that we ask a debconf question during package installation. Would this be sufficient from your point of view?
20:13:34 <TheSnide> it actually reflects my feeling and linus' in his infamous "without users, a secure system is of no use"
20:14:41 <sumpfralle3> I did not read that, but I guess, I understand.
20:14:59 <TheSnide> https://www.theregister.co.uk/2017/11/24/linus_torvalds_approach_to_security/
20:15:20 <TheSnide> i amended his more colorful statents ;)
20:15:29 <TheSnide> statements*
20:16:50 <TheSnide> ... back to your question : yes a debconf question is awesome. now it comes back to the "default"
20:16:53 <TheSnide> :p
20:18:41 <sumpfralle3> indeed :)
20:19:06 <TheSnide> that said, if we cannot come to an agreement on it, my #2 most voted option would be to do what she sugggested :
20:19:09 <TheSnide> > The [df*] section in the plugins.conf file (aka plugins-conf/munin-node) could contain a comment regarding this situation
20:19:33 <sumpfralle3> that sounds reasonable
20:19:58 <sumpfralle3> and the plugin code itself could include it
20:20:18 <TheSnide> as, I deeply agree that `README.Debian` is _the_ proper place to put it. But as Munin's goal is to be "as simple as hell", we should not _require_ any manual read ;p
20:21:40 <TheSnide> my take is that munin is all about "plug and play". So having to go through extra hoops to make something obvious work is against that spirit IMHO
20:21:43 <sumpfralle3> it is a pity that we (munin) cannot detect, when a process was restricted by certain security mechanism. But I undertand, that this is almost impossible (technically).
20:22:33 <TheSnide> well, we can detect that /home is empty. Which is 90% not what is expected.
20:23:18 <sumpfralle3> df simply omits this entry. Or what did you mean?
20:32:26 <TheSnide> ah, maybe. didn't really look closely
20:32:58 <TheSnide> But, IMHO, we should not restrict the default. And offer the option to easily restrict it if needed.
20:34:21 <TheSnide> what annoys me a little is that the node runs as root *from a socket*. And therefore has to drop privileges.
20:35:33 <TheSnide> let's put some comments in plugins.conf. and change the default when the node won't run *from* a socket anymore.
20:40:42 <sumpfralle3> agreed. How would you do that?
20:41:54 <TheSnide> by making munin-async much nicer than now
20:42:23 <TheSnide> and munin-node just reading the spooled data
20:43:14 <TheSnide> so, only munin-asyncd needs to be run as root. As it would handle the plugins itself, not connecting to munin-node.
20:43:48 <sumpfralle3> Sounds a bit more complex. But it obviously improves security. But the hardening flags are not only used against an external attack, but also against malicious plugins.
20:44:01 <TheSnide> --> well, that the theory. In practice i think I'll split munin-node in 2 : munin-polld & munin-node
20:44:54 <TheSnide> thinking loudly.... what if munin-node _delegates_ the plugin run to _munin-run_, even at runtime?
20:45:21 <TheSnide> delegates.... via systemd-run
20:46:22 <TheSnide> it would annihilate the "no overhead" part. but it could be done for priviledged plugins. like a "setuid on steroid"
20:50:43 <sumpfralle3> Thus munin-run would be setuid? Is this a "modern" (whatever that is) practice?
20:57:07 <TheSnide> i don't think, just thinking lougly
20:57:17 <TheSnide> i don't know, just thinking loudly*
20:59:35 <bcg_> That df-hardening problem was new to me. After reading the debian bug, I would suggest to default to "read-only" for /home
20:59:49 <bcg_> (if you're taking votes...)
21:01:03 <sumpfralle3> bcg_: your voice is certainly welcome :)
21:01:12 <sumpfralle3> do you enable the flag for epel?
21:02:26 <bcg_> Having it as "read-only" is better than it was before (no hardening). It's not super-hardening, but still better than nothing.
21:02:47 <bcg_> No, epel has only privatetmp at the moment.
21:04:44 <bcg_> I too have /home as separate file system, so I need read-only. Rhel doesn't have install-time questions (debconf?), so that's not an option for me.
21:10:11 <bcg_> I see also one other difference. In munin-async.service I have Requires=munin-node.service, as you use Wants=
21:10:47 * TheSnide also has /home separate
21:16:51 <bcg_> "ProtectHome=read-only" is now added to my munin-node.service and will be included to next epel update.
21:19:05 <sumpfralle3> I also tend to switch to read-only for /home. I will summarize our discussion here and submit it to the Debian bug. Let's see, if someone else (maybe h01ger) wants to add his thoughts there.
21:20:32 <sumpfralle3> Any other topics - or should we close the meeting for today?
21:29:44 <sumpfralle3> #endmeeting