From: dac.override@gmail.com (Dominick Grift) Date: Sun, 21 Aug 2016 21:33:23 +0200 Subject: [refpolicy] Syncthing Policy Module In-Reply-To: <2350b430-aea2-56a8-54db-e18375df537e@gmail.com> References: <20160821101051.GA2400@meriadoc.perfinion.com> <2350b430-aea2-56a8-54db-e18375df537e@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/21/2016 08:54 PM, Dominick Grift wrote: > 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. > Actually I am not sure if this would be technically possible in reference policy. It might be. See if the compiler would accept it. But even if its technically possible, it sets a precedent that I am not sure would be acceptable to others. > 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/d38f07da/attachment-0001.bin