16:00:16 <meskio> #startmeeting tor anti-censorship meeting
16:00:16 <MeetBot> Meeting started Thu Sep  4 16:00:16 2025 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:16 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:21 <meskio> hello everybody!!!!
16:00:26 <meskio> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:28 <meskio> ask me in private to give you the link of the pad to be able to edit it if you don't have it
16:00:30 <meskio> I'll wait few minutes for everybody to add you've been working on and put items on the agenda
16:00:45 <shelikhoo> hi~hi~
16:02:04 <meskio> can I remove the topic from last week about webtunnel setuid or is there something more to discuss there?
16:02:21 <shelikhoo> please keep it for the moment
16:02:25 <meskio> ok
16:02:37 <shelikhoo> it is connected to the first topic of this week
16:02:42 <meskio> let's start with the first one in the list then
16:02:57 <shelikhoo> yes!
16:03:06 <meskio> Check webtunnel bridge counts again
16:03:36 <meskio> (sorry, I haven't read the logs of the last meeting yet)
16:03:42 <shelikhoo> last week we discussed whether we wants to have a setuid binary in webtunnel bridge container image to automate the steps to fix state fike permissions
16:04:02 <shelikhoo> last week we discussed whether we wants to have a setuid binary in webtunnel bridge container image to automate the steps to fix state file permissions
16:04:59 <shelikhoo> on 2025-08-21 there was 3001 webtunnel bridge related logs
16:05:19 <shelikhoo> and on 2025-09-02 there was 2900 webtunnel bridge related logs
16:05:40 <meskio> ohhh, I see
16:06:10 <meskio> I tend to make containers that doesn't force a UID from inside, so users can set them from outside if they want by docker run --user UID
16:06:43 <meskio> I forgot we were setting the user that runs this container
16:06:51 <shelikhoo> yes, in this case, the docker compose file does have uid set
16:07:02 <meskio> I see we do the same in obfs4-bridge
16:07:05 <shelikhoo> and sadly due to debian version upgrade, the uid was changed
16:07:11 <dcf1> aha, meskio maybe you know a general docker-native solution to this problem? should we be doing it a different way?
16:07:12 <meskio> fun
16:07:29 <shelikhoo> and created a file permission issue
16:07:52 <meskio> dcf1: I'm not sure how to do it so it will upgrade gracelly
16:07:55 <shelikhoo> I did pushed an update to fix the uid to the numbers before debian upgrade
16:08:09 <shelikhoo> I did pushed an update to pin the uid to the numbers before debian upgrade
16:08:10 <dcf1> meskio: ok
16:08:23 <shelikhoo> but it will not fix permission if it is already broken
16:08:33 <shelikhoo> which would require a setuid binary to do so
16:08:48 <shelikhoo> which we don't wants to do unless it is strictly necessary
16:09:03 <shelikhoo> we see there is still a maybe 2.4% loss of bridge
16:09:24 <meskio> we could detect the problem and print out instructions to fix it manually
16:09:49 <meskio> but with your fix, will everybody be affected or only the ones that upgraded to the broken one before your fix?
16:09:50 <shelikhoo> yes, we have provided that instruction already
16:10:43 <shelikhoo> there is an email from gus about fixing permissions manually titled: "[tor-relays] [bridge operators] Fix required for WebTunnel docker bridges"
16:11:36 <shelikhoo> with the fix, only users who installed the bridge while the image has a unpinned uid is affected
16:11:45 <meskio> we could use this oportunity to remove the `USER` pinning in the dockerfile, but I'm not sure how much this will break extra things
16:11:57 <shelikhoo> or those who have manually chowned
16:12:21 <shelikhoo> I think we don't have USER pinning in docker file
16:12:34 <shelikhoo> the USER instruction is done in docker compose
16:12:39 <shelikhoo> let's me check again
16:12:56 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/blob/4a6914d6962b813cd3f09a4faed8643d8dafee8c/Dockerfile
16:13:16 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/blob/4a6914d6962b813cd3f09a4faed8643d8dafee8c/release/container/docker-compose.yml
16:13:34 <meskio> ohh, nice, I see
16:13:35 <shelikhoo> yes, the switch user instruction is in the docker compose file, not docker file
16:14:39 <shelikhoo> so our choice is about whether to deploy the setuid binary or not
16:14:41 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/merge_requests/33
16:14:49 <meskio> we could hardcode a UID number in the docker-compose, but that will still not fix the problem for existing deployments
16:15:53 <shelikhoo> yes... we have already hardcoded that UID in docker compose as well
16:16:17 <shelikhoo> but we didn't force user to run container with uid=101
16:16:26 <meskio> I think is not that bad idea to do the setuid, most containers around assume root permitions
16:16:39 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/blob/4a6914d6962b813cd3f09a4faed8643d8dafee8c/Dockerfile#L28
16:16:52 <meskio> anyway the tor and webtunnel and other processes will not have root permitions, only the script that fixes them, isn't it?
16:17:13 <shelikhoo> yes, only the script will have that permission via sudo
16:18:56 <shelikhoo> if c-tor have an exploit, and attackers gained interactive shell, it might use exploits in sudo or this script to gain root
16:19:25 <shelikhoo> (or if webtunnel binary have an exploit )
16:20:08 <meskio> I think this is not that bad as a solution
16:21:48 <shelikhoo> okay, so do we wants to merge and deploy this, or wait to see if the bridge count can recover further?
16:22:22 <meskio> so we might have lost 100 bridges
16:22:52 <meskio> I would deploy it, hopefully we recover those bridges
16:22:54 <shelikhoo> It is not really bridges counts per say
16:23:05 <meskio> and we can remove the setuid in a month or something
16:23:06 <shelikhoo> it was kind of tick message from bridges
16:23:29 <meskio> ahh, I see
16:23:38 <shelikhoo> oh yes, we can always remove this later
16:23:44 <meskio> true, we don't have 3k webtunnel bridges
16:24:30 <shelikhoo> but yes, we could merge this and then remove it in maybe 6 weeks
16:24:44 <meskio> +1
16:25:12 <shelikhoo> I will proceed with this unless there is any objects now....
16:25:22 <shelikhoo> BTW, because the container image is unsigned
16:25:47 <shelikhoo> this don't really create something that people can mount a downgrade attack
16:26:17 <shelikhoo> since the container's content is not signature pinned in the first place
16:26:47 <meskio> yes
16:27:12 <meskio> AFAIK docker hub only signs "official images", and they sign them on the server side
16:27:24 <meskio> I don't think you can push any kind of signatures into docker
16:27:34 <meskio> but I haven't look into this for years, maybe now is different
16:27:50 <shelikhoo> there are some custom solutions, but we are not using them
16:28:08 <shelikhoo> https://docs.sigstore.dev/cosign/signing/signing_with_containers/
16:29:04 <Shelikhoo[mds]> EOF
16:29:22 <meskio> interesting, I wonder how many people uses this kind of things
16:29:40 <meskio> anyway, we don't need to figure out image signatures now
16:29:46 <meskio> we have a solution for this problem now
16:29:48 <meskio> thanks
16:29:55 <meskio> anything more for today?
16:30:51 <Shelikhoo[mds]> nothing from me
16:31:15 <meskio> cool, I guess we are done
16:31:23 <meskio> just a reminder that we have a reading group next week
16:31:40 <meskio> talk to you next week
16:31:42 <meskio> #endmeeting