--- Log opened Thu Dec 26 00:00:29 2019 |
00:47 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
01:10 | | Degi [Degi@Nightstar-oiqvvr.dyn.telefonica.de] has quit [Operation timed out] |
01:12 | | Degi [Degi@Nightstar-ua966j.dyn.telefonica.de] has joined #code |
01:13 | | gnolam [quassel@Nightstar-csto10.cust.bahnhof.se] has quit [[NS] Quit: Z?] |
01:22 | <@sshine> | I'm building a WHOIS client library, and I learned that IANA releases new top-level domains on a rolling basis now: https://data.iana.org/TLD/tlds-alpha-by-domain.txt |
01:22 | <@sshine> | so whereas the Linux program 'whois' has a hardcoded list of "new" gTLDs, the IANA support said this was a bad way to go about it. |
01:23 | <@sshine> | apparently new gTLDs must have whois.nic.<tld>:43 hooked up |
01:25 | <@sshine> | so I'm contemplating two strategies: (1) just try to connect to whois.nic.<tld>:43 and possibly produce a network error. (2) do a recursive 'whois -h whois.iana.org <tld>', find 'whois: whois.nic.<tld>' and then do another 'whois -h whois.nic.<tld>' now knowing this is right. |
01:26 | <@sshine> | the old version of the WHOIS library I'm writing does something similar to (1), which is to connect blindly to <tld>.whois-servers.net:43, which is kinda unknown who runs those, I think, so I don't like that it does that. |
01:31 | <@sshine> | the drawback of (1) is that it will give a network error rather than say "I don't know how to do that." and the drawback of (2) is that every newer TLD will have a slower lookup. |
01:31 | <@sshine> | I'm going to go with (1) for now, I think. I'm actually going to depend on the performance of this library. |
01:32 | <@sshine> | (I was thinking an even better approach would be a cache layer, but since this is a Haskell library, I'd rather not deploy a file cache, since that's super strange. if it were a command-line program, that'd make sense, I guess.) |
02:17 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: WeeChat 2.6] |
02:18 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
02:18 | | mode/#code [+ao ToxicFrog ToxicFrog] by ChanServ |
02:48 | | Kindamoody is now known as Kindamoody[zZz] |
02:56 | <&[R]> | Thanks for letting me know the protocol changed |
02:56 | | * [R] was going to build a server |
04:12 | | celticminstrel [celticminst@Nightstar-0p84vo.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
05:35 | <@macdjord|slep> | sshine: Can you store the 'yes this TLD exists' result globally? Then you only have a slowdown the first time a given TLD is /ever/ used and can use the faster check method thereafter. |
05:35 | <&McMartin> | That implies trusting end users more than you probably would like to. Per-user databases are probably safer |
05:36 | <@Alek> | that may well be true. |
05:39 | <@macdjord|slep> | McMartin: Depends. You could make the central DB world-readable but only writable by the appropriate service account, then have the do-expensive-check code in a runnable-by-anyone-but-runs-as-the-service-account executable. |
05:39 | <&McMartin> | That last step is exactly the one I'm wary about |
05:40 | | macdjord|slep is now known as macdjord |
05:42 | <@macdjord> | McMartin: How so? It's an executable, it takes a TLD, it does the check, if the check passes it adds said TLD to the 'yes this really exists' file. Anyone can /trigger/ it with whatever TLD they wish to check, but they cannot force it to record a TLD which does not pass the check. |
05:44 | <&McMartin> | Basically two concerns |
05:44 | <&McMartin> | (a) any privilege escalation is part of an attack surface, which this thus is |
05:44 | <&McMartin> | (b) if it's annoyingly expensive, letting users do it can start being a DoS vector maybe |
05:45 | <@macdjord> | Re (B): Not in any way that isn't equally possible if they have their own DBs; they can run the expensive check as often as they want then. |
05:47 | <@macdjord> | As for (A), I was under the impression this was a Solved Problem in standard Unix security, and that this sort of script was the standard mechanism for allowing users to do in particular limited ways things that only root can do in the general case. |
05:48 | <&McMartin> | Yes, and the standard attack is "the system program has a bug and it is possible to ask for strange things that trigger the bug and let you do unintended things on the attacker's behalf with system privileges" |
05:50 | <@macdjord> | E.g. allowing people to mount temp drives without allowing them to mount or unmount volumes in general: create a script which does Exactly That, make it root-owned, world-executable but only-owner-readable-&-writable, and set it runs-as-owner. |
05:51 | <@macdjord> | McMartin: Well, yes. But in this case it takes exactly one input - a TLD to test - and has one privileged action - append that input to the Valid TLDs List file. That's a fairly small attack surface. |
06:09 | <&[R]> | <macdjord> E.g. allowing people to mount temp drives without allowing them to mount or unmount volumes in general: create a script which does Exactly That, make it root-owned, world-executable but only-owner-readable-&-writable, and set it runs-as-owner. <-- script? nope. |
06:09 | <&[R]> | ; sudo id; echo \#!/usr/bin/env xs\nid > test; sudo chown root.root test; sudo chmod 1755 test; ./test |
06:09 | <&[R]> | uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log) |
06:09 | <&[R]> | uid=10000(R) gid=10000(R) groups=10000(R),10(wheel) |
06:10 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has joined #code |
06:10 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
06:10 | <@macdjord> | [R]: Well, okay. Not a script. It would have to be a compiled executable, IIRC. |
06:11 | <&[R]> | Yes |
06:11 | <&[R]> | Though both sudo and doas provide means to run something as another user securely |
06:12 | <&[R]> | So it's recommended to try and use those systems instead |
06:12 | <&McMartin> | Mmm. |
06:12 | <&McMartin> | And in that case, you use an extremely restricted user to do the work, and then sudo over to that |
06:12 | <&McMartin> | So that it's a downpriv |
06:12 | <&[R]> | Yeah |
06:13 | <&McMartin> | Not awful, still means you need to be an admin to install the service. |
06:13 | <&McMartin> | Which I hadn't considered before but have been reminded is actually sometimes a problem |
06:14 | <&[R]> | Same results with `chmod u=rwxs,go=rx` BTW (1755 isn't the correct flags? +s wasn't set) |
06:15 | <&[R]> | Ah, 4755 |
06:19 | <@macdjord> | [R]: The mechanism is not really critical. What matters is you can set up your 'check this TLD' code in such a way that anyone can invoke it and the results are cached in a global location, but users /cannot/ edit the cache without passing through the check mechanism. |
06:20 | <&[R]> | Yeah |
06:20 | <&[R]> | In which case I'd probably just have it be a daemon that listens on a socket (possible UNIX one) |
06:20 | <&[R]> | possibly* |
06:21 | <@macdjord> | Also works. |
06:21 | | * macdjord ponders |
06:22 | <@macdjord> | The one attack I would worry about is, can Mallory redirect the 'Hey NIC, is this a real domain?' query in some way and return a false 'Yes it is!' answer which then gets cached? |
06:23 | <@macdjord> | E.g. by connecting to a wifi network they control? |
06:35 | <&[R]> | Sure... but in what setup would it be reasonable that a user could do that, that it would matter, AND I.T. doesn't just make it ask an internal server that does all the caching. |
06:36 | <&[R]> | Because you could do any sort of MITM and have the same issue |
06:36 | <&[R]> | Not like there's a whoiss protocol |
07:13 | <@macdjord> | Plus, even if you /do/ get a fake domain cached, that just means that future queries return 'network error' instead of 'no such TLD'. |
09:13 | | macdjord [macdjord@Nightstar-bt331u.dsl.bell.ca] has quit [[NS] Quit: Deep inside, every housecat believes themself to be just a temporarily embarrassed tiger.] |
09:19 | | macdjord [macdjord@Nightstar-bt331u.dsl.bell.ca] has joined #code |
09:19 | | mode/#code [+o macdjord] by ChanServ |
09:21 | | macdjord [macdjord@Nightstar-bt331u.dsl.bell.ca] has quit [[NS] Quit: Deep inside, every housecat believes themself to be just a temporarily embarrassed tiger.] |
09:26 | | macdjord [macdjord@Nightstar-bt331u.dsl.bell.ca] has joined #code |
09:26 | | mode/#code [+o macdjord] by ChanServ |
09:29 | | bluefoxx [fuzzylombax@Nightstar-gmbj85.vs.shawcable.net] has quit [Ping timeout: 121 seconds] |
10:16 | | Kindamoody[zZz] is now known as Kindamoody |
11:23 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
11:43 | | macdjord is now known as macdjord|slep |
12:22 | | Kindamoody is now known as Kindamoody|afk |
13:01 | | gnolam [quassel@Nightstar-csto10.cust.bahnhof.se] has joined #code |
13:01 | | mode/#code [+o gnolam] by ChanServ |
13:31 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
15:28 | | Kindamoody|afk is now known as Kindamoody |
16:51 | | celticminstrel [celticminst@Nightstar-0p84vo.dsl.bell.ca] has joined #code |
16:51 | | mode/#code [+o celticminstrel] by ChanServ |
17:21 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
21:05 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
22:50 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
23:57 | | bluefoxx [fuzzylombax@Nightstar-gmbj85.vs.shawcable.net] has joined #code |
--- Log closed Fri Dec 27 00:00:30 2019 |