Bug 699432

Summary: SoaS/Sugar spin needs additional firewall ports open for Salut to work.
Product: [Fedora] Fedora Reporter: Samuel Greenfeld <samuel>
Component: spin-kickstartsAssignee: Peter Robinson <pbrobinson>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: awilliam, bruno, kevin, martin, maxamillion, pbrobinson, satellitgo, simon, tflink, vanmeeuwen+fedora
Target Milestone: ---Keywords: Tracking
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-08 11:19:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Firewall configuration used for test endpoints
none
Packet Capture of failure to join shared activity
none
Failed invitation capture none

Description Samuel Greenfeld 2011-04-25 15:48:09 UTC
Description of problem:
The SoaS/Sugar spin kickstart only opens mDNS through Fedora's firewall.  But in order for telepathy-salut to work, Link-local XMPP (typically TCP/UDP 5298) should also be open, as well as possibly some more multicast support.

Since the Sugar UI does not provide an easy way to edit Fedora's Firewall configuration when a Jabber server is not used, it may be desirable to allow both a Jabber server as well as the Link-local approaches to work without user configuration.

How reproducible: Fedora 14, 15, & Rawhide SoaS spins seem to be affected.


Steps to Reproduce:
1. From the "My Settings" right-click menu on two SoaS spin systems, delete the default Jabber server name from the Networking control panel so link-local protocol usage is forced.
2. Attempt to start a Sugar activity on one system, and share it so the other can get to it.
  
Actual results:
Fails due to Fedora's firewall blocking the TCP 5298 connection where telepathy-salut typically connects.  We may also be blocking multicast traffic required for link-local XMPP as well, but I am not an XMPP protocol expert.

Expected results:
Link-local (no Jabber server Internet available) sharing should work between two SoaS-using computers out-of-the-box.

Comment 1 Peter Robinson 2011-04-25 16:01:10 UTC
I'll look at what's required to fix this.

Comment 2 Simon Schampijer 2011-04-25 22:16:22 UTC
From my testing you only need to open the mdns port to get collaboration working (you should check as well if selinux is set to permissive).

There was once a bug about opening the mdns port by default for quite a long time (I can not find it anymore, might have been closed in database cleanups) but it was never dealt with. Maybe making this happen would be a great thing to make link-local collaboration working out of the box.

