code logs -> 2019 -> Thu, 26 Dec 2019< code.20191225.log - code.20191227.log >
--- 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
code logs -> 2019 -> Thu, 26 Dec 2019< code.20191225.log - code.20191227.log >

[ Latest log file ]