16:00:46 <shelikhoo> #startmeeting tor anti-censorship meeting
16:00:46 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:46 <shelikhoo> editable link available on request
16:00:46 <MeetBot> Meeting started Thu Aug 28 16:00:46 2025 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:46 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:49 <shelikhoo> hi~hi~
16:01:41 <onyinyang> hello, I'm here afterall :)
16:02:00 <shelikhoo> hi~onyinyang
16:02:08 <cohosh> hi
16:03:25 <shelikhoo> okay I think we can start with the first topic
16:03:56 <shelikhoo> WebTunnel container's setuid volume migration trade-off
16:03:56 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge
16:04:34 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/33
16:04:42 <shelikhoo> sorry for broken link
16:05:16 <shelikhoo> so what happen was there is a debian distro upgrade between these two version
16:05:29 <shelikhoo> and sadly, the uid assigned to debian-tor user was changed
16:05:48 <shelikhoo> as a result, the persistent volume's file permission was broken
16:06:27 <shelikhoo> I have already provided a manual fix instruction yesterday, which have diffused with the help from gus
16:06:59 <shelikhoo> but we could take another step further to use a setuid binary to fix this issue in the container automatically
16:07:46 <shelikhoo> (The uid and gid is already pinned with https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/32)
16:08:07 <shelikhoo> so if the user has not manually fixed the issue
16:08:32 <shelikhoo> or recently freshly installed webtunnel container in the last week
16:08:47 <shelikhoo> this setuid script is not necessary
16:09:06 <shelikhoo> but for those who did need to fix the file owner
16:09:41 <shelikhoo> this tool can fix the problem without user intervention
16:10:10 <shelikhoo> with the cost of adding a setuid binary in the container
16:10:14 <shelikhoo> over
16:10:25 <dcf1> I am shocked tat Docker doesn't have some built-in facility for uid matching?
16:11:20 <shelikhoo> i failed to find it... there are some tools written by others but they too complex for this simple task
16:11:26 <dcf1> Is that (uid matching) what MR !32 was, and !33 is a workaround for existing deployments?
16:11:56 <shelikhoo> yes, 32 is to pin the uid:gid to 101:101
16:12:09 <dcf1> Oh, so then that's not what I was thinking.
16:12:35 <shelikhoo> and 33 is to fix the owner if the uid/gid is not 101
16:13:31 <shelikhoo> so if the user has installed a bullseye version which has uid = 101
16:13:53 <shelikhoo> and then upgrade to a unpinned bookworm version it will break
16:14:24 <shelikhoo> if user installed a unpinned bookworm version and then upgrade to a pinned bookworm version it will break
16:15:43 <dcf1> You are rigt to bring this up for discussion, because it seems like the kind of thing that has a releatively clear workaround that we may nevertheless come to regret
16:15:54 <shelikhoo> but otherwise it will just work without this setuid binary
16:16:30 <shelikhoo> there are two choices: we either have this setuid binary and user won't need to do anything it will just work
16:17:02 <shelikhoo> or we don't have this binary, and user will need to manually fix the problem with command line
16:17:15 <shelikhoo> which we have already provide a instruction
16:17:54 <shelikhoo> yes, dcf1, the issue is that having a setuid binary is kind of... scary
16:19:14 <cohosh> i am surprised that you can just do that with docker
16:19:18 <shelikhoo> it could create a security issue, despite being very convenient
16:19:49 <shelikhoo> yes, I thought docker would have no new privilege set, but it didn't
16:20:35 <cohosh> i guess the safer path, which would require more effort, is to manually reach out to operators
16:20:41 <cohosh> but that only works if they included contact info
16:20:56 <dcf1> The downside of having a setuid binary in the container, I suppose, is that it potentially allows an attacker who has gained access to the container to escalate their level of access, perhaps by making system files be owned by debian-tor and overwriting them
16:21:49 <shelikhoo> this would allow attacker to promote them self from c-tor's debian-tor user to the root user in the container
16:22:08 <shelikhoo> and docker is not really a hard security boundary
16:22:57 <cohosh> do we have bridgestrap logs that would tell us how many webtunnel bridges are suffered from this problem and aren't fixed yet?
16:23:26 <shelikhoo> I think it is cannot be tested with bridgestrap
16:23:34 <shelikhoo> as the bridge will just go offline
16:24:23 <cohosh> oh right, so maybe collector data would give as approximate number
16:25:09 <shelikhoo> It should also be taken into consideration that I have never written a setuid binary or edited sudoers file before, so it is more likely there is an issue with it...
16:25:15 <cohosh> i only ask because if we find very few that have gone offline and not returned, maybe we don't need to worry about it
16:25:47 <shelikhoo> yes, we could also just monitor the amount of webtunnel bridges
16:26:24 <shelikhoo> this data should be available for rdsys
16:27:46 <cohosh> right, we could get a quick approximate number from https://metrics.torproject.org/collector.html#bridgedb-metrics
16:28:25 <dcf1> How did you find out about the problem? Was it reports from bridge operators?
16:29:29 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/52#note_3247669
16:29:37 <shelikhoo> gus reported this issue to me
16:31:07 <cohosh> sorry forget what i said about the bridgedb collector metrics, those wouldn't be the right ones, i think we'd need to look at the archived extra info descriptors
16:32:12 <dcf1> Maybe hack https://gitlab.torproject.org/dcf/snowflake-graphs and change the filter to accept webtunnel rather than snowflake bridges
16:33:14 <dcf1> If metrics.torproject.org is not up-to-date or high-resolution enough.
16:36:11 <shelikhoo> thanks I will have a look at it later
16:36:28 <shelikhoo> it seems I won't be able to inspect it live
16:37:13 <shelikhoo> so I think we could try to hold the merge request in review for a little while and get some info before pushing this setuid binary
16:37:15 <cohosh> so if we don't go the setuid route, our options are to try and reach operators and notify users to refetch working bridges perhaps?
16:37:28 <dcf1> actually, thi smay be something you can do in a quick-and-dirty way with grep from the descriptor tarball
16:37:47 <cohosh> dcf1: ah, count the lines with "webtunnel" in them?
16:38:08 <dcf1> yeah something like that
16:38:23 <shelikhoo> yes, gus have already sent an email to tor-relays mailing list
16:40:05 <dcf1> tar -O -xf bridge-extra-infos-2025-03.tar.xz | grep -B3 '^transport webtunnel' | grep '^published '
16:41:21 <dcf1> This will give a bunch of "published" timestamps for webtunnel bridges, which you could then bin by date. It won't do any deduplication by relay fingerprint, but it would be adequate if you assume that alsmot all bridges publish a constant number of times per 24 hours
16:41:46 <dcf1> I used 2025-03 because I have that file handy, but of course you would want to use a recently downloaded bridge-extra-infos-2025-08.
16:42:58 <shelikhoo> okay command running...
16:43:42 <shelikhoo> shelikhoo@shell-laptop:/run/shm$ tar -O -xf bridge-extra-infos-2025-08.tar.xz | grep -B3 '^transport webtunnel' | grep '^published '|grep 2025-08-21|wc -l
16:43:42 <shelikhoo> 3011
16:43:42 <shelikhoo> shelikhoo@shell-laptop:/run/shm$ tar -O -xf bridge-extra-infos-2025-08.tar.xz | grep -B3 '^transport webtunnel' | grep '^published '|grep 2025-08-27|wc -l
16:43:42 <shelikhoo> 2597
16:43:59 <shelikhoo> I will run it again next Monday too see if it recovers
16:45:44 <shelikhoo> this 2597 is before I published the uid gid pinning fix
16:46:24 <shelikhoo> so it should be as bad as it could get
16:47:45 <shelikhoo> that is everything from me about this topic
16:47:48 <dcf1> so tat's a decrease of about 14%
16:48:12 <cohosh> i know the user experience of a bridge not working is bad, but if users can still request new working ones, it's not too terrible
16:48:45 <dcf1> ok, so the plan is to take another sample from bridge metrics in 1 week?
16:49:09 <shelikhoo> yes, that is my suggestion
16:49:18 <cohosh> thank you for responding to this so quickly shelikhoo
16:50:11 <shelikhoo> thanks cohosh...
16:51:50 <shelikhoo> but anyway, I think that is everything I have about this topic..
16:52:40 <shelikhoo> anything more we would like to discuss today?
16:53:32 <shelikhoo> #endmeeting