Comment 3 Peter Robinson 2011-04-25 22:26:51 UTC
(In reply to comment #2)
> From my testing you only need to open the mdns port to get collaboration
> working (you should check as well if selinux is set to permissive).

Its generally enforcing in live spins. Why is this a problem?

> There was once a bug about opening the mdns port by default for quite a long
> time (I can not find it anymore, might have been closed in database cleanups)
> but it was never dealt with. Maybe making this happen would be a great thing to
> make link-local collaboration working out of the box.

It use to be (a long time ago) open by default, then it was decided it was a security risk so was closed.

Looking at fedora-live-mini.ks which is what we use as the base for the soas.ks we have the following line:
firewall --enabled --service=mdns

Which should enable it. We just need to confirm (it might be that the firewall command is obsolete and we need to update it).

Comment 4 Simon Schampijer 2011-04-25 22:36:55 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > From my testing you only need to open the mdns port to get collaboration
> > working (you should check as well if selinux is set to permissive).
> 
> Its generally enforcing in live spins. Why is this a problem?

I thought the sugar sping did set it to permissive at one point. Not sure what is the exact technical reason, but when I had to set it when testing here.

> > There was once a bug about opening the mdns port by default for quite a long
> > time (I can not find it anymore, might have been closed in database cleanups)
> > but it was never dealt with. Maybe making this happen would be a great thing to
> > make link-local collaboration working out of the box.
> 
> It use to be (a long time ago) open by default, then it was decided it was a
> security risk so was closed.
> 
> Looking at fedora-live-mini.ks which is what we use as the base for the soas.ks
> we have the following line:
> firewall --enabled --service=mdns
> 
> Which should enable it. We just need to confirm (it might be that the firewall
> command is obsolete and we need to update it).

This should work I think. It would just be better if a vanilla Fedora-Sugar installation would enable it by default as well, not only the live spin. But I guess we have to live with it.

Comment 5 Peter Robinson 2011-04-25 22:57:23 UTC
> This should work I think. It would just be better if a vanilla Fedora-Sugar
> installation would enable it by default as well, not only the live spin. But I
> guess we have to live with it.

There's a new firewalld going into F-15 that's suppose to assist with these problems, I've not looked at it close enough to see whether its going to fix that issue but we might be able to add a /etc/firewalld.d/sugar file (or similar) with what we need, or set a policy or something. Not sure how advanced it is for F-15.

Comment 6 Samuel Greenfeld 2011-04-25 23:26:22 UTC
In my experience (as noted above) at least private invitations tend to try direct connections between computers on TCP 5298 for Salut, where the telepathy-salut daemon is listening ("netstat -anp" should verify this).  

I verified that a connection was attempted using wireshark/tcpdump, and filed this bug because I initially saw a rejection.

I don't know if anyone else can confirm/deny this.

Comment 7 Adam Williamson 2011-05-06 02:24:16 UTC
Proposing as Sugar blocker and therefore project-wide NTH as this affects a key component of Sugar. As per comment #4, this may be fixed for at least live installs?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Samuel Greenfeld 2011-05-06 17:56:26 UTC
(In reply to comment #7)
> Proposing as Sugar blocker and therefore project-wide NTH as this affects a key
> component of Sugar.

I'm not 100% sure on what blocks a release of Sugar/SoaS but:

* This issue is not a regression; F14 is similarly affected.
* The single-user SoaS experience in both F14 & F15 is not impacted.
* Since Sugar 0.90/F14 the collaboration stack in general has been extensively rewritten and still is being stabilized, so bugs in this area are expected.  Of course the firewall blocking you could be a rather big bug.
* It should not affect out-of-the-box SoaS installs, as they at least historically have used a public jabber server on the Internet over TCP originated from the SoaS instance.  Users would have to delete the Jabber server name via a Control Panel in order to run purely locally and run into this issue.


> As per comment #4, this may be fixed for at least live
> installs?


It depends on if you believe that mDNS is the only incoming-originating firewall port connection required.  I will try to setup a few machines and take packet captures on a somewhat isolated network tonight or early this weekend.

Comment 9 Tim Flink 2011-05-06 19:23:01 UTC
Discussed in the 2011-05-06 blocker review meeting. Rejected as NTH due to Samuel's assessment; particularly because this would not affect default SoaS installs.

Comment 10 Samuel Greenfeld 2011-05-08 22:06:41 UTC
Created attachment 497684 [details]
Firewall configuration used for test endpoints

Firewall used for testing on both endpoints.  It was created using the graphical Firewall configuration tool with SSH and mDNS incoming permitted.

The avahi-daemon.service was manually enabled via systemctl on the two F15 test systems used.

Comment 11 Samuel Greenfeld 2011-05-08 22:22:33 UTC
Created attachment 497688 [details]
Packet Capture of failure to join shared activity

1. Tcpdump was started.
2. Sugar-emulator started on host A @ 172.26.96.5 (Sugar via gdm running on host B @ 172.26.96.5).  The only other host on the network is a schoolserver (not in use except for DHCP).
3. The Chat activity is started and shared on host A.
4. On host B, we see the Chat activity and attempt to join it, but the Chat activity hangs and will not let you type in the text field, etc.
5. After a while I close the Chat activity on both hosts B & A, which stops sharing the activity on A.

Note the two direct connection attempts to the presence service (TCP 5298) from host B to A and then A to B which are rejected at packets 8-9 (~9.13 seconds) and 14-15 (~9.32 seconds) with an ICMP host administratively prohibited response.

The 10.0.0.0 host is a smart switch trying to do IGMP snooping.  It's unclear given my limited knowledge of multicast and this packet trace if anyone is responding to its group membership inquires, or if the switch is inquiring for updates because it sees recent changes in membership.  Hopefully since we're seeing an incoming request Fedora's firewall isn't blocking this.

Comment 12 Samuel Greenfeld 2011-05-08 22:27:40 UTC
Created attachment 497689 [details]
Failed invitation capture

1. Restarted chat activity on host A.
2. Switched to the Network view, and attempted to invite host B.

Note the direct TCP presence connection attempts and ICMP rejections (both host A to B) at packets 10-11 (~0.86 seconds) and 38-39 (~25.50 seconds).

Comment 13 Peter Robinson 2011-06-11 13:59:13 UTC
Has is been confirmed which ports are actually required?

Comment 14 Samuel Greenfeld 2011-06-14 13:42:58 UTC
I don't think anyone has 100% confirmed what is necessary.

I looked at this a bit again last night doing some tcpdumps on Fedora 14 (which has a more stable Sugar network stack at this point?) and using iptstat, but didn't really spot anything new:

1. mDNS (already configured) is definitely needed, as it is used to advertise available Sugar users and activities.
 
2. Incoming TCP (any port) to TCP port 5298 (telepathy-salut) is definitely needed, as Sugar connects to other Sugar systems using this, notably on Sugar startup as well as when an activity invite is sent.  Tested with "-p tcp --dport 5298 -j ACCEPT" inserted in the middle of the INPUT rule stack; verified with tcpdumps/iptstat.

3. An additional multicast protocol of some sort needs to be explicitly allowed.  I'm not quite certain what the minimal rule is, and why iptables' state table isn't automatically picking up on requests to join the group.  Adding an INPUT rule of the form "-m addrtype --dst-type MULTICAST -j ACCEPT" will allow the Chat activity to work over Salut, but still likely is overbroad (although not the worse security hole in the world).

Comment 15 Peter Robinson 2011-10-11 10:26:33 UTC
Samuel: Have we got any further with these requirements?

Comment 16 Samuel Greenfeld 2011-11-03 14:18:18 UTC
The requirements should ideally just match those required by http://xmpp.org/extensions/xep-0174.html

In our case port.p2pj seems to be 5298, which is noted as a historically hard coded number, but not guaranteed.

At the very least allowing mDNS and TCP port 5298 incoming would be a good starting point.

Comment 17 Peter Robinson 2011-12-24 12:27:19 UTC
I've adjusted the SoaS v7 firewall to add 5298, we already had mDNS

Comment 18 Fedora End Of Life 2013-07-04 06:25:15 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Jan Kurik 2015-07-15 15:16:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 20 Fedora End Of Life 2016-11-24 10:31:04 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.