From: dac.override@gmail.com (Dominick Grift) Date: Sun, 21 Aug 2016 20:54:26 +0200 Subject: [refpolicy] Syncthing Policy Module In-Reply-To: References: <20160821101051.GA2400@meriadoc.perfinion.com> Message-ID: <2350b430-aea2-56a8-54db-e18375df537e@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/21/2016 08:50 PM, Naftuli Tzvi Kay wrote: > Dominick, > I can replace that with gnome_config_filetrans. Yes though I am not sure that this would be acceptable either. It would be technically possible. I will leave it to others to decide on that. My comment was merely on illegal direct references to external types. > > Thanks, > - Naftuli Tzvi > > On Sun, Aug 21, 2016 at 3:14 AM, Dominick Grift via refpolicy < > refpolicy at oss.tresys.com> wrote: > >> 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 >> >> >> _______________________________________________ >> 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/d4affe43/attachment.bin