Bug 1115547 - kde-connect: document/make firewall hole for it
Summary: kde-connect: document/make firewall hole for it
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-connect
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1257699
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-02 15:09 UTC by Richard Z.
Modified: 2015-10-09 10:28 UTC (History)
12 users (show)

Fixed In Version: kde-connect-0.8-9.fc23 kde-connect-0.8-9.fc22
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-01 16:04:12 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
KDE Software Compilation 337250 None None None Never

Description Richard Z. 2014-07-02 15:09:19 UTC
KDE Connect requires ports 1714-1764 open. Either make a hole (semi-)automatically or at least provide instructions how to do it.

When the local interface is "192.168.2.0/8", something like this will work and cause the minimal required opening:

 # firewall-cmd --permanent --add-rich-rule 'rule  family="ipv4" source address="192.168.2.0/8"  port port="1714-1764" protocol="tcp"  accept'
 # firewall-cmd --permanent --add-rich-rule 'rule  family="ipv4" source address="192.168.2.0/8"  port port="1714-1764" protocol="udp"  accept'
success

Comment 1 Rex Dieter 2014-07-03 13:42:13 UTC
Looks like an xml snippet dropped into /usr/lib/firewalld/services is one approach (like what cockpit packaging currently does).

I queried -devel list for advice on best practices wrt packaging:
https://lists.fedoraproject.org/pipermail/devel/2014-July/200790.html

Comment 2 Richard Z. 2014-07-03 21:38:21 UTC
(In reply to Rex Dieter from comment #1)
> Looks like an xml snippet dropped into /usr/lib/firewalld/services is one
> approach (like what cockpit packaging currently does).
> 
> I queried -devel list for advice on best practices wrt packaging:
> https://lists.fedoraproject.org/pipermail/devel/2014-July/200790.html

Seems that /usr/lib/firewalld/services doesn't provide any easy way to limit the access to a particular network. Having devices from all over the world trying to pair with my workstation may be too permissive. 

From my /etc/firewalld/zones/public.xml : 

  <rule family="ipv4">
    <source address="192.168.2.0/8"/>
    <port protocol="udp" port="1714-1764"/>
    <accept/>
  </rule>

- this is safe enough for me. However other routers will have other private networks which needs to be configured based on local setup.

One way to do that would be to call a script from /etc/NetworkManager/dispatcher.d/ - get IP/Netmask from there

ip=`/sbin/ifconfig | grep -A 4 $1 | awk '/inet / { print $2 } ' | sed -e s/addr://`
netmask=`/sbin/ifconfig | grep -A 4 $1 | awk '/inet / { print $4 } ' | sed -e s/addr://`

and configure the firewall as needed.

Comment 3 Jiri Popelka 2014-07-04 10:22:18 UTC
(In reply to Richard Zidlicky from comment #2)
> Seems that /usr/lib/firewalld/services doesn't provide any easy way to limit
> the access to a particular network.

If <source address="192.168.2.0/8"/> isn't easy enough, how would you imagine such 'easy way' ?

> ip=`/sbin/ifconfig | grep -A 4 $1 | awk '/inet / { print $2 } ' | sed -e
> s/addr://`

Please don't use ifconfig (bug #687920), something like
ip -4 -o addr show $1 | awk '{ print $4 }'
should do the trick too.

Comment 4 Richard Z. 2014-07-04 10:36:11 UTC
(In reply to Jiri Popelka from comment #3)
> (In reply to Richard Zidlicky from comment #2)
> > Seems that /usr/lib/firewalld/services doesn't provide any easy way to limit
> > the access to a particular network.
> 
> If <source address="192.168.2.0/8"/> isn't easy enough, how would you
> imagine such 'easy way' ?

the problem is that not all routers use the 192.168.2.* address range, some routers or repeaters use something in the 10.xx range, some computers may have more interfaces that could be used.

There is  no way to know that at packagaing time so it seems a purely static rule can't do that.

Given that some computers will have more than one interfaces and it may be not desirable to allow pairing and firewall punching for all local networks completely unattended there probably should be some user interaction - selecting the network(s) that should be allowed for kde connect operation.

Comment 5 Martin Bříza 2014-07-04 11:16:59 UTC
(In reply to Richard Zidlicky from comment #4)
> the problem is that not all routers use the 192.168.2.* address range, some
> routers or repeaters use something in the 10.xx range, some computers may
> have more interfaces that could be used.

The local area subnets are still well known, that's not a problem.
What I see as problematic is when you are on a nontrusted network. I know there are zones in firewalld but I have no idea how they are set/switched.

Comment 6 Richard Z. 2014-07-05 15:05:18 UTC
(In reply to Martin Bříza from comment #5)

> The local area subnets are still well known, that's not a problem.

known at runtime yes, but not at packaging time so I don't see how prepackaged   /usr/lib/firewalld/services rules could be used (other than opening a hole larger than necessary) - am I missing something?

> What I see as problematic is when you are on a nontrusted network. I know
> there are zones in firewalld but I have no idea how they are set/switched.

Switching zones works but at this time I don't see how the firewalld zones and rules could do what is needed here with prepackaged rules alone.

The alternative approach - when a network comes up ask user if KDE connect should bind on the network and punch a fitting hole into the firewall at the same time.

Comment 7 Richard Z. 2014-07-08 22:49:02 UTC
Opened upstream report to query about the trusted/untrusted networks issue and clarify how to integrate with distribution specific firewalls.

https://bugs.kde.org/show_bug.cgi?id=337250

Comment 8 Martin Bříza 2014-07-09 12:50:05 UTC
(In reply to Richard Zidlicky from comment #6)
> (In reply to Martin Bříza from comment #5)
> 
> > The local area subnets are still well known, that's not a problem.
> 
> known at runtime yes, but not at packaging time so I don't see how
> prepackaged   /usr/lib/firewalld/services rules could be used (other than
> opening a hole larger than necessary) - am I missing something?

Reserved local area subnets are defined by RFC1918, so they are known at packaging time...

Comment 9 Richard Z. 2014-07-09 14:20:28 UTC
(In reply to Martin Bříza from comment #8)

> Reserved local area subnets are defined by RFC1918, so they are known at
> packaging time...

that would work. The firewall hole could be a lot tighter though using only the specific link-local subnet.

Comment 10 Kevin Kofler 2014-07-11 17:54:55 UTC
Is it not against Fedora policies to open up the firewall that way by default?

Comment 11 Rex Dieter 2014-09-24 20:00:53 UTC
updating summary (to at least document what is required)

Comment 12 Kevin Kofler 2014-09-24 21:16:20 UTC
> 192.168.2.0/8

It was pointed out on #fedora-kde IRC that that is NOT what you want, you want /24, not /8 here. The number is the length of the prefix, not of the suffix.

Comment 13 Rex Dieter 2015-06-05 19:11:04 UTC
fyi, for documentation purposes, here's where the port range comes from,
https://community.kde.org/KDEConnect#Troubleshooting

Comment 14 Fedora Update System 2015-09-23 14:45:22 UTC
kde-connect-0.8-9.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16512

Comment 15 Fedora Update System 2015-09-23 14:47:01 UTC
kde-connect-0.8-9.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16514

Comment 16 Fedora Update System 2015-09-24 03:32:00 UTC
kde-connect-0.8-9.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update kde-connect'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16512

Comment 17 Fedora Update System 2015-09-25 21:21:20 UTC
kde-connect-0.8-9.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update kde-connect'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16514

Comment 18 Fedora Update System 2015-10-01 16:04:09 UTC
kde-connect-0.8-9.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2015-10-09 10:28:16 UTC
kde-connect-0.8-9.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.