From: rfkrocktk@gmail.com (Naftuli Tzvi Kay) Date: Sun, 21 Aug 2016 11:50:22 -0700 Subject: [refpolicy] Syncthing Policy Module In-Reply-To: <20160821101051.GA2400@meriadoc.perfinion.com> References: <20160821101051.GA2400@meriadoc.perfinion.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com > > Does it put things in one dir by default? eg dropbox only uses > ~/Dropbox/ so in the policy for that I did not need to give it perms for > all files. I dont know how syncthing works tho so not sure if thats > doable in this case. Syncthing can sync any directory given to it in its configuration. It's not like Dropbox in that you can have multiple synced directories. This is why I gave it access to everything in user home. If there's a way for me to further prevent it from syncing things like ~/.gnupg and ~/.ssh, lemme know, but my understanding that access once granted is hard if not impossible to remove, and I don't know if there's an attribute for "non-security-related homedir stuff." I'll personally probably be using it to sync ~/Documents and ~/Music across my machines. How common is this? I'd probably just let it bind and connect to only > those 3 sets of ports and then if the user wants to use a different port > they could add the definition with semanage port --add. Alternatively > allow the three ports by default and have connecting to all ports behind > a boolean. A Syncthing process must at least bind the following: 1. 0.0.0.0:22000 for TCP transferring and communication. 2. 0.0.0.0:21027 for UDP discovery of other nodes. 3. 127.0.0.1:8384 for TCP web admin UI. I could be wrong, but I don't see a way for me to limit the admin socket to only be node_lo_t, which is something I'd like to do as they don't recommend having that listen to any non local interfaces. A Syncthing process must be able to communicate with at least the following: 1. http_port_t: it contacts its own update site to check if it's running the most up-to-date version of the software. There may be a command-line flag to disable update checks, but if you have Syncthing installed in your homedir, it will attempt to download and upgrade itself automatically, which I may not have handled properly here. I might need a transition for it to be able to relabel the created file if it's not handled by the file contexts properly. 2. http_port_t: some of the remote registry servers are running on port 443 and other ports. Their port numbers seem hard to predict. 3. syncthing_discovery_port_t: communicate with other Syncthing servers and locate transport. 4. syncthing_port_t: transfer content over TLS. We have the whole infrastructure for this in the gentoo policy. It was > previously not upstreamed but came up again in the last few weeks for > another policy too so I think I will clean and upstream the main parts > for this to refpol. Dominick already put a note on the github PR about the > optional_policy( config_home_t part and that its not in refpol. I didnt > actually realize redhat had types for that stuff too now. The names are > different from the gentoo ones may well change again when I upstream it. > Drop the config_home_t stuff for now and we'll revisit it later. ?I can use ?what he recommended, which is gnome_config_filetrans . If that gets upstreamed, that'd probably be good. Should I just not include that for now? I think Dominick is saying to change to that, but should I just hold off for now? ?In general you dont have to worry about things like this. eg the apache > policy just serves out of /var/www/ and if for some reason the admin > wants to serve out of a random dir the admin would just add an fcontext > with semanage themselves. If you tried to forsee every single > configuration there would be a trillion booleans for each program. It > should definitely work out of hte box for the default config and maybe a > few other very common setups but dont worry about /mnt/ or /srv etc.? ?Great, sounds good.? Thanks, - Naftuli Tzvi On Sun, Aug 21, 2016 at 3:10 AM, Jason Zaman wrote: > On Sun, Aug 21, 2016 at 12:31:55AM -0700, Naftuli Tzvi Kay via refpolicy > wrote: > > Hello, > > This is my first post here, but I've done a fair bit of work on getting > > policy support for Syncthing working. I have > > submitted the following pull requests: > > Glad to see it :D > > > Add Syncthing Support to Policy: > > https://github.com/TresysTechnology/refpolicy/pull/37 > > Syncthing Policy Module: > > https://github.com/TresysTechnology/refpolicy-contrib/pull/26 > > > > I'd love to hear feedback, improvements, comments, criticisms. > > > > Currently, the policy will let Syncthing do most basic things it'll need > to > > do by default: > > > > - Manage all user home files/dirs/etc. > > Does it put things in one dir by default? eg dropbox only uses > ~/Dropbox/ so in the policy for that I did not need to give it perms for > all files. I dont know how syncthing works tho so not sure if thats > doable in this case. > > > - Bind to the 3 different ports required for Syncthing to function > > (admin, transfer, discovery ports). > > - Connect to arbitrary remote hosts on arbitrary ports (ie: remote > > Syncthing servers might be listening on non-standardized ports to get > > around firewall restrictions etc.). > > How common is this? I'd probably just let it bind and connect to only > those 3 sets of ports and then if the user wants to use a different port > they could add the definition with semanage port --add. Alternatively > allow the three ports by default and have connecting to all ports behind > a boolean. > > > - Allow user_u, staff_u, and unconfined_u to run Syncthing. > > > > Some things I'd like to have it do that I haven't figured out yet: > > > > - Standardize some way of managing syncthing_config_home_t as a subset > > of config_home_t, which doesn't seem to have been standardized in the > > reference policy (Fedora has the type, nobody else seems to). > > We have the whole infrastructure for this in the gentoo policy. It was > previously not upstreamed but came up again in the last few weeks for > another policy too so I think I will clean and upstream the main parts > for this to refpol. Dominick already put a note on the github PR about the > optional_policy( config_home_t part and that its not in refpol. I didnt > actually realize redhat had types for that stuff too now. The names are > different from the gentoo ones may well change again when I upstream it. > Drop the config_home_t stuff for now and we'll revisit it later. > > > - Supply booleans for cases I haven't imagined yet (possibly serving > > files out of /mnt or /srv? would anyone really want to run this as > root? > > etc.) > > In general you dont have to worry about things like this. eg the apache > policy just serves out of /var/www/ and if for some reason the admin > wants to serve out of a random dir the admin would just add an fcontext > with semanage themselves. If you tried to forsee every single > configuration there would be a trillion booleans for each program. It > should definitely work out of hte box for the default config and maybe a > few other very common setups but dont worry about /mnt/ or /srv etc. > > -- Jason > > > > > Please send feedback, I'll happily refactor and rewrite accordingly. > > > > Thanks, > > - Naftuli Tzvi > > > _______________________________________________ > > refpolicy mailing list > > refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160821/5ce72436/attachment.html