Hello,
This is my first post here, but I've done a fair bit of work on getting
policy support for Syncthing <https://syncthing.org> working. I have
submitted the following pull requests:
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.
- 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.).
- 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).
- 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.)
Please send feedback, I'll happily refactor and rewrite accordingly.
Thanks,
- Naftuli Tzvi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160821/c7acf9ce/attachment.html
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 <https://syncthing.org> 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
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 <https://syncthing.org> 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
>
> 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
<https://github.com/fedora-selinux/selinux-policy/blob/rawhide-contrib/gnome.if#L433>.
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 <[email protected]> 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 <https://syncthing.org> 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
Dominick,
I can replace that with gnome_config_filetrans.
Thanks,
- Naftuli Tzvi
On Sun, Aug 21, 2016 at 3:14 AM, Dominick Grift via refpolicy <
[email protected]> 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 <https://syncthing.org> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160821/ce749f31/attachment-0001.html
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 <https://syncthing.org> 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
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 <https://syncthing.org> 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