From: dac.override@gmail.com (Dominick Grift) Date: Sun, 21 Aug 2016 12:14:48 +0200 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 On 08/21/2016 12:10 PM, Jason Zaman via refpolicy 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. > My comment was not about config_home_t not being in refpolicy though. The issue I was trying to address is directly referencing external types. whether they are refpolicy specific or not. >> - 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 > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160821/41644a61/attachment.bin