| 28 Sep 2024 |
 undltd | In reply to@philipp:xndr.de
I don't think there is a universal answer since firewalls rules are more complex than just "port open or closed". let's say packets dropped or rejected by the kernel even if something is listening on said port and address | 15:24:12 |
| undltd | and I guess the next question is "packets from where" | 15:26:15 |
| undltd | to which the best answer I can provide (as a firewall noob) is "from outside my machine" | 15:27:08 |
 Johann | Not sure about that. The netfilter is quite complex and I do not have really a clue how Docker fucks around in there. | 17:05:12 |
 tgerbet | Basically if you have a Docker container running with port binding on anything else than a local address it will bypass your FW rules (it also does on local bind but it is less likely to be an issue on standard configs) | 21:57:53 |
| 29 Sep 2024 |
 hexa | added CAP_DAC_OVERRIDE to logrotate.service, and was a bit worried about the broad scope, but since it runs as root a capability boundary is better than nothing? | 20:01:05 |
| hexa | just now I grepped for other occurrences of this capability in nixpkgs | 20:01:18 |
| hexa | nixos/modules/services/monitoring/netdata.nix
295: "CAP_DAC_OVERRIDE" # is required for freeipmi and slabinfo plugins
nixos/modules/services/security/kanidm.nix
925: # CAP_DAC_OVERRIDE is needed to ignore ownership of unixd socket
929: "CAP_DAC_OVERRIDE"
nixos/modules/services/backup/snapraid.nix
169: CapabilityBoundingSet = "CAP_DAC_OVERRIDE";
212: CapabilityBoundingSet = "CAP_DAC_OVERRIDE" +
nixos/modules/services/misc/snapper.nix
282: CapabilityBoundingSet = "CAP_DAC_OVERRIDE CAP_FOWNER CAP_CHOWN CAP_FSETID CAP_SETFCAP CAP_SYS_ADMIN CAP_SYS_MODULE CAP_IPC_LOCK CAP_SYS_NICE";
nixos/modules/services/logging/logrotate.nix
263: "CAP_DAC_OVERRIDE"
nixos/modules/services/networking/ntp/chrony.nix
222: CapabilityBoundingSet = [ "CAP_CHOWN" "CAP_DAC_OVERRIDE" "CAP_NET_BIND_SERVICE" "CAP_SETGID" "CAP_SETUID" "CAP_SYS_RESOURCE" "CAP_SYS_TIME" ];
nixos/modules/services/networking/tetrd.nix
84: "CAP_DAC_OVERRIDE"
89: "CAP_DAC_OVERRIDE"
| 20:01:22 |
| hexa | ideally those can be reviewed, especially if they are network-facing services like kanidm | 20:01:59 |
| hexa | CAP_DAC_OVERRIDE
Bypass file read, write, and execute permission checks.
(DAC is an abbreviation of "discretionary access
control".)
| 20:02:37 |
| hexa | fwiw | 20:02:38 |
| 30 Sep 2024 |
| hexa | https://github.com/OpenPrinting/cups/releases/tag/v2.4.11 | 12:11:56 |
| hexa | https://github.com/OpenPrinting/cups/blob/2.4.x/CHANGES.md#changes-in-cups-v2411-2024-09-30 | 12:12:20 |
| tgerbet | Seems to contain only the set of patches for CVE-2024-47175. I opened the PR anyway, at least it allows us to cleanup the series of fetchpatch https://github.com/NixOS/nixpkgs/pull/345553 | 17:22:15 |
| 1 Oct 2024 |
|  -_o joined the room. | 21:00:10 |
| 2 Oct 2024 |
|  tlaurion aka Insurgo [UTC-4] changed their display name from tlaurion aka Insurgo [UTC-4] (🛫🗺️🛬: Back 2024-10-01) to tlaurion aka Insurgo [UTC-4]. | 12:42:36 |
| 3 Oct 2024 |
 ElvishJerricco | emily: point was that you'd do your idea of storing per generation secrets in terms of their names, along with a store of name -> secret. That way any generation always gets the most up to date version of the secret for the name. But if the name changes, the old generation still gets whatever was stored for the old name | 18:02:39 |
 emily | (wrong emily :) ) | 18:03:02 |
| ElvishJerricco | damn autocorrect | 18:03:09 |
| emily | I don't think it's intuitive that the name is semantically relevant in a way that is dependent on previous generations | 18:03:24 |
| ElvishJerricco | * damn autocorrect autocomplete (that one was autocorrect) | 18:03:27 |
| emily | that's both a weird CVS-like model for versioning, and totally inconsistent with how NixOS configurations work in general | 18:03:38 |
| emily | you can at least explain the current model in terms of being a total hack that violates the model, which it is | 18:03:50 |
| ElvishJerricco | yea, I know it's more confusing, which is a good argument against it | 18:04:03 |
| emily | I don't think you can get anyone to expect that renaming their SSH host key affects the security properties of a rollback | 18:04:14 |
| ElvishJerricco | and you've made a fairly convincing point about generational secrets not being such an issue because rollbacks are always a security risk | 18:04:40 |
| ElvishJerricco | but I'm still convinced I don't want encrypted secrets in the store | 18:05:12 |
| ElvishJerricco | like, if encrypted forms of someone's iCloud photo library were publicly accessible on Apple's servers, I think they'd be rightly criticized for the leak, even if the files are hopefully useless | 18:05:57 |
| ElvishJerricco | and of course in the case of agenix that's more analogous to publishing your git repo with your age encrypted secrets in it to github (which many people do) rather than being readable by all users on one system | 18:06:46 |
| emily | people with that level of paranoia shouldn't let other users access the host filesystem, though | 18:07:19 |
