Re: Firewall blocking desktop features
On Wed, 11 Sep 2013, Thomas Woerner wrote: On 09/10/2013 10:07 PM, Peter Oliver wrote: Now, if you're running a server and you install, say, Apache, I think you expect to have to go and poke at the firewall config, but these seem to be very desktop-focused features, and the UI provides no clue about the extra steps required. I am not sure if I am getting this right. What is 'these'? Are you are talking about the desktop UI or firewall-config UI here? I was talking about the desktop UI. It doesn't seem to make a lot of sense to me to have user-facing switches in the desktop UI that, in the default system configuration, are broken (from a naive user's point of view). To be able to add a service configuration file, the information about ports etc. is needed. Dynamic ports are not good for this. Lots of these desktop features are using some dynamic port(s), which makes the creation of service configuration files hard or impossible. A futher complication is that some depend on other features, such as mDNS. In an ideal world there'd be some way to express this in the configuration, I suppose. -- Peter Oliver -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Friday 13 September 2013 01:51:00 drago01 wrote: On Fri, Sep 13, 2013 at 1:26 AM, Oron Peled o...@actcom.co.il wrote: - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). This is wrong. That's not how controlling the service works. Care to explain? * Let's assume someone exploit a buffer overflow in nm-applet to execute arbitrary code. * Now she can ask (over dbus) from NM to do legitimate operations without the user consent/knowledge -- e.g: connect to some random-joe wireless network, etc. (btw, the user can still discover the truth via other client which isn't subverted -- like nmcli, the kde widget, etc.) * I don't claim this attack is easy, because the arbitrary code would have to hook into all relevant dbus callbacks for the wanted transaction to complete successfully, but I don't see any theoretical show-stopper. * IMO, all this just set some upper bound to our security expectations. Privilege separation of services into controller-controlled pair is an improvement over the previous state of affairs, but a verified-good controller can still become rogue during runtime due to a buffer overflow -- it than still have the same power it had before :-( -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron It's not the software that's free; it's you. - billyskank on Groklaw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Fri, Sep 13, 2013 at 10:23 AM, Oron Peled o...@actcom.co.il wrote: On Friday 13 September 2013 01:51:00 drago01 wrote: On Fri, Sep 13, 2013 at 1:26 AM, Oron Peled o...@actcom.co.il wrote: - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). This is wrong. That's not how controlling the service works. Care to explain? Yes. What I meant is nm-applet is not more privileged then any other application in the session. The policy says the active session is allowed to do foo not nm-applet is allowed to do foo. So you can securing the controller wont help you much as long as any other app from the active session can be exploited. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Fri, 2013-09-13 at 11:23 +0300, Oron Peled wrote: On Friday 13 September 2013 01:51:00 drago01 wrote: On Fri, Sep 13, 2013 at 1:26 AM, Oron Peled o...@actcom.co.il wrote: - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). This is wrong. That's not how controlling the service works. Care to explain? * Let's assume someone exploit a buffer overflow in nm-applet to execute arbitrary code. * Now she can ask (over dbus) from NM to do legitimate operations without the user consent/knowledge -- e.g: connect to some random-joe wireless network, etc. (btw, the user can still discover the truth via other client which isn't subverted -- like nmcli, the kde widget, etc.) nm-applet can certainly *ask* NetworkManager to do something. Depending on the policy that an administrator has set, NetworkManager will ask the user to authorize the request via PolicyKit. Only if the request is authorized, will that request be granted. If your user must authorize before you can obtain the ModifySystem and ModifyOwn permissions, then no, nm-applet can't ask NetworkManager to connect to malicious networks unless that trojan also somehow subverts PolicyKit. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. But a malicious app can pretend to be another one, unless there is a way for the firewall to know which app is asking in a way that cannot be forged. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Thursday 12 September 2013 08:25:21 Pierre-Yves Chibon wrote: Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. But a malicious app can pretend to be another one, unless there is a way for the firewall to know which app is asking in a way that cannot be forged. But there is a way: * The firewall management software (firewalld?) would listen over a local stream socket. * The requesting application would connect to this socket with SO_PASSCRED and send its request for ports. * The firewall management software would ignore (and log) connections without SCM_CREDENTIALS. * with SCM_CREDETIALS you have uid, gid and pid of the caller. * From pid you can find the real executable (/proc/pid/cmd). Oh, and btw, when the client closes the connection (e.g: when it terminates) we should close the requested ports so we don't leave unused ports open for future malicious apps. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Simplicity is prerequisite for reliability. -- Edsger Wybe Dijkstra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Thu, 2013-09-12 at 10:01 +0300, Oron Peled wrote: * From pid you can find the real executable (/proc/pid/cmd). And this is the step that's worthless: https://bugzilla.gnome.org/show_bug.cgi?id=533493 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 11.09.2013 23:18, schrieb Mateusz Marzantowicz: On 11.09.2013 17:24, Daniel J Walsh wrote: On 09/11/2013 09:18 AM, Reindl Harald wrote: The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless Interesting discussion but several things doesn't fit together for me: 1. It's firewall's job to manage and keep track of opened ports and established connection so it also should be the piece of software that asks user if he wants to allow network traffic or not. yes 2. Why you say there is no way for firewall to know which app is requesting specific port to be opened? There is a process name and path and it could be identified. could - well, could is not a working implementation show a working implementation firewall means iptables yes, firewalld is nothing else than writing netfilter rules) It's also easy to maintain database of most commonly used binaries and ports that they'd like to open/close. If you don't trust binaries on your system it means it's already been compromised and firewall is then useless in case of *desktop features* most of the time you are speaking about not so well known ports like 80,443,445 and what i fight against is the proposal someone brought in this thread is that the *application defines* the message which the user confirms to open a port - from security point of view this is the most stupid way to go and will later end in a nightmare 3. If you allow each app to ask for permission to open some port, it'll certainly be done in thousand different ways and lack of consistency isn't going to help users *what*? where do i say anything about 1000 different ways? the *opposite* is what i claim all the time must happen and what most people do not realize here is that the whole system (netfilter, network stack, applications) need to work tight together in the case of a request because the application layer still sends data and you have to consider queue packets and after open the firewall send them to the application or whatever you liked to do likely will fail so with the current state of play there is a lot of infrastructure missing for even loudly consider to implement desktop firewalls as knwon from the windows world and honestly before there are done mistakes i clearly say do not touch it at all simply because it worked over decades, it is still working and before now one comes out and says but not comfortable enough he should take a breath and realize that if it comes to security it works *always* against of comfort with *no* exceptions at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 12.09.2013 08:25, schrieb Pierre-Yves Chibon: Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. But a malicious app can pretend to be another one, unless there is a way for the firewall to know which app is asking in a way that cannot be forged the problem is that people refuse to understand security implications until it is too late and in context of a firewall this is fatal proven by 80 out of 100 alerts on securityfocus for *any* sort of software and before someone comes out with but konqueror is from a package well, and you be 100% sure that you not treat /usr/local/bin/ or ~/bin/konqueror the same trusted way and how do you make it sure? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Thursday 12 September 2013 09:23:13 Colin Walters wrote: On Thu, 2013-09-12 at 10:01 +0300, Oron Peled wrote: * From pid you can find the real executable (/proc/pid/cmd). And this is the step that's worthless: https://bugzilla.gnome.org/show_bug.cgi?id=533493 Thanks, that was a very good read. However, there may be still way out for some cases... * First, let's talk about the primary mentioned attack vector -- LD_PRELOAD/ptrace attacks: - These should be ignored by suid/sgid binaries on modern Linux systems (sans kernel bugs). - So if we can sgid all these binaries to a specific group -- this threat is mitigated. - Actually, with this, the service can simply talk to clients running in this firewalld-control group. - Obviously, SELinux (which was mentioned in the URL) is a better solution along the same lines (labeling), but I think it wouldn't be easy to upstream a solution that can only work with SELinux. * But thinking more about attack vectors, I got a more depressing picture: - Assume a valid UI controller get subverted *during* run-time. - Examples: a buffer overrun, dlopen() malicious plugin, loading other dynamic code (e.g: via embedded python interpreter), etc. - This looks pretty hopeless to me in any case (be it SELinux or what's-not) As the same trusted process instantly becomes a bad-guy. - This isn't very different than a hypothetical security hole in ssh that would enable attacker to steal my private key. - *BUT*, since typical GUI programs are far bigger than ssh (including the whole UI library stacks), the risks for buffer overruns are not marginal. - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). - It's true that this is somewhat better than the old suid-root GUI wrappers that could do *anything* to your system. But still, we have no idea how to protect system-wide services *if* they need GUI control. - Or am I missing something here? -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Your fair use of this book is restricted You may only read this book once -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Fri, Sep 13, 2013 at 1:26 AM, Oron Peled o...@actcom.co.il wrote: - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). This is wrong. That's not how controlling the service works. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Wed, 2013-09-11 at 10:04 +0200, Reindl Harald wrote: and who controls for sure that bad software does not the same? snip The source of all this software is available to be looked at. So really, you can verify that only the required ports are opened up. *nobody* and *nothing* has to punch holes im my firewalls - period No one is doing it behind your back here either. Reiterating the points from my last mail: - These software inform and take permission from the user before opening ports in the firewall. - An alternative solution is where the software would just pop a message telling you that you need to open so and so ports in the firewall. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Wed, 2013-09-11 at 18:41 +1000, Ankur Sinha wrote: - These software inform and take permission from the user before opening ports in the firewall. In light of the parallel discussion on too many password prompts, as pointed out by Bochecha, I'd like to clarify: - The software *must* inform the user and take permission before opening ports. (Getting rid of the permission requests altogether will enable proprietary software to open ports too) -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. -- Regards, Heiko Adams signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Le Mer 11 septembre 2013 11:23, Alec Leamas a écrit : On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. The application can lie and propose to open X and then when user says ok open Y. The prompt really needs to be initiated firewall-side -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 2013-09-11 12:02, Nicolas Mailhot wrote: Le Mer 11 septembre 2013 11:23, Alec Leamas a écrit : On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. The application can lie and propose to open X and then when user says ok open Y. The prompt really needs to be initiated firewall-side True. But isn't there a lot to do if we should safefuard against local, lying applications? Well, we have the precompiled, proprietary ones... Even if an app isn't malware, most applications are just not designed for a scenario where the user is prompted to punch o hole in the firewall as soon as an attempt is done. There might be surprises down this road. That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. -- Regards, Heiko Adams signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. If we had applications register prompts/ports in the installed package that firewalld could look up and send the prompt to the user would be the best solution to this problem. This of course does not stop firefox plugin from attempting to share a directory, but my wife would have more of a chance to say no. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIwZhYACgkQrlYvE4MpobO2awCfU+l1bnGFR7nymjUO16PyfB+v 7YkAn0Yegzql2b0SfMq04s0ic+hJfvsJ =6ZgX -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 08:56 AM, Alec Leamas wrote: On 2013-09-11 14:46, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. If we had applications register prompts/ports in the installed package that firewalld could look up and send the prompt to the user would be the best solution to this problem. This of course does not stop firefox plugin from attempting to share a directory, but my wife would have more of a chance to say no. Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. Or cups registers the ports that would be required to share a printer. And the prompt. The apps on the desktop would have limited control over these prompts other them maybe a couple of args the could pass in. The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) Bottom line we need to give feed back to the user about the action being requested that makes sense. I might understand I am sharing a printer or a directory containing music, what network ports these apps require, I would have no clue. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIwaqgACgkQrlYvE4MpobPuFgCZAUzmcjZ/FzQ57o1x5NOwjqxu y10AoM2ESDn5xo9ct8r2NTzUerWW2YEI =Z+VQ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 2013-09-11 15:20, Ralf Corsepius wrote: On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. Ralf Well, it is. Also. And hat's really the core here. It's so damned different in these two cases. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/11/2013 03:32 PM, Alec Leamas wrote: On 2013-09-11 15:20, Ralf Corsepius wrote: On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. Ralf Well, it is. Also. Sure, Single-User-Single-Seat systems are a singular, degenerated case of Multi-User-Multi-Seat systems. And hat's really the core here. It's so damned different in these two cases. Correct, it means that Single-Seat-Single-User focused approaches often lack the generality required on Multi-User-Multi-Seat systems. It often means approaches, which are easily applicable on other OSes, will never fly on Linux. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 2013-09-11 15:41, Ralf Corsepius wrote: On 09/11/2013 03:32 PM, Alec Leamas wrote: On 2013-09-11 15:20, Ralf Corsepius wrote: On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. Ralf Well, it is. Also. Sure, Single-User-Single-Seat systems are a singular, degenerated case of Multi-User-Multi-Seat systems. And hat's really the core here. It's so damned different in these two cases. Correct, it means that Single-Seat-Single-User focused approaches often lack the generality required on Multi-User-Multi-Seat systems. It often means approaches, which are easily applicable on other OSes, will never fly on Linux. Ralf This discussion could easily fly away. Trying to stay on topic: what we are discussing so far is hints for firewall configuration for each application. I don't think anyone should be upset by that. The key issue is just *who* is punching the hole. But isn't this as simple as having administrative rights for this, which some wifes have and some don't? --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/11/2013 06:30 AM, Alec Leamas wrote: On 2013-09-11 12:02, Nicolas Mailhot wrote: Le Mer 11 septembre 2013 11:23, Alec Leamas a écrit : On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. The application can lie and propose to open X and then when user says ok open Y. The prompt really needs to be initiated firewall-side True. But isn't there a lot to do if we should safefuard against local, lying applications? Well, we have the precompiled, proprietary ones... Even if an app isn't malware, most applications are just not designed for a scenario where the user is prompted to punch o hole in the firewall as soon as an attempt is done. There might be surprises down this road. That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. --alec Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/11/2013 10:59 AM, Ankur Sinha wrote: - The software*must* inform the user and take permission before opening ports. Hmm, can you use this feature?: https://lists.fedoraproject.org/pipermail/devel/2013-July/186797.html I.e. you will write script, which will ask admin and open the port. And once rpmconf is run, it will execute it. Of course this is just for command line users using rpmconf and lack integration into GUI tools. :( -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 09:18 AM, Reindl Harald wrote: Am 11.09.2013 15:05, schrieb Daniel J Walsh: On 09/11/2013 08:56 AM, Alec Leamas wrote: Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. very very bad idea! In a perfect world I agree. Sadly we need something better then we currently have. Microsoft tried the tell the user about every port connection and this does not work, because users have no idea. I am trying to find some happy ground between, telling everyone you have to disable firewall to do cool stuff on the desktop. If a random prompt came up that says Do you want to share FOOBAR on the internet? A non educated user could have a chance of saying No? If it kept on happening, he might even ask someone why his machine is acting weird. But if he just said setup sharing of FOOBAR he would understand this and make the correct decision. We have a tool that could be used for labeling the processes that are asking, SELinux, but we would have to eliminate the unconfined_t domain :^(. that means if the is no samba running and whatever harmful process needs to open incoming connections it would trigger the promt for samba these is the way to go only if you want to design a security nightmare The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIwi0QACgkQrlYvE4MpobOOsgCeNKvHYntJyqHecZ3w8SUdk37n +koAn3/y/dI73xIT428bj/23Ryzl/CSK =h307 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/10/2013 10:07 PM, Peter Oliver wrote: Empathy's People Nearby feature doesn't work out of the box because the required ports are blocked by default by the firewall (https://bugzilla.redhat.com/show_bug.cgi?id=844308). It's a similar story with Gnome's Media Sharing feature, and I'm sure there are lots of other examples. With NM connection editor you can bind zones to the connections. For wireless connections you have a connection per ssid. This makes it possible to bind a zone (for example 'home') to your home connection. If you are trusting your home environment completely, you can also use 'trusted'. Then your home network will have full access to your machine. If you are using your machine in an other environment, then it will use another connection and therefore will be bound to another zone. The initial default zone is 'public'. If you are not in a semi or full trusted environment, then there is no simple solution. See further down... Now, if you're running a server and you install, say, Apache, I think you expect to have to go and poke at the firewall config, but these seem to be very desktop-focused features, and the UI provides no clue about the extra steps required. I am not sure if I am getting this right. What is 'these'? Are you are talking about the desktop UI or firewall-config UI here? The FirewallD wiki page talks about a proposed user interaction mode (https://fedoraproject.org/wiki/FirewallD#User_interaction_mode), which sounds like it's intended to address these kinds of issues. I guess that's not going to be with us soon? The user interaction mode is not planned for the short term anymore and it needs to be verified if it could be used with these desktop features at all. The time to ask the user and to get an ok/deny might be too long to establish a connection with the already received packets. A reconnect might be essential to make it work. Meanwhile, are there any quick ways we could simply this for users? It's not much, but should application packages ship /usr/lib/firewalld/services/service.xml files so that users can open the correct ports by ticking a box in firewall-config rather than having to go hunting around to find the ranges? We already have a long list of service configuration files provided by firewalld, most of them are service related. But there is sure room for improvement. To be able to add a service configuration file, the information about ports etc. is needed. Dynamic ports are not good for this. Lots of these desktop features are using some dynamic port(s), which makes the creation of service configuration files hard or impossible. Therefore there are (mostly) no service configuration files for these desktop features. At first there is no documentation about the used ports, addresses and so on and further more there seems to be no interest in firewalls at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 11.09.2013 15:05, schrieb Daniel J Walsh: On 09/11/2013 08:56 AM, Alec Leamas wrote: Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. very very bad idea! that means if the is no samba running and whatever harmful process needs to open incoming connections it would trigger the promt for samba these is the way to go only if you want to design a security nightmare The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 11.09.2013 17:24, Daniel J Walsh wrote: On 09/11/2013 09:18 AM, Reindl Harald wrote: Am 11.09.2013 15:05, schrieb Daniel J Walsh: On 09/11/2013 08:56 AM, Alec Leamas wrote: Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. very very bad idea! In a perfect world I agree. Sadly we need something better then we currently have. Microsoft tried the tell the user about every port connection and this does not work, because users have no idea. I am trying to find some happy ground between, telling everyone you have to disable firewall to do cool stuff on the desktop. If a random prompt came up that says Do you want to share FOOBAR on the internet? A non educated user could have a chance of saying No? If it kept on happening, he might even ask someone why his machine is acting weird. But if he just said setup sharing of FOOBAR he would understand this and make the correct decision. We have a tool that could be used for labeling the processes that are asking, SELinux, but we would have to eliminate the unconfined_t domain :^(. that means if the is no samba running and whatever harmful process needs to open incoming connections it would trigger the promt for samba these is the way to go only if you want to design a security nightmare The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless Interesting discussion but several things doesn't fit together for me: 1. It's firewall's job to manage and keep track of opened ports and established connection so it also should be the piece of software that asks user if he wants to allow network traffic or not. 2. Why you say there is no way for firewall to know which app is requesting specific port to be opened? There is a process name and path and it could be identified. It's also easy to maintain database of most commonly used binaries and ports that they'd like to open/close. If you don't trust binaries on your system it means it's already been compromised and firewall is then useless. 3. If you allow each app to ask for permission to open some port, it'll certainly be done in thousand different ways and lack of consistency isn't going to help users. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Wed, 2013-09-11 at 23:18 +0200, Mateusz Marzantowicz wrote: On 11.09.2013 17:24, Daniel J Walsh wrote: On 09/11/2013 09:18 AM, Reindl Harald wrote: Am 11.09.2013 15:05, schrieb Daniel J Walsh: On 09/11/2013 08:56 AM, Alec Leamas wrote: Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. very very bad idea! In a perfect world I agree. Sadly we need something better then we currently have. Microsoft tried the tell the user about every port connection and this does not work, because users have no idea. I am trying to find some happy ground between, telling everyone you have to disable firewall to do cool stuff on the desktop. If a random prompt came up that says Do you want to share FOOBAR on the internet? A non educated user could have a chance of saying No? If it kept on happening, he might even ask someone why his machine is acting weird. But if he just said setup sharing of FOOBAR he would understand this and make the correct decision. We have a tool that could be used for labeling the processes that are asking, SELinux, but we would have to eliminate the unconfined_t domain :^(. that means if the is no samba running and whatever harmful process needs to open incoming connections it would trigger the promt for samba these is the way to go only if you want to design a security nightmare The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless Interesting discussion but several things doesn't fit together for me: 1. It's firewall's job to manage and keep track of opened ports and established connection so it also should be the piece of software that asks user if he wants to allow network traffic or not. Asking users is generally a bad idea, but indeed it should be done by a central app if ever. 2. Why you say there is no way for firewall to know which app is requesting specific port to be opened? There is a process name and path and it could be identified. It's also easy to maintain database of most commonly used binaries and ports that they'd like to open/close. If you don't trust binaries on your system it means it's already been compromised and firewall is then useless. You may have a legit app that you do not want to allow to access the network, for whatever reason (and there are many valid ones). 3. If you allow each app to ask for permission to open some port, it'll certainly be done in thousand different ways and lack of consistency isn't going to help users. An API to a central service to request access would make sense, then the central service can decide based on policy whether to grant it, prompt a user, or whatever. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 11.09.2013 00:01, schrieb Alec Leamas: On 2013-09-10 23:11, Reindl Harald wrote: Am 10.09.2013 22:58, schrieb Heiko Adams: Am 10.09.2013 22:07, schrieb Peter Oliver: Empathy's People Nearby feature doesn't work out of the box because the required ports are blocked by default by the firewall (https://bugzilla.redhat.com/show_bug.cgi?id=844308). It's a similar story with Gnome's Media Sharing feature, and I'm sure there are lots of other examples. AFAIR the samba client port is also blocked by default which makes it impossible to share files with windows machines what is a samba *client* port? if you want to offer shares you are a *server* *server ports* for *incoming* connections must be closed as default to protect people not knowing what they are doing before read minimal manpages like do not open samba on the WAN - period Nobody questions this. Thie issue in this thread is if we could find ways to make it simpler to enable these services and making it easier to open random incoming port for everybody and it's brother without knowing what they are doing results in waht Microsoft is showing all the years - no thanks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 11.09.2013 12:02, schrieb Nicolas Mailhot: Le Mer 11 septembre 2013 11:23, Alec Leamas a écrit : On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. The application can lie and propose to open X and then when user says ok open Y. The prompt really needs to be initiated firewall-side and as long there is no way for the firewall to *predictable* know what application and display it in the user-request this whole discusssion is *pointless* from a security point of view and we *do not* make all the mistakes other OS vendors in the past in this context thank you! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 10.09.2013 23:38, schrieb Heiko Adams: Am 10.09.2013 23:11, schrieb Reindl Harald: AFAIR the samba client port is also blocked by default which makes it impossible to share files with windows machines what is a samba *client* port? It's port 137 and 138 UDP mhh - and why should i need an *incoming* port for smb? if you want to offer shares you are a *server* Samba-client is (also?) required to access remote shares on Windows machines mhh - that is why i connect to smb-shares *without* any incoming port 137/138/139/445 since years? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 11.09.2013 04:17, schrieb Ankur Sinha: On Wed, 2013-09-11 at 00:01 +0200, Alec Leamas wrote: Nobody questions this. Thie issue in this thread is if we could find ways to make it simpler to enable these services. Last I checked, the bugs already spoke about giving utilities the ability to punch holes in the firewall and then close them when they're done. and who controls for sure that bad software does not the same? upnp on the router side is the same stupidity *nobody* and *nothing* has to punch holes im my firewalls - period signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 10.09.2013 22:58, schrieb Heiko Adams: Am 10.09.2013 22:07, schrieb Peter Oliver: Empathy's People Nearby feature doesn't work out of the box because the required ports are blocked by default by the firewall (https://bugzilla.redhat.com/show_bug.cgi?id=844308). It's a similar story with Gnome's Media Sharing feature, and I'm sure there are lots of other examples. AFAIR the samba client port is also blocked by default which makes it impossible to share files with windows machines what is a samba *client* port? if you want to offer shares you are a *server* *server ports* for *incoming* connections must be closed as default to protect people not knowing what they are doing before read minimal manpages like do not open samba on the WAN - period signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
Am 10.09.2013 22:07, schrieb Peter Oliver: Empathy's People Nearby feature doesn't work out of the box because the required ports are blocked by default by the firewall (https://bugzilla.redhat.com/show_bug.cgi?id=844308). It's a similar story with Gnome's Media Sharing feature, and I'm sure there are lots of other examples. AFAIR the samba client port is also blocked by default which makes it impossible to share files with windows machines. -- Regards, Heiko Adams signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 2013-09-10 23:11, Reindl Harald wrote: Am 10.09.2013 22:58, schrieb Heiko Adams: Am 10.09.2013 22:07, schrieb Peter Oliver: Empathy's People Nearby feature doesn't work out of the box because the required ports are blocked by default by the firewall (https://bugzilla.redhat.com/show_bug.cgi?id=844308). It's a similar story with Gnome's Media Sharing feature, and I'm sure there are lots of other examples. AFAIR the samba client port is also blocked by default which makes it impossible to share files with windows machines what is a samba *client* port? if you want to offer shares you are a *server* *server ports* for *incoming* connections must be closed as default to protect people not knowing what they are doing before read minimal manpages like do not open samba on the WAN - period Nobody questions this. Thie issue in this thread is if we could find ways to make it simpler to enable these services. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Wed, 2013-09-11 at 00:01 +0200, Alec Leamas wrote: Nobody questions this. Thie issue in this thread is if we could find ways to make it simpler to enable these services. Last I checked, the bugs already spoke about giving utilities the ability to punch holes in the firewall and then close them when they're done. The same issue persists in rygel as well[2]. The printer settings in gnome already seem to open up ports in the firewall after taking permission from the user. If the gnome sharing and people nearby applications could do the same, this would make it easier for users. This solution makes it a task for upstreams of these software I'd think. Not a lot firewalld can do here. Even a pop up message that says port needs to be opened in the firewall, open firewall configuration? would work IMO. At the moment, I need to search the web to find what ports each service needs and open them up manually. Either these applications gain the capability to open these ports, or at least properly document what ports need to be open. Rygel, btw, uses a dynamic port via libsoup or something. The user has to configure it to use a static port manually to start with :/ I really haven't looked at any of the source codes. This is from personal experience and the on-going rygel issue which I was unfortunate enough to run into. [1] https://bugzilla.redhat.com/show_bug.cgi?id=626188 [2] https://bugzilla.gnome.org/show_bug.cgi?id=699691 -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
