@queerhackerwitch The reason I want to operate without privileges is not because I can't get them; I'm developing some security-paranoid software, and rule 1 of security paranoia is "try not to have privileges. The more privileges you have, the worse it is when you get pwned."

@queerhackerwitch So I'm at the point of maybe having a suid knock helper program that runs in a different process.

@jennamagius In this case though it’s not the software that needs privileges, it’s the admin during setup

@queerhackerwitch That's true, but I'm disappointed to have written a program that can do 99.9% of it's work with user privs, but isn't directly usable when you only have user privs.

@jennamagius That’s because those privileges have to keep the security of the rest of the system in mind. Those privileges aren’t normally available to users because they can be abused. This is why many services usually start as root and then drop their privileges after they’ve used them to set up what they need.

@queerhackerwitch I assure you I understand this, I'm not... new to computing. My argument is that "services should be visible to any unauthenticated anyone who looks for them, from anywhere" is an unreasonable default.

@jennamagius Sorry, I’m not making an assumption that you don’t understand, I’m just trying to get across another perspective on why others would consider this desired behavior. I spend most of my time working with network security so I’m forced to see both sides of the coin.

@queerhackerwitch Sure, I certainly understand that hidden services are more difficult to use than visible services, but I think running visible services should be an option for environments with enfranchised users and high security needs. I think the "visible services are more ergonomic" has translated excessively into "hidden services should not be possible" with respect to how our kernel infrastructure has developed.

@queerhackerwitch s/running visible services should be an option/running hidden services should be an option/

@queerhackerwitch It kinda seems to me like "We've got some great infrastructure in place for running discoverable, ergonomic services. It's called TCP. It runs great services you know and love, like HTTPS. People connect to HTTPS services on servers they don't know much about all the time." I don't feel like UDP needs to _be_ the same thing TCP is.

@queerhackerwitch The annoying thing about making a firewall rule is that interacting with the firewall is very different across different platforms. Plus, there's an information disclosure inherent in not sending the unreachable responses when you are an otherwise clearly existant system. The approach I'm going with is using raw sockets to recieve portknocks without causing the kernel to consider additional UDP ports "open", so it _keeps_ sending unreachable responses.

@queerhackerwitch knockd exists, and it shells out to iptables, but shelling out to iptables is fragile and miserable and I hate it >.> We can do better.

@queerhackerwitch Also, literally the first time I set up knockd my knock ports showed up in nmap -sU and you could find the knock sequence by brute-forcing permutations on five ports, which is fairly pathetic. I suspect that happens to pretty much everyone the first time they set up knockd.

@jennamagius it makes sense to need root privileges to be able to hide a service though, even as a one time thing to set up a firewall rule

@queerhackerwitch Kinda. I mean, it's not "hidden" from the admins of the box: it shows up in netstat. It's just hidden from people on the far side of the network. I kinda resent the notion that people on the far side of a network "have a right" to know what services you are running by default.

@jennamagius It’s not that they “have a right” it’s just from a protocol practicality point of view. It’s often better for a server to respond “nothing’s on this port, go away” than to remain silent and have the other end keep retrying (because there’s an assumption that the network can be unreliable).

@queerhackerwitch The thing is, anyone who should be accessing remote-access services on my network should have a-priori out-of-band knowledge about what services should and should not exist. There's no user that's like "Maybe there is not supposed to be a service here or maybe this is connectivity problems" because they should know FOR A FACT, BEFORE THEY START what services are and are not supposed to exist.