| 27 Sep 2024 |
 hexa | no | 14:50:38 |
|  @austreelis:the-apothecary.club left the room. | 16:09:07 |
| 28 Sep 2024 |
|  @majiir:matrix.org left the room. | 00:11:31 |
 undltd | How can I verify that a certain port is not "open" on a certain interface / ip on my machine? Like, how can I actually test it without physically going to another machine and nmapping/etc? | 11:14:29 |
 f0x | In reply to @setthemfree:matrix.org
How can I verify that a certain port is not "open" on a certain interface / ip on my machine? Like, how can I actually test it without physically going to another machine and nmapping/etc? with netstat or ss | 11:48:54 |
 aloisw | That doesn't take the firewall into account. | 11:53:24 |
| f0x | In reply to @aloisw:kde.org
That doesn't take the firewall into account. is there anything that does, from the local machine? | 13:36:23 |
 clefru | In reply to @f0x:pixie.town
is there anything that does, from the local machine? Put nmap into a docker container maybe? That should pass the firewall if I recall correctly. | 13:49:08 |
 philipp | I don't think there is a universal answer since firewalls rules are more complex than just "port open or closed". | 15:15:29 |
| 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 |
