Re: Fedora Workstation and disabled by default firewall

2019-09-04 Thread Nico Kadel-Garcia
On Wed, Sep 4, 2019 at 5:46 AM Nicolas Mailhot via devel
 wrote:
>
> Le 2019-09-03 18:52, Kyle Marek a écrit :
>
> > Additionally, binding to a specific address does not handle dynamic
> > networks very well.
>
> Simplify that to binding to a specific address does not handle network
> very well, since everything is dynamic nowadays, on desktops, phones or
> servers (servers via vlans, binding, teaming, etc).
>
> Having every single networked app handle dynamic network changes on its
> own does not scale.
>
> There are not so many ways to handle this:
>
> 1. have every app bind to null, and hope the firewall filters out
> dangerous accesses. You'll get a *lot* of app collisions, because every
> app will fight for 443 ownership. And as soon as the firewall is down,
> the king has no clothes.
>
> 2. have every app bind to a private exotic or dynamic port, and map
> those to public well-known ports on the correct address and network at
> the firewall level. That's the usual strategy for containers set up by
> people with no network understanding, because they can not imagine more
> than one address per container. They forget that this will break all
> network management/inspection tools, because no network port will make
> any sense to tools anymore, and unless they go to full dynamic, their
> exotic ports will collide too because their choices are obvious and dumb
> (80xxx usually). And it requires some out of band data telling the
> firewall what the well-known port for each private port should be
> (complex mapping). Again, as soon as the firewall is down, the king has
> no clothes.
>
> 3. only bind to null apps actually intended to be exposed everywhere
> (sshd). Have every other app (containerized or not) use standard fixed
> well-known ports, but give each one a loopback address, and map public
> addresses+well-known port to the correct loopback address+same
> well-known port at the firewall level. It is safe (if the firewall goes
> down, the mappings go down with it, nothing is exposed). It is
> manageable (network flows use standard ports tools know about; the
> firewall does not need to learn complex port mapping, just what private
> ip owns the public port associate to a specific public networks; and the
> usual collision of 443 requests can be easily handled at layer set by
> deploying apache+mod-proxy on one of the private addresses).
>
> Using 3., there is not need to ask users to answer complex questions
> about network ports (because all the network ports are standard,
> well-known port, preset by upstream/the packager). The user only needs

You're trying to outsmart what other people want with a technological
procedure. Since sshd is a lethally dangerous protocol to expose by
default in the world of rootkitted hosts and stolen passwords, and is
one of the ports which should *most* be cut off from exposure to the
world at large, well, the premise of exposing it by default fails
immediately.

Yes, it's pretty much the only place to start with cloud based
machines, but one of the first security steps there is to activate
some kind of firewally to restrict access to your internal network
only.

> Making 3. work for the workstation case just needs some way to tell an
> app what system-specific loopback it should use, and some way for the
> app to declare to the firewall the well-known ports it wants, which is
> the kind and level of complexity systemd already manages.

Please, stop trying to treat the workstation as a fundamentally
different case. It's not. Let's leave the firewall on by default, to
encourage our users to actually learn about their systems and to leave
them in a considerably safer state at system installation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-04 Thread Nicolas Mailhot via devel

Le 2019-09-03 18:52, Kyle Marek a écrit :


Additionally, binding to a specific address does not handle dynamic
networks very well.


Simplify that to binding to a specific address does not handle network 
very well, since everything is dynamic nowadays, on desktops, phones or 
servers (servers via vlans, binding, teaming, etc).


Having every single networked app handle dynamic network changes on its 
own does not scale.


There are not so many ways to handle this:

1. have every app bind to null, and hope the firewall filters out 
dangerous accesses. You'll get a *lot* of app collisions, because every 
app will fight for 443 ownership. And as soon as the firewall is down, 
the king has no clothes.


2. have every app bind to a private exotic or dynamic port, and map 
those to public well-known ports on the correct address and network at 
the firewall level. That's the usual strategy for containers set up by 
people with no network understanding, because they can not imagine more 
than one address per container. They forget that this will break all 
network management/inspection tools, because no network port will make 
any sense to tools anymore, and unless they go to full dynamic, their 
exotic ports will collide too because their choices are obvious and dumb 
(80xxx usually). And it requires some out of band data telling the 
firewall what the well-known port for each private port should be 
(complex mapping). Again, as soon as the firewall is down, the king has 
no clothes.


3. only bind to null apps actually intended to be exposed everywhere 
(sshd). Have every other app (containerized or not) use standard fixed 
well-known ports, but give each one a loopback address, and map public 
addresses+well-known port to the correct loopback address+same 
well-known port at the firewall level. It is safe (if the firewall goes 
down, the mappings go down with it, nothing is exposed). It is 
manageable (network flows use standard ports tools know about; the 
firewall does not need to learn complex port mapping, just what private 
ip owns the public port associate to a specific public networks; and the 
usual collision of 443 requests can be easily handled at layer set by 
deploying apache+mod-proxy on one of the private addresses).


Using 3., there is not need to ask users to answer complex questions 
about network ports (because all the network ports are standard, 
well-known port, preset by upstream/the packager). The user only needs 
to decide if an app should be exposed to a particular network (or zone) 
and then the firewall can just map the ports used by this app on its 
loopback address on the same ports on the public addresses used by the 
system in this zone.


Making 3. work for the workstation case just needs some way to tell an 
app what system-specific loopback it should use, and some way for the 
app to declare to the firewall the well-known ports it wants, which is 
the kind and level of complexity systemd already manages.


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-03 Thread Kyle Marek
On 8/31/19 6:45 PM, John Harris wrote:
> On Friday, August 30, 2019 4:33:11 AM MST Björn Persson wrote:
>> John Harris wrote:
>>> Thing is, binding a port and expecting it to be open to every network
>>> interface you've got are two very different things.
>> Once again John Harris is completely wrong. The bind system call is
>> precisely how a program specifies which network interfaces it wants to
>> open a socket to. A program that calls bind with IN6ADDR_ANY_INIT or
>> INADDR_ANY and a specific port number expects that port to be open to
>> every network interface the computer has.
>>
>> A program that doesn't intend to listen on every network interface will
>> bind to an IP address assigned to one interface to listen only on that
>> network, or maybe a localhost address to listen only on the loopback
>> interface. The port and the network interface are specified together in
>> a single sockaddr object passed to a single system call, so it's very
>> much the same thing.
>>
>> Björn Persson
> This is a bit hostile, and certainly comes off as passive aggressive. When 
> you 
> bind a port, it isn't open on every interface unless you specify that, you're 
> partially correct. Many programs, however, bind all interfaces regardless. 
> For 
> example, dnsmasq does this by default, and many other programs do it without 
> a 
> configuration option on ports. So, while the software may be open to all 
> ports 
> because of the code itself, that is often not the intention. Many programs 
> just bind all interfaces, and expect that you'll configure your firewall to 
> whatever should be able to access the network service it's serving.
>
> Programs that don't intend to listen on every interface generally don't bind 
> only to one interface, though they should. Especially not proprietary 
> software. If an interface is not specified, you get all interfaces bound.
>
> binding a port has nothing to do with opening a socket to something else. In 
> nearly all cases, it's used to open your system to incoming connections.

Additionally, binding to a specific address does not handle dynamic
networks very well. Programs would need to be reconfigured and restarted
to handle the machine being connected to a different network, or an IP
address change on an existing network. Binding to null address and
taking advantage of firewall zones works well for situations where the
program should be accessible on one network (or one class of networks)
but not another (even when connected to both networks simultaneously).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-02 Thread Christopher
On Tue, Sep 3, 2019 at 12:26 AM John Harris  wrote:
> There is not a single service in Fedora that is broken by the firewall
> running. You simply have to open the port before it can be accessed from a
> remote system, which is by design. Basic access control, a security feature.

Exactly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-02 Thread John Harris
On Sunday, September 1, 2019 4:13:10 AM MST mcatanz...@gnome.org wrote:
> On Sat, Aug 31, 2019 at 6:37 PM, Nico Kadel-Garcia  
> wrote:
> 
> > If 30 years in DevOps and system security in both large and small
> > networks count for anything, this makes *complete* sense. The
> > distinction between a "Workstation" deployment and a "Server" or
> > "Everything" deployment should not include leaving the Workstation
> > completely vulnerable to the most casual script kiddie attacks after
> > they install *any* services, especially including MySQL, DNS, Samba,
> > or Tomcat, Jenkins, or anything else.
> 
> 
> Well that's why installed network services are disabled by default in 
> Fedora, unless the package receives an exception from FESCo. This isn't 
> Debian where installing a package is expected to result in the service 
> being up and running. If you 'systemctl start' your service and the 
> firewall breaks it, that's just annoying.
> 
> Michael

There is not a single service in Fedora that is broken by the firewall 
running. You simply have to open the port before it can be accessed from a 
remote system, which is by design. Basic access control, a security feature.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-02 Thread Sheogorath via devel
On 8/28/19 1:01 AM, Adam Williamson wrote:
> On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:
>> mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:
>>> On Tue, Aug 27, 2019 at 4:22 AM, John Harris 
>>> wrote:
 No, that is not how this works, at all. First, let's go ahead and
 address the 
 idea that "if the firewall blocks it, the app breaks, so it's the
 firewall's 
 fault": It's not. If the firewall has not been opened, that just
 means it 
 can't be accessed by remote systems until you EXPLICITLY open that
 port, with 
 the correct protocol, on your firewall. That's FINE. That's how
 it's designed 
 to work. There's nothing wrong with that.

 This means that the system administrator (or owner, if this is
 some 
 individual's personal system) must allow the port to be accessed
 remotely, 
 before the app can be reached remotely, increasing the security of
 the system.
>>>
>>> You've already lost me here. Sorry, but we do not and will not
>>> install a firewall GUI that exposes complex technical details like
>>> port numbers. Expecting users to edit firewall rules to use their
>>> apps is ridiculous and I'm not really interested in debating it.
>>
>> Yeah, when you ask users questions they're not qualified to answer,
>> you're just creating bad design.
>> I always imagine my mom (who BTW has been a Fedora user for years) how
>> she'd deal with that and I can't really imagine her opening/closing
>> firewall ports. She'd be puzzled even by "Do you trust this network?"
>> and would probably just click "Yes" to make it go away. No additional
>> security, just annoying UX.
> 
> However, Fedora Workstation is an edition. Which means it has a
> *policy-defined* target audience. That target audience is defined here:
> https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> 
> Case 1: "Engineering/CS student"
> Case 2: "Independent Developer"
> Case 3: "Small Company Developer"
> Case 4: "Developer in a Large Organization"
> 
> Are those people we believe do not understand the concepts associated
> with firewalls?
> 

Let's get real. It doesn't matter if you understand firewalls or not.
Reality is that developers run applications they are working on in
development configurations on their local system. With some luck they
are properly configured but as far as I know most dev setups, they are
not considered secure or "production-ready" and that for good reasons.

But what do we do after a long day? We take our notebook and close the
lid at the end of a long day or when we head over to this annoying
meeting with the new customer. We probably don't close and shut down all
services we are developing/testing in background. Then we head over
there, open the notebook and of course need some kind of
presentation/picture/data we stored on the cloud storage provider of our
trust. We connect to the public/unknown WiFi and *boom* suddenly we have
unexpected open ports on a public network we didn't to expose them to.

This is not something that people do on purpose but it simply happens.
It's how we use devices nowadays.

So I guess it would already improve the situation when we would only
open the ports on install, which by far isn't a perfect solution but
would already prevent the scenario mentioned above. Which appears no
matter if someone is aware of firewall concepts or not.

Let's work on solving this problem for everyone, because it's a general
problem.

-- 
Signed
Sheogorath



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-02 Thread Sheogorath via devel
On 8/27/19 3:25 AM, John Harris wrote:
> On Monday, August 26, 2019 7:25:27 AM MST Iñaki Ucar wrote:
>> On Mon, 26 Aug 2019 at 15:25, Robert Marcano 
>> wrote:
>>>
>>>
>>> On 8/26/19 9:07 AM, mcatanz...@gnome.org wrote:
>>>


 Well the thing is, blocknig ports tends to break applications that want
 to use those ports. We're not going to do that, period. It also doesn't
 really accomplish anything: either your app or service needs network
 access and you have whitelisted it (in which case the firewall provides
 no security), or it needs network access and you have not whitelisted
 it
 (in which case your firewall breaks your app/service). In no case does
 it increase your security without breaking your app, right? Unless you
 have malware installed (in which case, you have bigger problems than
 the
 firewall). Or unless you have a vulnerable network service installed
 that you don't want (in which case, uninstall it).
>>>
>>>
>>>
>>> This is a reasonable point of view, until you notice Linux desktops
>>> evironments don't provide applications with a method to detect if they
>>> are running on a private network or not (See Windows Home, Office,
>>> Internet network settings).
>>
>>
>> That's a very good point. When Windows connects to a new network, it
>> asks whether it's a home connection (and then you want to share
>> resources in the network) or it's a public connection (and everything
>> should stay private). And I think that, if the user simply ignores the
>> notification, the default is to consider it a public network (not 100%
>> sure though). That's a good policy I think, and it would be great if
>> NetworkManager could do that.
>>
>> I understand mcatanzaro's point of view, but it's quite narrow,
>> because laptops not only connect to home networks to share resources,
>> but also to many insecure public WiFis. I don't think we should rely
>> on chasing upstream developers to behave in a *possibly* insecure
>> environment. The system should abstract this for them and set proper
>> firewall rules.
> 
> Keep in mind that even Windows doesn't address the use case where you set it 
> to Home or Business, or whatever the private setting is, and then plug in a 
> connection to a public network. It thinks it's still the same.
> 

I had something back in mind that tickled, when I read this. Because I
remember that Windows 7 did something with the default Gateway mac
address, so I did some digging.

https://web.archive.org/web/20170405202217/https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/

There is quite some documentation about how Windows
determines/determined when it was connected to a different network
(being it by wire or WiFi). Even when this information is might outdated
when looking at Windows 10.

Hope that helps to provide some inspiration towards solving this problem
and create better Firewall rule sets :)

(But in general it sounds like something that should go into
NetworkManager and could be useful for easier network profiles)

-- 
Signed
Sheogorath



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-01 Thread Nico Kadel-Garcia
On Sun, Sep 1, 2019 at 7:16 AM  wrote:
>
> On Sat, Aug 31, 2019 at 6:37 PM, Nico Kadel-Garcia 
> wrote:
> > If 30 years in DevOps and system security in both large and small
> > networks count for anything, this makes *complete* sense. The
> > distinction between a "Workstation" deployment and a "Server" or
> > "Everything" deployment should not include leaving the Workstation
> > completely vulnerable to the most casual script kiddie attacks after
> > they install *any* services, especially including MySQL, DNS, Samba,
> > or Tomcat, Jenkins, or anything else.
>
> Well that's why installed network services are disabled by default in
> Fedora, unless the package receives an exception from FESCo. This isn't
> Debian where installing a package is expected to result in the service
> being up and running. If you 'systemctl start' your service and the
> firewall breaks it, that's just annoying.
>
> Michael

There is "annoying", and there is "dangerously exposing your host"
while you're first learning about the service. I'd encourage leaving
the training wheels on until the service administrator can bother to
learn about firewalls and take off the training wheels.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-09-01 Thread mcatanzaro
On Sat, Aug 31, 2019 at 6:37 PM, Nico Kadel-Garcia  
wrote:

If 30 years in DevOps and system security in both large and small
networks count for anything, this makes *complete* sense. The
distinction between a "Workstation" deployment and a "Server" or
"Everything" deployment should not include leaving the Workstation
completely vulnerable to the most casual script kiddie attacks after
they install *any* services, especially including MySQL, DNS, Samba,
or Tomcat, Jenkins, or anything else.


Well that's why installed network services are disabled by default in 
Fedora, unless the package receives an exception from FESCo. This isn't 
Debian where installing a package is expected to result in the service 
being up and running. If you 'systemctl start' your service and the 
firewall breaks it, that's just annoying.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-31 Thread Nico Kadel-Garcia
On Sat, Aug 31, 2019 at 7:04 PM John Harris  wrote:
>
> On Friday, August 30, 2019 5:16:25 AM MST Nico Kadel-Garcia wrote:
> > > On Aug 29, 2019, at 9:41 PM, John Harris  wrote:
> > >
> > >
> > >> On Thursday, August 29, 2019 8:12:22 AM MST Dan Book wrote:
> > >> I would agree, but people do install multiple desktops after installing
> > >> a
> > >> spin. Such a use case needs to be considered (not sure if it matters,
> > >> though).
> > >
> > >
> > > This is definitely not the ideal scenario, especially not from the case of
> > > the  installer for the GNOME spin. I don't know if there's really any
> > > reason to consider it, as the user is taking things into their own hands
> > > at that point.
> >
> > Let us not try to outsmart what people *must have wanted*, and err on the
> > side of not leaving their neckties hanging out the window for yanking by
> > passing pranksters.  Leave firewalls up by default.
>
> I don't think you understand what I meant. Please allow me to clarify. The
> suggestion was that we should set the default in such a way that would work
> regardless of what the user installs after the installation of Workstation
> itself. We have no way of doing that. We cannot just guess what the user means
> to install while we're in Anaconda. Unfortunately, mind reading hardware isn't
> there yet.
>
> I would agree, leave firewalls up by default.

If 30 years in DevOps and system security in both large and small
networks count for anything, this makes *complete* sense. The
distinction between a "Workstation" deployment and a "Server" or
"Everything" deployment should not include leaving the Workstation
completely vulnerable to the most casual script kiddie attacks after
they install *any* services, especially including MySQL, DNS, Samba,
or Tomcat, Jenkins, or anything else.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-31 Thread John Harris
On Friday, August 30, 2019 5:16:25 AM MST Nico Kadel-Garcia wrote:
> > On Aug 29, 2019, at 9:41 PM, John Harris  wrote:
> > 
> > 
> >> On Thursday, August 29, 2019 8:12:22 AM MST Dan Book wrote:
> >> I would agree, but people do install multiple desktops after installing
> >> a
> >> spin. Such a use case needs to be considered (not sure if it matters,
> >> though).
> > 
> > 
> > This is definitely not the ideal scenario, especially not from the case of
> > the  installer for the GNOME spin. I don't know if there's really any
> > reason to consider it, as the user is taking things into their own hands
> > at that point.
> 
> Let us not try to outsmart what people *must have wanted*, and err on the
> side of not leaving their neckties hanging out the window for yanking by
> passing pranksters.  Leave firewalls up by default.

I don't think you understand what I meant. Please allow me to clarify. The 
suggestion was that we should set the default in such a way that would work 
regardless of what the user installs after the installation of Workstation 
itself. We have no way of doing that. We cannot just guess what the user means 
to install while we're in Anaconda. Unfortunately, mind reading hardware isn't 
there yet.

I would agree, leave firewalls up by default.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-31 Thread John Harris
On Friday, August 30, 2019 12:35:34 PM MST mcatanz...@gnome.org wrote:
> On Wed, Aug 28, 2019 at 7:46 PM, Christopher 
>  wrote:
> 
> > Yeah, I also don't want a complicated installer. I just don't see this
> > disagreement going anywhere without some sort of compromise, and I
> > can't think of any others that will satisfy people. I think there's a
> > good chance this could be implemented without much complexity, though.
> > Thank you for giving the idea at least a little consideration, though,
> > and not outright dismissing it.
> 
> 
> The potential compromise I see might involve exposing firewall zones in 
> some well-considered and thoughtful way, including a rethink of what is 
> blocked and allowed by the zones, and an understanding of what the goal 
> of having each zone is. That would have to be done in both gnome-shell 
> and gnome-control-center, and it'd need to receive buy-in from relevant 
> designers and developers.
> 
> Such an effort would need to be undertaken by developers who understand 
> and accept a requirement to not break installed applications or 
> services, to not expect users to be capable of editing firewall rules, 
> and to not require the installation of a firewall GUI application that 
> exposes technical details like ports. It would also need to firmly 
> reject the assumption that users know (or even that users *should* 
> know) the difference between a TCP port and a USB port. Otherwise, the 
> gulf between the two sides here is just too great, and there's no hope 
> for a useful discussion or compromise. But if these requirements are 
> OK, maybe we can agree on something.
> 
> The work would need to be undertaken by people actually interested in 
> the problem. Expecting existing Workstation developers to work on this 
> is not likely to turn out well, since we're busy, and I think most of 
> us are already OK with the status quo.
> 
> It'd also be helpful to get beyond this security myth that having a 
> firewall is somehow essential to have a secure workstation. I'm firmly 
> convinced this is not the case, and I'm unpersuaded by most of the 
> comments in this thread that assume otherwise. The best argument I've 
> seen so far in favor of a firewall was accidentally sharing your 
> Rhythmbox media library on a public network, so focusing on that or 
> similar issues would be helpful. Unplugging from trusted "wired 
> connection 1" (e.g. a home router) and plugging into a different 
> untrusted "wired connection 1" (e.g. a modem) is another good example 
> from this thread of where mistakes can currently occur. We probably 
> shouldn't allow users to share media on a network where the user has a 
> public IP, for instance. But just repeated claiming that a firewall is 
> essential for security isn't going to impress me.
> 
> Iñaki seems to be batting in this direction with the issues he's 
> filed. His approach seems constructive to me. I fear it might be easy 
> to have missed his comment in this noisy thread.
> 
> Michael

Several things.

One, running with a firewall that blocks incoming connections from external 
hosts doesn't break any known software in Fedora. If it does, please let me 
know, as that's highly unusual, and certainly cause for concern.

I don't believe we need to wait for the DE to catch up in terms of security in 
order to set a default firewall zone of something more safe. If the end user 
is planning on running a network service, especially something which is not 
part of GNOME, I can't see any reason that it should be in the default 
firewall zone, nor can I see any reason that it needs to be opened for the 
user, the system simply making assumptions about what they intend to do. When 
an end user chooses to run a network service, they should definitely be making 
a conscious decision to open that port to their given network, unless they've 
changed the firewall zone.

Port numbers are not "technical data". Seriously, they're not. I have no idea 
where you're getting that from, because port numbers are important to know if 
you intend to connect to anything. The only ones they, for the most part,  
wouldn't need to know in order to connect are: http, https, ssh.

Holy cow, they definitely should know that there is a MAJOR difference between 
a TCP port and a USB port. One of these is a number used to identify the 
service you want to connect to on a remote host. The other is a physical port 
for local devices.. When remote devices are involved, things are very 
different.

Having a firewall is absolutely essential, ESPECIALLY if you expect that your 
users don't know what a firewall is, or even what a port number is.

Additionally, you have no real way of knowing what a "public IP" is. You can 
have a 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 IP address and still be on 
a public network.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- 

Re: Fedora Workstation and disabled by default firewall

2019-08-31 Thread John Harris
On Friday, August 30, 2019 4:33:11 AM MST Björn Persson wrote:
> John Harris wrote:
> > Thing is, binding a port and expecting it to be open to every network
> > interface you've got are two very different things.
> 
> Once again John Harris is completely wrong. The bind system call is
> precisely how a program specifies which network interfaces it wants to
> open a socket to. A program that calls bind with IN6ADDR_ANY_INIT or
> INADDR_ANY and a specific port number expects that port to be open to
> every network interface the computer has.
> 
> A program that doesn't intend to listen on every network interface will
> bind to an IP address assigned to one interface to listen only on that
> network, or maybe a localhost address to listen only on the loopback
> interface. The port and the network interface are specified together in
> a single sockaddr object passed to a single system call, so it's very
> much the same thing.
> 
> Björn Persson

This is a bit hostile, and certainly comes off as passive aggressive. When you 
bind a port, it isn't open on every interface unless you specify that, you're 
partially correct. Many programs, however, bind all interfaces regardless. For 
example, dnsmasq does this by default, and many other programs do it without a 
configuration option on ports. So, while the software may be open to all ports 
because of the code itself, that is often not the intention. Many programs 
just bind all interfaces, and expect that you'll configure your firewall to 
whatever should be able to access the network service it's serving.

Programs that don't intend to listen on every interface generally don't bind 
only to one interface, though they should. Especially not proprietary 
software. If an interface is not specified, you get all interfaces bound.

binding a port has nothing to do with opening a socket to something else. In 
nearly all cases, it's used to open your system to incoming connections.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-30 Thread mcatanzaro
On Wed, Aug 28, 2019 at 7:46 PM, Christopher 
 wrote:

Yeah, I also don't want a complicated installer. I just don't see this
disagreement going anywhere without some sort of compromise, and I
can't think of any others that will satisfy people. I think there's a
good chance this could be implemented without much complexity, though.
Thank you for giving the idea at least a little consideration, though,
and not outright dismissing it.


The potential compromise I see might involve exposing firewall zones in 
some well-considered and thoughtful way, including a rethink of what is 
blocked and allowed by the zones, and an understanding of what the goal 
of having each zone is. That would have to be done in both gnome-shell 
and gnome-control-center, and it'd need to receive buy-in from relevant 
designers and developers.


Such an effort would need to be undertaken by developers who understand 
and accept a requirement to not break installed applications or 
services, to not expect users to be capable of editing firewall rules, 
and to not require the installation of a firewall GUI application that 
exposes technical details like ports. It would also need to firmly 
reject the assumption that users know (or even that users *should* 
know) the difference between a TCP port and a USB port. Otherwise, the 
gulf between the two sides here is just too great, and there's no hope 
for a useful discussion or compromise. But if these requirements are 
OK, maybe we can agree on something.


The work would need to be undertaken by people actually interested in 
the problem. Expecting existing Workstation developers to work on this 
is not likely to turn out well, since we're busy, and I think most of 
us are already OK with the status quo.


It'd also be helpful to get beyond this security myth that having a 
firewall is somehow essential to have a secure workstation. I'm firmly 
convinced this is not the case, and I'm unpersuaded by most of the 
comments in this thread that assume otherwise. The best argument I've 
seen so far in favor of a firewall was accidentally sharing your 
Rhythmbox media library on a public network, so focusing on that or 
similar issues would be helpful. Unplugging from trusted "wired 
connection 1" (e.g. a home router) and plugging into a different 
untrusted "wired connection 1" (e.g. a modem) is another good example 
from this thread of where mistakes can currently occur. We probably 
shouldn't allow users to share media on a network where the user has a 
public IP, for instance. But just repeated claiming that a firewall is 
essential for security isn't going to impress me.


Iñaki seems to be batting in this direction with the issues he's 
filed. His approach seems constructive to me. I fear it might be easy 
to have missed his comment in this noisy thread.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-30 Thread mcatanzaro
On Wed, Aug 28, 2019 at 5:33 AM, Jiri Eischmann  
wrote:

And the same document says:
"While our focus is on creating a top-class developer workstation, our
developer focus will not compromise the aforementioned goal to be a
polished and user friendly system that appeals to a wide general
audience."

Having a target audience in mind doesn't mean we have to make bad
design for everyone else.


Absolutely.


In addition their preferences could be
actually the same. Just look at macOS, it's made easy for our moms and
dads and very popular with developers at the same time.


If anybody with a good memory or interest in thread archaeology wants 
to investigate, I believe there was actually some problem with some 
specific tools used by web developers that were broken by the previous 
firewall configuration.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-30 Thread Matthew Miller
On Thu, Aug 29, 2019 at 06:54:48PM -0700, John Harris wrote:
> Workstation is only the primary product because somebody decided GNOME was
> the best default. This should be reconsidered, so that the various Spins,

This is backwards. We (the Fedora Board) at the time, asked for a team to
develop our primary desktop-focused edition, and the team that stepped up to
do that chose GNOME as the best environment to use for that.

I think this is still the case. But that doesn't mean that the other
desktops and spins and solutions using them aren't important. I refer you to
https://communityblog.fedoraproject.org/fedoras-strategic-direction-an-update-from-the-council/
for current Fedora Council thinking on this.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-30 Thread Nico Kadel-Garcia


> On Aug 29, 2019, at 9:41 PM, John Harris  wrote:
> 
>> On Thursday, August 29, 2019 8:12:22 AM MST Dan Book wrote:
>> I would agree, but people do install multiple desktops after installing a
>> spin. Such a use case needs to be considered (not sure if it matters,
>> though).
> 
> This is definitely not the ideal scenario, especially not from the case of 
> the 
> installer for the GNOME spin. I don't know if there's really any reason to 
> consider it, as the user is taking things into their own hands at that point.

Let us not try to outsmart what people *must have wanted*, and err on the side 
of not leaving their neckties hanging out the window for yanking by passing 
pranksters.  Leave firewalls up by default.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-30 Thread Björn Persson
John Harris wrote:
> Thing is, binding a port and expecting it to be open to every network 
> interface you've got are two very different things.

Once again John Harris is completely wrong. The bind system call is
precisely how a program specifies which network interfaces it wants to
open a socket to. A program that calls bind with IN6ADDR_ANY_INIT or
INADDR_ANY and a specific port number expects that port to be open to
every network interface the computer has.

A program that doesn't intend to listen on every network interface will
bind to an IP address assigned to one interface to listen only on that
network, or maybe a localhost address to listen only on the loopback
interface. The port and the network interface are specified together in
a single sockaddr object passed to a single system call, so it's very
much the same thing.

Björn Persson


pgpAOVug6y7hZ.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread John Harris
On Thursday, August 29, 2019 3:50:19 AM MST Iñaki Ucar wrote:
> Responding to the first message because I'm not interested in further
> discussion. It's clear to me that there will be no agreement in this
> matter unless there are reasonable potential alternatives. Therefore,
> this message is just to let you all know that I'm at least trying to
> push for better alternatives. In particular, these:
> 
> https://bugs.kde.org/show_bug.cgi?id=411359
> https://gitlab.gnome.org/GNOME/gnome-shell/issues/1550
> https://gitlab.gnome.org/GNOME/gnome-control-center/issues/650
> 
> You are welcome to help with the above, or bring them to other
> desktops. Hopefully, if these proposals get accepted and implemented,
> we could eventually bring back this discussion and reach some
> consensus.

In GNOME, it used to be a dropdown with these default options:
home
public
trusted
work

I don't see how this could possibly be too confusing for "non-power users". 
Just default it to something safe, like "public", is what I'd suggest. That's 
what the default used to be. Additionally, I can't see anything that can be 
enabled using GNOME's GUIs, other than VNC, which would bind ports.

KDE has that as a dropdown right now, and the KDE Spin is not affected by the 
decision of the GNOME folks.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread John Harris
On Thursday, August 29, 2019 1:11:02 PM MST Chris Murphy wrote:
> On Thu, Aug 29, 2019 at 12:24 AM Chris Murphy 
> wrote:
> >
> >
> > Debian has a permissive firewall
> > https://wiki.debian.org/DebianFirewall
> 
> 
> And Ubuntu, Mint, elementary, MX Linux, Solus, pop!_OS, as well. By
> permissive, they all accept everything. Nothing is rejected or
> dropped.
> 
> Mageia, and openSUSE do have a fair amount of iptables filtering
> entries. e.g. openSUSE Tumbleweed lastest snapshot,
> https://paste.fedoraproject.org/paste/TOJ1cdZpRWy2150N2O~IOw/raw
> 
> I didn't test Zorin because I couldn't get passed the paywall, and for
> some reason Manjaro boots (kernel and initramfs) but then hangs during
> startup and I don't really want to troubleshoot it.
> 
> Anyway, that rounds out the top ~10 distros, and Fedora Workstation is
> definitely not the most permissive.

That Ubuntu and a handful of obscure distros do something does not mean that's 
a good idea. These systems, except for Debian, also don't have SELinux or 
AppArmor enabled by default.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread John Harris
On Thursday, August 29, 2019 8:34:09 AM MST Christophe de Dinechin wrote:
> mcatanz...@gnome.org writes:
> 
> 
> > Well the thing is, blocknig ports tends to break applications that want
> > to use those ports. We're not going to do that, period. It also doesn't
> > really accomplish anything: either your app or service needs network
> > access and you have whitelisted it (in which case the firewall provides
> > no security), or it needs network access and you have not whitelisted
> > it (in which case your firewall breaks your app/service). In no case
> > does it increase your security without breaking your app, right? Unless
> > you have malware installed (in which case, you have bigger problems
> > than the firewall). Or unless you have a vulnerable network service
> > installed that you don't want (in which case, uninstall it).
> >
> >
> >
> > So if you want to change the firewall settings, you'd need to
> > completely rethink how the firewall works. And nobody seems interested
> > in doing that. We could e.g. have a list of apps that are allowed
> > network access, but then we'd need some form of attestation so apps
> > can't impersonate each other. So only sandboxed (flatpaked) apps could
> > use this hypothetical new firewall. And we surely don't want to have
> > yes/no permission prompts, so we can't really ask the user "do you want
> > your app to access the network?" (the user will almost always say
> > yes).
> 
> 
> For what it's worth, macOS started doing exactly that recently.
> I agree it seems useless, except for one thing. Sometimes, you realize
> that some app is opening a port when you don't expect it.
> 
> 
> > I'm not really sure what design would even work.
> >
> >
> >
> > Avoiding unnecessary network services makes more sense.
> >
> >
> >
> > On Mon, Aug 26, 2019 at 3:45 PM, Alexander Ploumistos
> >  wrote:
> > 
> >>
> >>
> >> As a matter of fact, you did:
> >>  >> org/thread/3LHDQD5HCZMPV6O4LZRSKTVEIKEFJIBY/#3LHDQD5HCZMPV6O4LZRSKTVEIKEF
> >> JIBY>
> >>  
> >> >> Products.html#idm225474210784>>
> >
> >
> > Thanks for dredging up these links!
> >
> >
> >
> > Michael
> >
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
 List
> > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> > Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o
> > rg
> 
> 
> --
> Cheers,
> Christophe de Dinechin (IRC c3d)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Thing is, binding a port and expecting it to be open to every network 
interface you've got are two very different things.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread John Harris
On Thursday, August 29, 2019 5:29:32 PM MST Christopher wrote:
> Workstation is the primary product. Some choose that not for GNOME...
> but because they want to start with the most base product and
> customize from there. If you start with a Spin, you may get something
> pre-configured in a very weird way... and with a smaller support
> community.

Workstation is only the primary product because somebody decided GNOME was the 
best default. This should be reconsidered, so that the various Spins, the 
GNOME Spin, KDE Spin, XFCE Spin and so on have equal standing. At least the 
most common two. This obviously isn't my decision to make, nor does my 
position on it really matter, but that is my opinion, and I believe it isn't 
so unfounded.

> In any case, what users do with the Workstation product isn't the
> point at all. The point is that the problem at hand is the
> firewalld.conf file, and *NOT* anything to do with the GNOME
> experience itself, or any part of any GNOME packages.

Well, the Workstation product is the GNOME Spin. It is *the* GNOME experience 
in Fedora. I do agree with "what users do with the Workstation product isn't 
the point at all", as it's not like we can predict what people will do with 
their system after it's installed.

> Yikes! Making a particular (graphical or otherwise) environment
> mandatory is a frightening idea for a Linux distro. "Have it your way"
> is what separates Linux from proprietary OSes.

I completely agree. It's what brought me to Fedora.

> Agreed, but nobody suggested that. Writing a kickstart specifically
> for the Workstation product seems like a sane thing to do if you want
> to PXE boot and automate a custom install based on Workstation for
> your entire office / school / library that you support as an IT
> person. And, to loop it back to the main point of this thread... if
> you were to do that, unless you took special steps to clobber
> firewalld.conf with your own, you'd be affected by the firewalld.conf
> default configuration without ever logging in to GNOME on any of those
> workstations. Again, the problem isn't GNOME... it's firewalld's
> default configuration in Workstation.

Writing a kickstart for Workstation would require you to base your package 
list on that of the Workstation kickstart.

The issue is not firewalld.conf, it's the package that Workstation pulls in 
through the group workstation-product, fedora-release-workstation.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread John Harris
On Thursday, August 29, 2019 11:17:11 AM MST Japheth Cleaver wrote:
> On 8/29/2019 8:10 AM, Adam Williamson wrote:
> 
> > On Wed, 2019-08-28 at 23:13 -0400, Christopher wrote:
> > 
> >> On Wed, Aug 28, 2019 at 8:56 PM John Harris 
> >> wrote:
> >> 
> >>> It might be okay to be a GNOME-specific thing, as that's the only spin
> >>> of
> >>> Fedora which is affected by this decision.
> >>>
> >>>
> >>>
> >> The default firewall config affects every user of that edition, even
> >> if they never use GNOME (or even use graphical boot). So, I don't know
> >> if this would be adequate.
> > 
> > Why would you install Workstation if you didn't intend to use GNOME?
> 
> 
> That would seem to be a reasonable question, but if it's possible to do 
> so then it is bound to happen... It may be a symptom of unclear definition.
> 
> If Workstation is going to require a graphical environment for 
> reasonable usage/administration/whatever, then it should be made 
> mandatory somehow. It would also help clarify that the Workstation, 
> Server, and  Products must be treated distinctly... and that you 
> shouldn't just point your kickstart file at whatever ISO you happen to 
> have laying around.

It shouldn't matter which ISO you use, as the package wouldn't be installed 
unless the kickstart pulls it in.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread John Harris
On Thursday, August 29, 2019 8:12:22 AM MST Dan Book wrote:
> I would agree, but people do install multiple desktops after installing a
> spin. Such a use case needs to be considered (not sure if it matters,
> though).

This is definitely not the ideal scenario, especially not from the case of the 
installer for the GNOME spin. I don't know if there's really any reason to 
consider it, as the user is taking things into their own hands at that point.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Christopher
On Thu, Aug 29, 2019 at 2:18 PM Japheth Cleaver  wrote:
>
> On 8/29/2019 8:10 AM, Adam Williamson wrote:
> > On Wed, 2019-08-28 at 23:13 -0400, Christopher wrote:
> >> On Wed, Aug 28, 2019 at 8:56 PM John Harris  wrote:
> >>> It might be okay to be a GNOME-specific thing, as that's the only spin of
> >>> Fedora which is affected by this decision.
> >>>
> >> The default firewall config affects every user of that edition, even
> >> if they never use GNOME (or even use graphical boot). So, I don't know
> >> if this would be adequate.
> > Why would you install Workstation if you didn't intend to use GNOME?
>
> That would seem to be a reasonable question, but if it's possible to do
> so then it is bound to happen... It may be a symptom of unclear definition.

Workstation is the primary product. Some choose that not for GNOME...
but because they want to start with the most base product and
customize from there. If you start with a Spin, you may get something
pre-configured in a very weird way... and with a smaller support
community.

In any case, what users do with the Workstation product isn't the
point at all. The point is that the problem at hand is the
firewalld.conf file, and *NOT* anything to do with the GNOME
experience itself, or any part of any GNOME packages.

>
> If Workstation is going to require a graphical environment for
> reasonable usage/administration/whatever, then it should be made
> mandatory somehow. It would also help clarify that the Workstation,

Yikes! Making a particular (graphical or otherwise) environment
mandatory is a frightening idea for a Linux distro. "Have it your way"
is what separates Linux from proprietary OSes.

> Server, and  Products must be treated distinctly... and that you
> shouldn't just point your kickstart file at whatever ISO you happen to
> have laying around.

Agreed, but nobody suggested that. Writing a kickstart specifically
for the Workstation product seems like a sane thing to do if you want
to PXE boot and automate a custom install based on Workstation for
your entire office / school / library that you support as an IT
person. And, to loop it back to the main point of this thread... if
you were to do that, unless you took special steps to clobber
firewalld.conf with your own, you'd be affected by the firewalld.conf
default configuration without ever logging in to GNOME on any of those
workstations. Again, the problem isn't GNOME... it's firewalld's
default configuration in Workstation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Christopher
On Thu, Aug 29, 2019 at 4:12 PM Chris Murphy  wrote:
>
> On Thu, Aug 29, 2019 at 12:24 AM Chris Murphy  wrote:
> >
> > Debian has a permissive firewall
> > https://wiki.debian.org/DebianFirewall
>
> And Ubuntu, Mint, elementary, MX Linux, Solus, pop!_OS, as well. By
> permissive, they all accept everything. Nothing is rejected or
> dropped.
>
> Mageia, and openSUSE do have a fair amount of iptables filtering
> entries. e.g. openSUSE Tumbleweed lastest snapshot,
> https://paste.fedoraproject.org/paste/TOJ1cdZpRWy2150N2O~IOw/raw
>
> I didn't test Zorin because I couldn't get passed the paywall, and for
> some reason Manjaro boots (kernel and initramfs) but then hangs during
> startup and I don't really want to troubleshoot it.
>
> Anyway, that rounds out the top ~10 distros, and Fedora Workstation is
> definitely not the most permissive.
>
>
> --
> Chris Murphy

It's my understanding that most of these don't do SELinux either. I
choose Fedora (and RH) products because I like the extra thought put
into security that other distros haven't necessary done. If I wanted
an insecure system, I'd have selected one of the countless ones listed
in this thread that people insist on comparing Fedora's firewall to.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Chris Murphy
On Thu, Aug 29, 2019 at 12:24 AM Chris Murphy  wrote:
>
> Debian has a permissive firewall
> https://wiki.debian.org/DebianFirewall

And Ubuntu, Mint, elementary, MX Linux, Solus, pop!_OS, as well. By
permissive, they all accept everything. Nothing is rejected or
dropped.

Mageia, and openSUSE do have a fair amount of iptables filtering
entries. e.g. openSUSE Tumbleweed lastest snapshot,
https://paste.fedoraproject.org/paste/TOJ1cdZpRWy2150N2O~IOw/raw

I didn't test Zorin because I couldn't get passed the paywall, and for
some reason Manjaro boots (kernel and initramfs) but then hangs during
startup and I don't really want to troubleshoot it.

Anyway, that rounds out the top ~10 distros, and Fedora Workstation is
definitely not the most permissive.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Japheth Cleaver

On 8/29/2019 8:10 AM, Adam Williamson wrote:

On Wed, 2019-08-28 at 23:13 -0400, Christopher wrote:

On Wed, Aug 28, 2019 at 8:56 PM John Harris  wrote:

It might be okay to be a GNOME-specific thing, as that's the only spin of
Fedora which is affected by this decision.


The default firewall config affects every user of that edition, even
if they never use GNOME (or even use graphical boot). So, I don't know
if this would be adequate.

Why would you install Workstation if you didn't intend to use GNOME?


That would seem to be a reasonable question, but if it's possible to do 
so then it is bound to happen... It may be a symptom of unclear definition.


If Workstation is going to require a graphical environment for 
reasonable usage/administration/whatever, then it should be made 
mandatory somehow. It would also help clarify that the Workstation, 
Server, and  Products must be treated distinctly... and that you 
shouldn't just point your kickstart file at whatever ISO you happen to 
have laying around.


-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Christophe de Dinechin

mcatanz...@gnome.org writes:

> Well the thing is, blocknig ports tends to break applications that want
> to use those ports. We're not going to do that, period. It also doesn't
> really accomplish anything: either your app or service needs network
> access and you have whitelisted it (in which case the firewall provides
> no security), or it needs network access and you have not whitelisted
> it (in which case your firewall breaks your app/service). In no case
> does it increase your security without breaking your app, right? Unless
> you have malware installed (in which case, you have bigger problems
> than the firewall). Or unless you have a vulnerable network service
> installed that you don't want (in which case, uninstall it).
>
> So if you want to change the firewall settings, you'd need to
> completely rethink how the firewall works. And nobody seems interested
> in doing that. We could e.g. have a list of apps that are allowed
> network access, but then we'd need some form of attestation so apps
> can't impersonate each other. So only sandboxed (flatpaked) apps could
> use this hypothetical new firewall. And we surely don't want to have
> yes/no permission prompts, so we can't really ask the user "do you want
> your app to access the network?" (the user will almost always say
> yes).

For what it's worth, macOS started doing exactly that recently.
I agree it seems useless, except for one thing. Sometimes, you realize
that some app is opening a port when you don't expect it.

> I'm not really sure what design would even work.
>
> Avoiding unnecessary network services makes more sense.
>
> On Mon, Aug 26, 2019 at 3:45 PM, Alexander Ploumistos
>  wrote:
>>
>> As a matter of fact, you did:
>> 
>> 
>
> Thanks for dredging up these links!
>
> Michael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--
Cheers,
Christophe de Dinechin (IRC c3d)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Dan Book
On Thu, Aug 29, 2019 at 11:11 AM Adam Williamson 
wrote:

> On Wed, 2019-08-28 at 23:13 -0400, Christopher wrote:
> > On Wed, Aug 28, 2019 at 8:56 PM John Harris 
> wrote:
> > > On Wednesday, August 28, 2019 5:46:58 PM MST Christopher wrote:
> > > > A similar idea that would keep it separate from the installer might
> be
> > > > to offer a dialogue as a "first-boot" action, but that seems like
> it'd
> > > > be a very GNOME-specific thing, and firewalld is not specific to the
> > > > WM/Desktop.
> > >
> > > It might be okay to be a GNOME-specific thing, as that's the only spin
> of
> > > Fedora which is affected by this decision.
> > >
> >
> > The default firewall config affects every user of that edition, even
> > if they never use GNOME (or even use graphical boot). So, I don't know
> > if this would be adequate.
>
> Why would you install Workstation if you didn't intend to use GNOME?
>

I would agree, but people do install multiple desktops after installing a
spin. Such a use case needs to be considered (not sure if it matters,
though).

-Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Adam Williamson
On Wed, 2019-08-28 at 23:13 -0400, Christopher wrote:
> On Wed, Aug 28, 2019 at 8:56 PM John Harris  wrote:
> > On Wednesday, August 28, 2019 5:46:58 PM MST Christopher wrote:
> > > A similar idea that would keep it separate from the installer might be
> > > to offer a dialogue as a "first-boot" action, but that seems like it'd
> > > be a very GNOME-specific thing, and firewalld is not specific to the
> > > WM/Desktop.
> > 
> > It might be okay to be a GNOME-specific thing, as that's the only spin of
> > Fedora which is affected by this decision.
> > 
> 
> The default firewall config affects every user of that edition, even
> if they never use GNOME (or even use graphical boot). So, I don't know
> if this would be adequate.

Why would you install Workstation if you didn't intend to use GNOME?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Iñaki Ucar
Responding to the first message because I'm not interested in further
discussion. It's clear to me that there will be no agreement in this
matter unless there are reasonable potential alternatives. Therefore,
this message is just to let you all know that I'm at least trying to
push for better alternatives. In particular, these:

https://bugs.kde.org/show_bug.cgi?id=411359
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1550
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/650

You are welcome to help with the above, or bring them to other
desktops. Hopefully, if these proposals get accepted and implemented,
we could eventually bring back this discussion and reach some
consensus.

Iñaki


On Mon, 26 Aug 2019 at 14:40, Vitaly Zaitsev via devel
 wrote:
>
> Hello all.
>
> Is it okay that firewall is completely disabled by default (opened all
> ports 1025-65535) on Fedora Workstation?
>
> I think that this is a major vulnerability and it must be fixed by
> changing default zone to public.
>
> firewall-cmd --list-all
> FedoraWorkstation (active)
>   target: default
>   icmp-block-inversion: no
>   interfaces: enp1s0
>   sources:
>   services: dhcpv6-client mdns samba-client ssh
>   ports: 1025-65535/udp 1025-65535/tcp
>   protocols:
>   masquerade: no
>   forward-ports:
>   source-ports:
>   icmp-blocks:
>   rich rules:
>
> --
> Sincerely,
>   Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



--
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread Chris Murphy
Debian has a permissive firewall
https://wiki.debian.org/DebianFirewall
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-29 Thread John Harris
On Wednesday, August 28, 2019 10:31:54 PM MST Christopher wrote:
> We're getting off-topic, but really quickly: Yes, you can select
> advanced packaging (at least you could in the past... probably still
> can). You can also use kickstart to automate installs with custom
> package installations and configuration using the same Workstation
> ISO, and you can also just open a new TTY (e.g. Ctrl+Alt+F3),
> customize your system, and reboot without ever logging in to GNOME.

I don't know how that would possibly pull in the GNOME Spin's firewall config, 
if you select a different set entirely, unless they're doing some odd package 
mangling that I'm not aware of.

I'm not talking about users that do the default install, and then switch to a 
TTY, because that's going to be a very small number of the userbase of the 
Workstation product.

> It's not "GNOME's firewall zone". As previously mentioned, it's not
> pulled in by GNOME at all. Rather, it's being provided by the
> firewalld RPM itself, and configured by default, based on the contents
> of /etc/os-release (which is provided by the
> fedora-release-workstation RPM).

It is specific to the GNOME Spin. I don't imagine /etc/os-release would be set 
to that when another package set is selected, if that's even possible with the 
GNOME Spin's installer. Simply using the install media is not enough to put 
the fedora-release-workstation package into other options' package sets.

> The main point is that it's not GNOME-specific at all, but it is
> Workstation Edition-specific.

That's what I'm referring to as the GNOME Spin, because it's not fair to call 
it anything else, unless you're talking about how it's able to do all kinds of 
nonsense, like this, that Spins can't get away with. Calling it "Workstation", 
when speaking of anything other than the name it's adopted and been approved 
with, is dishonest at best, as it's certainly not the only workstation option 
in Fedora, nor is it the best, which is subjective. This is an important 
distinction, which needs to be made at some point.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Christopher
On Thu, Aug 29, 2019 at 1:08 AM John Harris  wrote:
>
> On Wednesday, August 28, 2019 10:00:35 PM MST Christopher wrote:
> > No, the default firewalld zone affects all Fedora Workstation users,
> > because firewalld runs outside of GNOME. Just because a user uses the
> > Workstation Edition doesn't mean they're running GNOME... you can
> > still run Cinnamon, XFCE, MATE, KDE, (or no graphical environment at
> > all) using the Workstation Edition. It's just that GNOME is the
> > default. So, this isn't a GNOME-specific issue. This is a Workstation
> > Edition issue with /etc/firewalld/firewalld.conf's DefaultZone option.
>
> How is that possible? The workstation installer installs GNOME, right? Can you
> select something else in those ISOs' Anaconda config? If so, why would it
> still pull in GNOME's firewall zone?
[SNIP]

We're getting off-topic, but really quickly: Yes, you can select
advanced packaging (at least you could in the past... probably still
can). You can also use kickstart to automate installs with custom
package installations and configuration using the same Workstation
ISO, and you can also just open a new TTY (e.g. Ctrl+Alt+F3),
customize your system, and reboot without ever logging in to GNOME.

It's not "GNOME's firewall zone". As previously mentioned, it's not
pulled in by GNOME at all. Rather, it's being provided by the
firewalld RPM itself, and configured by default, based on the contents
of /etc/os-release (which is provided by the
fedora-release-workstation RPM).

The main point is that it's not GNOME-specific at all, but it is
Workstation Edition-specific.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 10:00:35 PM MST Christopher wrote:
> No, the default firewalld zone affects all Fedora Workstation users,
> because firewalld runs outside of GNOME. Just because a user uses the
> Workstation Edition doesn't mean they're running GNOME... you can
> still run Cinnamon, XFCE, MATE, KDE, (or no graphical environment at
> all) using the Workstation Edition. It's just that GNOME is the
> default. So, this isn't a GNOME-specific issue. This is a Workstation
> Edition issue with /etc/firewalld/firewalld.conf's DefaultZone option.

How is that possible? The workstation installer installs GNOME, right? Can you 
select something else in those ISOs' Anaconda config? If so, why would it 
still pull in GNOME's firewall zone?

> Funny, the FedoraServer.xml file still has a description "For use in
> public areas" while FedoraWorkstation.xml does not... as if servers
> are more likely than workstations to travel to "public areas" often.

You know, laptops move between networks a lot more frequently than servers. 
The majority of those would be running GNOME spin (Workstation), KDE spin or 
another DE's spin.

> :) I know it's because the server zone was derived from the public
> zone, which has that description, but it is still amusing.

That's because servers are often public facing, but so are laptops when 
they're on unknown networks, or even on peoples' own home networks, where we 
want a decent `trusted` config.

> FWIW, I actually prefer the public zone on my Workstation installs...
> and... it's actually the default upstream. Honestly, I'd prefer we
> just stick to that across all Editions/Spins.

As would I.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Christopher
On Wed, Aug 28, 2019 at 11:23 PM John Harris  wrote:
>
> On Wednesday, August 28, 2019 8:13:59 PM MST Christopher wrote:
> > The default firewall config affects every user of that edition, even
> > if they never use GNOME (or even use graphical boot). So, I don't know
> > if this would be adequate.
>
> This only affects GNOME users. Workstation = GNOME Spin.

No, the default firewalld zone affects all Fedora Workstation users,
because firewalld runs outside of GNOME. Just because a user uses the
Workstation Edition doesn't mean they're running GNOME... you can
still run Cinnamon, XFCE, MATE, KDE, (or no graphical environment at
all) using the Workstation Edition. It's just that GNOME is the
default. So, this isn't a GNOME-specific issue. This is a Workstation
Edition issue with /etc/firewalld/firewalld.conf's DefaultZone option.

>
> Unless I'm mistaken, and that installer is a generic Anaconda installer, where
> users can select the end product they want installed, in which case I'd have
> to ask why in the world that config would get pulled into the resulting
> system..

The configuration is being set in the resulting system by the
firewalld.spec itself when the firewalld RPM is installed:
See 
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/firewalld.spec#_122-136
and 
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/firewalld.spec#_154-174
and 
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/FedoraWorkstation.xml#_7-9

For comparison, the FedoraServer.xml is much more secure:
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/FedoraServer.xml

Funny, the FedoraServer.xml file still has a description "For use in
public areas" while FedoraWorkstation.xml does not... as if servers
are more likely than workstations to travel to "public areas" often.
:) I know it's because the server zone was derived from the public
zone, which has that description, but it is still amusing.

FWIW, I actually prefer the public zone on my Workstation installs...
and... it's actually the default upstream. Honestly, I'd prefer we
just stick to that across all Editions/Spins.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 8:13:59 PM MST Christopher wrote:
> The default firewall config affects every user of that edition, even
> if they never use GNOME (or even use graphical boot). So, I don't know
> if this would be adequate.

This only affects GNOME users. Workstation = GNOME Spin.

Unless I'm mistaken, and that installer is a generic Anaconda installer, where 
users can select the end product they want installed, in which case I'd have 
to ask why in the world that config would get pulled into the resulting 
system..

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Christopher
On Wed, Aug 28, 2019 at 8:56 PM John Harris  wrote:
>
> On Wednesday, August 28, 2019 5:46:58 PM MST Christopher wrote:
> > A similar idea that would keep it separate from the installer might be
> > to offer a dialogue as a "first-boot" action, but that seems like it'd
> > be a very GNOME-specific thing, and firewalld is not specific to the
> > WM/Desktop.
>
> It might be okay to be a GNOME-specific thing, as that's the only spin of
> Fedora which is affected by this decision.
>

The default firewall config affects every user of that edition, even
if they never use GNOME (or even use graphical boot). So, I don't know
if this would be adequate.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread James Cassell
On Wed, Aug 28, 2019, at 8:59 PM, John Harris wrote:
> On Wednesday, August 28, 2019 1:35:32 PM MST Colin Walters wrote:
> > FWIW,
> > 
> > For Fedora CoreOS we don't enable a firewall by default; see
> > https://github.com/coreos/fedora-coreos-tracker/issues/26
> > 
> > (Neither for that matter does Fedora Cloud:
> >  https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_36)
> 
> Yikes! I suppose we should discuss these as well. Those are, in my opinion, 
> much more serious, as they COMPLETELY shut off the firewall. Especially for 
> what those systems are designed for, this is very concerning..
> 

This seems to be a common theme with cloud images. I believe the assumption is 
that each cloud has its own Access Control policies that serve the function of 
a firewall.

I always end up building my own cloud images with a firewall, partly for this 
reason.

I would tend to agree that Fedora Core OS should have a firewall, if only to 
well-define which ports are required; but I have not been active there.

V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 1:35:32 PM MST Colin Walters wrote:
> FWIW,
> 
> For Fedora CoreOS we don't enable a firewall by default; see
> https://github.com/coreos/fedora-coreos-tracker/issues/26
> 
> (Neither for that matter does Fedora Cloud:
>  https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_36)

Yikes! I suppose we should discuss these as well. Those are, in my opinion, 
much more serious, as they COMPLETELY shut off the firewall. Especially for 
what those systems are designed for, this is very concerning..

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 5:46:58 PM MST Christopher wrote:
> A similar idea that would keep it separate from the installer might be
> to offer a dialogue as a "first-boot" action, but that seems like it'd
> be a very GNOME-specific thing, and firewalld is not specific to the
> WM/Desktop.

It might be okay to be a GNOME-specific thing, as that's the only spin of 
Fedora which is affected by this decision.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 3:50:49 PM MST Chris Murphy wrote:
> A somewhat related feature that was rejected by FESCo
> https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
> https://lists.fedoraproject.org/pipermail/devel/2014-March/19.html

Security policies aren't related to the firewall, though they may include 
changes to the firewall (and blacklisting packages, etc). That's something 
much better suited for RHEL and CentOS though. Firewalls are useful 
everywhere.

> Again, hyperbole, that cannot be taken seriously, because it does not
> withstand even a little bit of scrutiny.

I must disagree, as it does stand up to scrutiny.
 
> I'm recently a member on the Workstation working group, I know the
> members on it. The reason why everyone is on it is because they care
> very much about, and respect the community immensely, and demonstrate
> it with deliberation and significant effort.

That's fantastic, and that's why we want to work with the WG to fix this issue 
with the product. We all want to make things better for the community.
 
> It's not good enough to just say things forcefully and expect that
> people will agree as if you're a hammer, and they're a nail. You have
> to work harder than you are working, if your goal really is to be
> persuasive.

Unfortunately, that doesn't change the security concerns with having a wide 
open firewall by default.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Christopher
On Wed, Aug 28, 2019 at 6:52 PM Chris Murphy  wrote:
>
> On Wed, Aug 28, 2019 at 12:57 PM Christopher  
> wrote:
> >
> > At the very least, it'd be nice if anaconda had an option to select
> > the default firewalld zone during installation,
>
> A somewhat related feature that was rejected by FESCo
> https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
> https://lists.fedoraproject.org/pipermail/devel/2014-March/19.html

I think the fact that the Workstation WG's proceeded with an
effectively disabled firewall after FESCo rejected the complete
disabling of it, somewhat undermines your point here about rejection
of a similar proposal being relevant to the current one.

In any case, I don't think these are that similar. I think this is
sufficiently different from that proposal. This is much more narrowly
scoped that a whole new security policy dialogue. It would be limited
to just an UI element in the existing network configuration
dialogue... in the same spirit as the familiar NetworkManager zone
selection dropdown that I recall seeing at some point (but not sure if
it's still there). It'd barely be different than adding "WPA3" as an
option to the same section of the installer (I use as an example,
because I think it's safe to assume that's the kind of installer
feature change that would be readily accepted).

>
> Neat idea. But complicates an already complicated installer. Many
> responses in that at the time, in devel@ and FESCo, were concerned
> about balancing out users even though they liked the overall idea.

Yeah, I also don't want a complicated installer. I just don't see this
disagreement going anywhere without some sort of compromise, and I
can't think of any others that will satisfy people. I think there's a
good chance this could be implemented without much complexity, though.
Thank you for giving the idea at least a little consideration, though,
and not outright dismissing it.

A similar idea that would keep it separate from the installer might be
to offer a dialogue as a "first-boot" action, but that seems like it'd
be a very GNOME-specific thing, and firewalld is not specific to the
WM/Desktop.

>
> Working group members have to make UI/Ux judgements all the time, and
> things not going the way you would have is not a good enough reason to
> impugn those making these decisions. You could have just said you
> disagree. But you went much further. You assert there is not only a
> lack of respect for the community, but that is it a complete lack. 0%.
> Not even 50/50?
>
> Again, hyperbole, that cannot be taken seriously, because it does not
> withstand even a little bit of scrutiny.
>

My statement was intended to be qualitative, not quantitative, but I
take your point. Yes, it was, in fact, hyperbole, and I apologize for
my poor word choice.

> I'm recently a member on the Workstation working group, I know the
> members on it. The reason why everyone is on it is because they care
> very much about, and respect the community immensely, and demonstrate
> it with deliberation and significant effort.

I'm sure that's true. I have no reason to doubt any of that. My
statements aren't about them as individuals... I've tried to be
careful about that, because 1) I don't think it's helpful to call out
individuals here, and 2) I don't think what I've said about the group
applies to the individuals (see
https://en.wikipedia.org/wiki/Fallacy_of_division).

>
> It's not good enough to just say things forcefully and expect that
> people will agree as if you're a hammer, and they're a nail. You have
> to work harder than you are working, if your goal really is to be
> persuasive.

I have tried to point to specific actions taken (or not taken) by the
WG that I think demonstrate the previous lack of respect I referred
to. I am not simply trying to persuade by saying things "forcefully"
(however that works). If you are not persuaded, that's fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 12:59:17 PM MST Christopher wrote:
> Yeah, obviously that would be bad. Please don't simply dismiss a
> serious suggestion, because it would be bad in other scenarios or if
> taken to the extreme. This is one specific suggestion, not a proposal
> to accept all similar suggestions, and I'm not even convinced myself
> that this is the best possible solution. It just seemed like an idea
> worth considering, since the debate is raging on, has been raging on
> and off since 2014, and this proposal seems like it has potential to
> satisfy all parties once and for all (since it gets directly to the
> heart of the matter, eliminates user surprise, and fits naturally
> within the existing network setup portion of Anaconda).

That sounds like a great idea, with the rest of the configuration options for 
a given interface. That falls in line with where I'd expect the configuration 
option to be in the GUI in GNOME, and where it currently is in KDE. (I don't 
know if it's there in GNOME, but I think somebody earlier in the thread 
mentioned that it was removed)

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 10:00:03 AM MST Chris Murphy wrote:
> This is hyperbole, and turning up the volume isn't going to make
> anyone go "oh, ok, now I see your point, it's hostile and we don't
> want to do that, let's change it" as if literally everyone reading
> this is some kind of moron.

I disagree. The description is a response to the earlier suggestion, that 
because something is already insecure, to a certain degree, that it should 
just be left that way.

> 
> Your position is shown to be weak if you have to use this distinctly
> non-objective tactic designed to evoke an emotional response in the
> reader. All you're doing is casually dismissing one side of a
> balancing act and then claiming the result as proof the policy should
> change. Guess what? Saying things does not make them true.

You're welcome to your opinion, but that doesn't make it so. I'm not 
dismissing anything.

> You should try to understand all of these arguments have happened
> before, and if you really want a change to happen, you need a produce
> a compelling new arguments.

See my other responses to this thread.

> Did the previous working group misunderstand something previously?

It seem so.

> Has new information come to light?

Yes, more people have realized what was done by the GNOME spin.

> Has the GUI firewall app made UI/Ux improvements that might sway the
> working group to re-evaluate?

Possibly, but that doesn't have anything to do with what needs to be done to 
provide our users with a more secure default.

> By all means shout more. And be ignored. Or do the hard work and put
> together a deliberate and compelling argument.

I have been addressing concerns as I see them. If you have a concern I have 
not addressed, please feel free to ask.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 9:05:00 AM MST Tony Nelson wrote:
> Properly packaged Fedora software uses either the D-Bus interface
> at runtime or firewall-cmd in a scriptlet at install time to open any
> needed ports

This is not actually the case. No software, to my knowledge, makes the 
assumption that it's configured properly and ready to be open to the network, 
on installation.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Chris Murphy
On Wed, Aug 28, 2019 at 12:57 PM Christopher  wrote:
>
> At the very least, it'd be nice if anaconda had an option to select
> the default firewalld zone during installation,

A somewhat related feature that was rejected by FESCo
https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
https://lists.fedoraproject.org/pipermail/devel/2014-March/19.html

Neat idea. But complicates an already complicated installer. Many
responses in that at the time, in devel@ and FESCo, were concerned
about balancing out users even though they liked the overall idea.

Working group members have to make UI/Ux judgements all the time, and
things not going the way you would have is not a good enough reason to
impugn those making these decisions. You could have just said you
disagree. But you went much further. You assert there is not only a
lack of respect for the community, but that is it a complete lack. 0%.
Not even 50/50?

Again, hyperbole, that cannot be taken seriously, because it does not
withstand even a little bit of scrutiny.

I'm recently a member on the Workstation working group, I know the
members on it. The reason why everyone is on it is because they care
very much about, and respect the community immensely, and demonstrate
it with deliberation and significant effort.

It's not good enough to just say things forcefully and expect that
people will agree as if you're a hammer, and they're a nail. You have
to work harder than you are working, if your goal really is to be
persuasive.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Colin Walters
FWIW,

For Fedora CoreOS we don't enable a firewall by default; see
https://github.com/coreos/fedora-coreos-tracker/issues/26

(Neither for that matter does Fedora Cloud:
 https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_36 )
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Dan Book
On Wed, Aug 28, 2019 at 4:27 PM Adam Williamson 
wrote:

> That is talking about the whole idea that having a firewall enabled by
> default is not as important if there are no listening services by
> default; at that point you can make the argument that installing a
> service that listens on a port is a conscious decision to "open" that
> port.
>

And we are expecting this apparent target audience of people that don't
understand the firewall GUI to understand that installing such a service is
a conscious decision to open a port?

-Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Adam Williamson
On Wed, 2019-08-28 at 22:32 +0300, mcatanz...@gnome.org wrote:
> On Wed, Aug 28, 2019 at 9:56 PM, Christopher 
>  wrote:
> > 2) the Workstation WG has not only taken no action in response to the
> > FESCo statement of trust at the conclusion of our last lengthy
> > discussion on this matter, it has been explicitly stated in this
> > thread that they have never had any intention of doing anything
> > further, even though that was FESCo's clear expectation.
> 
> In January 2015, FESCo said:
> 
> """
> AGREED: FESCo trusts the Workstation WG to properly research and 
> develop a sensible firewall solution and will stay out of the way. (+5, 
> 3, -0) (sgallagh, 18:40:04)
> """
> 
> 
> 
> It reads to me like an affirmation of the work that had been done for 
> Fedora 21:
> 
> 
> 
> I don't think a reasonable person reading the thread could plausibly 
> conclude that FESCo expected further work.

Here is the actual log of the meeting that produced that conclusion:

https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2015-01-07-18.01.log.txt

It's a pretty...messy discussion. I would say there was clearly an
expectation at the start that there would be further ongoing work:


18:07:31  I don't think anyone is perfectly happy with the
current state (is that a fair statement?)
18:07:51  fair understatement, maybe even
18:08:01  I'm not sure we need to discuss solutions here tho...
18:08:10  nirik, +1
18:08:15  unless we feel that it's worth overriding the
workstation working group.
18:08:20  sgallagh: I am reasonably happy with the current
capabilities _of the firewall_ actually.  I am very much wishing for
reliable sandboxing which would replace some of the firewall uses but
is not actually a firewall.
18:08:22  which IMHO, I am -1 to
18:08:25  nirik: Well, we need to try to agree on an end-
experience, not necessarily an implementation
18:08:38  mitr, +1
18:08:41  the long term goals were mentioned in my mail to
fedora workstation, definitely not finished, but certainly on the right
path

But at the same time, there's a fairly strong vein of feeling that
FESCo shouldn't override the WG here and should basically leave the WG
to do whatever it wanted to do. I think my interpretation would be
that, as of the meeting, FESCo was willing to delegate this topic
entirely to the WG; it was *expecting* further work to happen, but it
did not *require* it, and I don't think you could say the conclusion at
the meeting was incompatible with the WG simply leaving everything as-
is.

There are a couple of other interesting notes along the way, especially
this one (for me):

18:33:08  Proposal 2) The automated tests to make sure that
nothing in Fedora is listening by default unless on a strictly
maintained whitelist are a blocker for F22.

That is talking about the whole idea that having a firewall enabled by
default is not as important if there are no listening services by
default; at that point you can make the argument that installing a
service that listens on a port is a conscious decision to "open" that
port. It seems there was an expectation around this time that testing
to ensure that this was actually the case should be automated. At the
time this was expected to happen in Taskotron, but I don't believe it
ever has.

I think we could implement this in openQA relatively easily, and check
that it's in the release criteria and validation tests. Assuming folks
still think this would be valuable, I'll file a ticket for us to work
on that.

I must also congratulate mclasen for this, given Christopher's comment
that Michael replied to:

"18:20:33 * mclasen waits for the suggestion to ask in the installer"

It took four years, but here we are ;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Christopher
On Wed, Aug 28, 2019 at 3:33 PM  wrote:
>
> On Wed, Aug 28, 2019 at 9:56 PM, Christopher  
> wrote:
>
> 2) the Workstation WG has not only taken no action in response to the FESCo 
> statement of trust at the conclusion of our last lengthy discussion on this 
> matter, it has been explicitly stated in this thread that they have never had 
> any intention of doing anything further, even though that was FESCo's clear 
> expectation.
>
>
> In January 2015, FESCo said:
>
> """
> AGREED: FESCo trusts the Workstation WG to properly research and develop a 
> sensible firewall solution and will stay out of the way. (+5, 3, -0) 
> (sgallagh, 18:40:04)
> """
>
> https://pagure.io/fesco/issue/1372#comment-27998
>
> It reads to me like an affirmation of the work that had been done for Fedora 
> 21:
>
> http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html
>
> I don't think a reasonable person reading the thread could plausibly conclude 
> that FESCo expected further work.

I consider myself generally reasonable, and that's precisely what I
concluded, since 1) it was written in response to a request for a
change (further work) in the context of a heated debate where one side
was demanding the change, and 2) the grammatical context is all
present and future tense, and not past tense in any way. Notably, they
did not say "trusts the Workstation WG has properly researched and
developed a sensible solution". I'm a native (American-)English
speaker, and while I'll admit it's possible the phrasing could be
interpreted as an affirmation, to me it implies the work is to be
done. It is entirely possible I'm misinterpreting the intent... I'll
grant you that. We can ask for clarity or FESCo to re-consider the
matter.

>
> At the very least, it'd be nice if anaconda had an option to select
> the default firewalld zone during installation
>
>
> Imagine if Anaconda had an option for every time someone suggested it 
> should

Yeah, obviously that would be bad. Please don't simply dismiss a
serious suggestion, because it would be bad in other scenarios or if
taken to the extreme. This is one specific suggestion, not a proposal
to accept all similar suggestions, and I'm not even convinced myself
that this is the best possible solution. It just seemed like an idea
worth considering, since the debate is raging on, has been raging on
and off since 2014, and this proposal seems like it has potential to
satisfy all parties once and for all (since it gets directly to the
heart of the matter, eliminates user surprise, and fits naturally
within the existing network setup portion of Anaconda). This proposal
was an attempt to seek out a compromise. Please don't be so dismissive
of the attempt.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread mcatanzaro
On Wed, Aug 28, 2019 at 9:56 PM, Christopher 
 wrote:

2) the Workstation WG has not only taken no action in response to the
FESCo statement of trust at the conclusion of our last lengthy
discussion on this matter, it has been explicitly stated in this
thread that they have never had any intention of doing anything
further, even though that was FESCo's clear expectation.


In January 2015, FESCo said:

"""
AGREED: FESCo trusts the Workstation WG to properly research and 
develop a sensible firewall solution and will stay out of the way. (+5, 
3, -0) (sgallagh, 18:40:04)

"""



It reads to me like an affirmation of the work that had been done for 
Fedora 21:




I don't think a reasonable person reading the thread could plausibly 
conclude that FESCo expected further work.



At the very least, it'd be nice if anaconda had an option to select
the default firewalld zone during installation


Imagine if Anaconda had an option for every time someone suggested it 
should


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Christopher
On Wed, Aug 28, 2019 at 1:01 PM Chris Murphy  wrote:
>
> On Wed, Aug 28, 2019 at 9:36 AM John Harris  wrote:
>
> > Essentially disabling the firewall falls under having a "bad design for
> > everyone else". Disabling the firewall is something that could be considered
> > hostile to the user.
>
> This is hyperbole, and turning up the volume isn't going to make
> anyone go "oh, ok, now I see your point, it's hostile and we don't
> want to do that, let's change it" as if literally everyone reading
> this is some kind of moron.
>
[SNIP]

This isn't hyperbole. This is disagreement. Nobody called anybody a
moron. John simply highlighted Jiri's statement of "bad design for
everyone else" as subjective, and there are those who can see it
differently; there those of us that consider the current status quo to
be of "bad design", possibly even hostile. This is just a difference
of opinion, because "bad design" is subjective.

Because it is subjective, I don't think this is going to be solved
easily (consensus gathering is hard). Right now... from the
participants... it seems pretty split. I wish we had a way of polling
the community to get a sense of the community consensus on the matter.

For me, the biggest thing that upsets me is that:

1) it seems FESCo's previous rejection of the change proposal seems to
have been ignored in spirit, even though it wasn't technically
ignored, and
2) the Workstation WG has not only taken no action in response to the
FESCo statement of trust at the conclusion of our last lengthy
discussion on this matter, it has been explicitly stated in this
thread that they have never had any intention of doing anything
further, even though that was FESCo's clear expectation.

To me, these two facts demonstrate a complete lack of respect for the
community and its elected representatives. The appearance is that the
WG will do what it wants no matter what the community thinks (even if
the community consensus were on their side... which is still
uncertain). It also makes it appear that Fedora governance is weak...
a puppet to the whims of those who don't necessarily represent the
whole community. This seems like a very unhealthy state for Fedora to
be in right now. I'm just disappointed in how this has played out.

At the very least, it'd be nice if anaconda had an option to select
the default firewalld zone during installation, so users had a choice
to select "public - more secure, but some firewall configuration
changes may need to made to allow some applications to work" or
"trusted - more open, but may expose your computer's applications to
malicious actors on the networks you connect to" with a comment that
"you can change this later; see ". Then, you don't need to
worry about what the default is... nobody could claim surprise by the
setting. If this option existed during installation in an obvious way
during network setup, I wouldn't even care if "trusted" was selected
by default, because changing it would be simple.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Chris Murphy
On Wed, Aug 28, 2019 at 9:36 AM John Harris  wrote:

> Essentially disabling the firewall falls under having a "bad design for
> everyone else". Disabling the firewall is something that could be considered
> hostile to the user.

This is hyperbole, and turning up the volume isn't going to make
anyone go "oh, ok, now I see your point, it's hostile and we don't
want to do that, let's change it" as if literally everyone reading
this is some kind of moron.

Your position is shown to be weak if you have to use this distinctly
non-objective tactic designed to evoke an emotional response in the
reader. All you're doing is casually dismissing one side of a
balancing act and then claiming the result as proof the policy should
change. Guess what? Saying things does not make them true.

You should try to understand all of these arguments have happened
before, and if you really want a change to happen, you need a produce
a compelling new arguments. Did the previous working group
misunderstand something previously? Has new information come to light?
Has the GUI firewall app made UI/Ux improvements that might sway the
working group to re-evaluate?

By all means shout more. And be ignored. Or do the hard work and put
together a deliberate and compelling argument.

> I fail to see how the comparison to MacOS applies here.

Tons of installations. 1% of their user base dwarfs ours. If firewall
disabled by default were so hideously flawed, there'd be a million
users getting malware, and we'd hear about it including and autopsy
report saying, effectively, Apple's crazy because their firewall would
have prevented this. But that isn't happening.

Windows is likewise a fair contra example, but I can't assess to what
degree their firewall is a security strategy that helps prevent
infections, versus reputation repair. And that is in some sense where
we are right now. Do we have examples of penetrated systems that the
firewall would have prevented? This is a real problem, a theoretical
problem that can be tested unambiguously, or is it purely
hypothetical? It's definitely a problem when people's applications
silently fail to work in weird ways and is non-obvious that the cause
is the firewall.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Tony Nelson

On 19-08-28 01:03:51, Chris Murphy wrote:
On Tue, Aug 27, 2019 at 10:26 PM Christopher  
 wrote:

>
> On Tue, Aug 27, 2019 at 9:27 PM Chris Murphy  
 wrote:

>
> > The Workstation technical specification document says in part:
>
> Where is the full technical specification document, so one can read  
it

> not in part, but in full?

https://fedoraproject.org/wiki/Workstation/Technical_Specification

The discussion and decision to not include firewall-config (GUI
configuration application for firewalld) by default, five years ago
https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/thread/QROJ6LHGT5UUMNTBXEIJTPHPI3IWGFRY/

What's changed since then? It's fine to have purposeful re-evaluation
of any requirements or specification, but someone or a group need to
look through the prior history, and clearly articulate why that
history is obsolete, and produce a compelling case why this should be
re-evaluated.

 ...

Well, they promised to be responsible and it is asserted that an open
firewall is not responsible, and they said they would develp solutions
but they opened the firewall instead, and they haven't shown an actual
example of software available through gnome-software (the only supported
way to install software on Gnome and Fedora Workstation) that needs the
firewall to be already open.  Properly packaged Fedora software uses
either the D-Bus interface at runtime or firewall-cmd in a scriptlet at
install time to open any needed ports, so an example of software that
works only because the ports are already open would be good.

Note that software needing open inbound ports will usually need ports
opened (or a service enabled) on some router, along with setup to direct
incoming connections to the correct internal IP, so it can't work OOB.
It's possible that there is some confusion here, and Gnome thinks that
outbound ports need to be opened and that that is what they have done.

I haven't needed to do anything with firewalld on my machines in the
last few years, and my zone is "public", so I'm not very familiar with
firewalld.  (I use XFCE, not Workstation.)

--

TonyN.:'   
  '  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 2:45:37 AM MST Björn Persson wrote:
> If an attacker guesses your passphrase, then it's your weak passphrase
> that allows them to break in.

No. Having it wide open to the network means it can be broken, even through 
brute force if necessary.

> (That said, I'd be in favor of tightening the default SSHD
> configuration to allow only public key authentication, as long as it
> would still be possible to gain initial access to a freshly installed
> headless server.)

That would make it hard for "our moms and dads" to use, so I'm not sure that's 
a good idea.

> I have no idea what you mean by "running local".

A program that binds either your currently configured interface(s) or all 
interfaces by default. These are not at all uncommon. Some of them are 
designed for local access only, and yet they still bind all interfaces.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Wednesday, August 28, 2019 3:33:48 AM MST Jiri Eischmann wrote:
> Adam Williamson píše v Út 27. 08. 2019 v 16:01 -0700:
> 
> > On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:
> > 
> > > mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:
> > > 
> > > > On Tue, Aug 27, 2019 at 4:22 AM, John Harris <
> > > > joh...@splentity.com>
> > > > wrote:
> > > > 
> > > > > No, that is not how this works, at all. First, let's go ahead
> > > > > and
> > > > > address the 
> > > > > idea that "if the firewall blocks it, the app breaks, so it's
> > > > > the
> > > > > firewall's 
> > > > > fault": It's not. If the firewall has not been opened, that
> > > > > just
> > > > > means it 
> > > > > can't be accessed by remote systems until you EXPLICITLY open
> > > > > that
> > > > > port, with 
> > > > > the correct protocol, on your firewall. That's FINE. That's how
> > > > > it's designed 
> > > > > to work. There's nothing wrong with that.
> > > > > 
> > > > > This means that the system administrator (or owner, if this is
> > > > > some 
> > > > > individual's personal system) must allow the port to be
> > > > > accessed
> > > > > remotely, 
> > > > > before the app can be reached remotely, increasing the security
> > > > > of
> > > > > the system.
> > > > 
> > > > 
> > > > You've already lost me here. Sorry, but we do not and will not
> > > > install a firewall GUI that exposes complex technical details
> > > > like
> > > > port numbers. Expecting users to edit firewall rules to use their
> > > > apps is ridiculous and I'm not really interested in debating it.
> > > 
> > > 
> > > Yeah, when you ask users questions they're not qualified to answer,
> > > you're just creating bad design.
> > > I always imagine my mom (who BTW has been a Fedora user for years)
> > > how
> > > she'd deal with that and I can't really imagine her opening/closing
> > > firewall ports. She'd be puzzled even by "Do you trust this
> > > network?"
> > > and would probably just click "Yes" to make it go away. No
> > > additional
> > > security, just annoying UX.
> > 
> > 
> > However, Fedora Workstation is an edition. Which means it has a
> > *policy-defined* target audience. That target audience is defined
> > here:
> > https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> > 
> > 
> > Case 1: "Engineering/CS student"
> > Case 2: "Independent Developer"
> > Case 3: "Small Company Developer"
> > Case 4: "Developer in a Large Organization"
> > 
> > Are those people we believe do not understand the concepts associated
> > with firewalls?
> 
> 
> And the same document says:
> "While our focus is on creating a top-class developer workstation, our
> developer focus will not compromise the aforementioned goal to be a
> polished and user friendly system that appeals to a wide general
> audience."
> 
> Having a target audience in mind doesn't mean we have to make bad
> design for everyone else. In addition their preferences could be
> actually the same. Just look at macOS, it's made easy for our moms and
> dads and very popular with developers at the same time.
> 
> Jiri 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Essentially disabling the firewall falls under having a "bad design for 
everyone else". Disabling the firewall is something that could be considered 
hostile to the user.

I fail to see how the comparison to MacOS applies here. MacOS is not a FLOSS 
project, nor is it some standard. I know GNOME folks seem to think MacOS is 
great and all, to the point that they copy stuff from MacOS and throw it in, 
calling it a "feature", but this is not a feature.

If you want something that's both easy for "our moms and dads", and something 
that keeps them safe, because both are certainly possible at once, you can 
just move back to the default firewall config.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Jiri Eischmann
Adam Williamson píše v Út 27. 08. 2019 v 16:01 -0700:
> On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:
> > mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:
> > > On Tue, Aug 27, 2019 at 4:22 AM, John Harris <
> > > joh...@splentity.com>
> > > wrote:
> > > > No, that is not how this works, at all. First, let's go ahead
> > > > and
> > > > address the 
> > > > idea that "if the firewall blocks it, the app breaks, so it's
> > > > the
> > > > firewall's 
> > > > fault": It's not. If the firewall has not been opened, that
> > > > just
> > > > means it 
> > > > can't be accessed by remote systems until you EXPLICITLY open
> > > > that
> > > > port, with 
> > > > the correct protocol, on your firewall. That's FINE. That's how
> > > > it's designed 
> > > > to work. There's nothing wrong with that.
> > > > 
> > > > This means that the system administrator (or owner, if this is
> > > > some 
> > > > individual's personal system) must allow the port to be
> > > > accessed
> > > > remotely, 
> > > > before the app can be reached remotely, increasing the security
> > > > of
> > > > the system.
> > > 
> > > You've already lost me here. Sorry, but we do not and will not
> > > install a firewall GUI that exposes complex technical details
> > > like
> > > port numbers. Expecting users to edit firewall rules to use their
> > > apps is ridiculous and I'm not really interested in debating it.
> > 
> > Yeah, when you ask users questions they're not qualified to answer,
> > you're just creating bad design.
> > I always imagine my mom (who BTW has been a Fedora user for years)
> > how
> > she'd deal with that and I can't really imagine her opening/closing
> > firewall ports. She'd be puzzled even by "Do you trust this
> > network?"
> > and would probably just click "Yes" to make it go away. No
> > additional
> > security, just annoying UX.
> 
> However, Fedora Workstation is an edition. Which means it has a
> *policy-defined* target audience. That target audience is defined
> here:
> https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> 
> Case 1: "Engineering/CS student"
> Case 2: "Independent Developer"
> Case 3: "Small Company Developer"
> Case 4: "Developer in a Large Organization"
> 
> Are those people we believe do not understand the concepts associated
> with firewalls?

And the same document says:
"While our focus is on creating a top-class developer workstation, our
developer focus will not compromise the aforementioned goal to be a
polished and user friendly system that appeals to a wide general
audience."

Having a target audience in mind doesn't mean we have to make bad
design for everyone else. In addition their preferences could be
actually the same. Just look at macOS, it's made easy for our moms and
dads and very popular with developers at the same time.

Jiri 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Björn Persson
John Harris wrote:
> Consider this. Our default ssh config, under your firewall config, would 
> allow 
> any system on any network your system is connected to to break in.

Only if you have chosen a worthless passphrase. Fedora's default SSHD
configuration – on those spins where SSHD is actually installed and
enabled by default – does in fact require at least an account
passphrase for authentication. If an attacker guesses your passphrase,
then it's your weak passphrase that allows them to break in.

(That said, I'd be in favor of tightening the default SSHD
configuration to allow only public key authentication, as long as it
would still be possible to gain initial access to a freshly installed
headless server.)

> If you're 
> running local, it's open to any system on a network you're on. If you're 
> running postgres, same deal, and so on.

I have no idea what you mean by "running local". As for PostgreSQL, the
truth is that that by default it listens only on the loopback interface
and two Unix domain sockets. It's not accessible from the network at all
until you configure it so. Posting easily verifiable falsehoods doesn't
help your case.

If you explicitly configure PostgreSQL to listen for external
connections, and also configure no authentication, and blindly assume
that there is a packet filter in place to keep you safe, then you won't
get much sympathy from me.

As for the rest, this exchange has grown too ridiculous to waste any
more of my time on.

Björn Persson


pgpuqfb5py_Uq.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread John Harris
On Tuesday, August 27, 2019 10:03:51 PM MST Chris Murphy wrote:
> https://fedoraproject.org/wiki/Workstation/Technical_Specification
> 
> The discussion and decision to not include firewall-config (GUI
> configuration application for firewalld) by default, five years ago
> https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.or
> g/thread/QROJ6LHGT5UUMNTBXEIJTPHPI3IWGFRY/
 
> What's changed since then? It's fine to have purposeful re-evaluation
> of any requirements or specification, but someone or a group need to
> look through the prior history, and clearly articulate why that
> history is obsolete, and produce a compelling case why this should be
> re-evaluated.

That's not necessary. We don't need to address everything that was mentioned 
before, nor do I honestly care. Others may, I most certainly do not. This is 
not something many were aware of before this thread. This sort of thing didn't 
always get the kind of attention it does now.

Current problem: Workstation ships with a useless firewall config
Solution: Get rid of it, replace it with something more sane, like whatever 
the Server spin or KDE spin use, and set the default zone to "public".

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-28 Thread Adam Williamson
On Tue, 2019-08-27 at 17:11 -0700, John Harris wrote:
> Workstation ships with sshd enabled by default, unless something has changed.

It doesn't. This was definitely a conscious decision related to the
firewall policy. See
/usr/lib/systemd/system-preset/80-workstation.preset , where sshd is
explicitly disabled.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
On Tue, Aug 27, 2019 at 10:26 PM Christopher  wrote:
>
> On Tue, Aug 27, 2019 at 9:27 PM Chris Murphy  wrote:
>
> > The Workstation technical specification document says in part:
>
> Where is the full technical specification document, so one can read it
> not in part, but in full?

https://fedoraproject.org/wiki/Workstation/Technical_Specification

The discussion and decision to not include firewall-config (GUI
configuration application for firewalld) by default, five years ago
https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/thread/QROJ6LHGT5UUMNTBXEIJTPHPI3IWGFRY/

What's changed since then? It's fine to have purposeful re-evaluation
of any requirements or specification, but someone or a group need to
look through the prior history, and clearly articulate why that
history is obsolete, and produce a compelling case why this should be
re-evaluated.



> > A firewall in its default configuration may not interfere with the
> > normal operation of programs installed by default.
>
> Using "public" as the zone default instead of "FedoraWorkstation"
> would satisfy this and provide much more reasonable secure defaults.

You've tested all of the default applications with this zone active?

If some significant number of popular/important applications that
aren't installed by default are effectively silently broken upon
installation, I wouldn't be inclined to support enabling an aggressive
firewall policy out of the box. This needs to be assessed, we can't
just set the default zone to public without testing an understanding
how this impacts the user experience.

And also, these arguments should separate between firewall-config
being installed by default, versus what zone to enable by default.
That includes a hypothetical v2 of FedoraWorkstation zone.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Christopher
On Tue, Aug 27, 2019 at 9:27 PM Chris Murphy  wrote:
>
> On Tue, Aug 27, 2019 at 6:23 PM John Harris  wrote:
> >
> > sshd was enabled by default back in F23, unless my install was completely
> > broken. I wouldn't remember that well, unfortunately, as I've been running 
> > KDE
> > since the end of the F24 release cycle.
>
> I don't think so.

Let's please focus on the topic at hand.

> * Fri Mar 13 2015 Dennis Gilmore  - 23-0.4
> - add preset file for workstation to disable sshd
> https://src.fedoraproject.org/rpms/fedora-release/blob/f23/f/fedora-release.spec
>
> The Workstation technical specification document says in part:

Where is the full technical specification document, so one can read it
not in part, but in full?

>
> A firewall in its default configuration may not interfere with the
> normal operation of programs installed by default.

Using "public" as the zone default instead of "FedoraWorkstation"
would satisfy this and provide much more reasonable secure defaults.

> We should detect when the system is on a public or untrusted network
> and prevent the user from unwanted sharing...

"public" would prevent unwanted sharing. Auto-detection is a hard
problem... and I'm not convinced it's possible to solve without
annoying the user interactively on new network connections (and
possibly even reconnecting to previous connections). Either way, that
sounds like the problem of some other component... NetworkManager
perhaps... or something else. Such an auto-detection mechanism doesn't
seem to exist reliably. When it does, the secure assumption should be
to fail safe and assume untrusted unless otherwise specified.

The issue at hand is the default firewalld configuration. Any other
user-interactive experience, or network safety assessment, or
whatever, is a problem to be solved by other components in the future.
For now, firewalld should default to "public" or some similar secure
zone, IMO.

>
> Whereas the KDE spin isn't subject to that spec.
>
> --
> Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Tony Nelson

On 19-08-27 19:58:15, Chris Murphy wrote:
 ...

I definitely do not want to pester developers, or make their day to
day life difficult. If there's no satisfactory GUI right now to manage
it, it's difficult to even experiment with different policies. The
original firewalld proposal considered the graphical tool the main way
of interacting with the firewall, and it was the cli tool that came
later, yet as far as I recall, Workstation never shipped with this GUI
tool.


The package is firewall-config.  On XFCE, App menu -> Administration ->
Firewall.  Perfectly normal graphical firewall configurator.  I've
never used it, because I haven't had to.

--

TonyN.:'   
  '  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
On Tue, Aug 27, 2019 at 6:23 PM John Harris  wrote:
>
> sshd was enabled by default back in F23, unless my install was completely
> broken. I wouldn't remember that well, unfortunately, as I've been running KDE
> since the end of the F24 release cycle.

I don't think so.
* Fri Mar 13 2015 Dennis Gilmore  - 23-0.4
- add preset file for workstation to disable sshd
https://src.fedoraproject.org/rpms/fedora-release/blob/f23/f/fedora-release.spec

The Workstation technical specification document says in part:

A firewall in its default configuration may not interfere with the
normal operation of programs installed by default.
We should detect when the system is on a public or untrusted network
and prevent the user from unwanted sharing...

Whereas the KDE spin isn't subject to that spec.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 5:15:52 PM MST Chris Murphy wrote:
> > > That actually isn't clear at all. And I am the end user and sysadmin.
> > > I'm at home, I have my own AP, but none of the equipment is under my
> > > direct control, it's centrally managed by a company I don't even pay.
> > > So, is it trustworthy? Maybe. Maybe not. I have no practical way of
> > > knowing without digging into Fedora Security spin and learning a bunch
> > > of things I don't presently know - which for sure sounds really
> > > fascinating, and I like that this spin exists, but there are only so
> > > many hours in the day!
> >
> >
> >
> > Workstation ships with sshd enabled by default, unless something has
> > changed.
> 
> It isn't enabled by default, and it hasn't changed since Workstation
> edition has existed. What is true is once you enabled it, it doesn't
> get disabled when you do a major version upgrade.
> 
> 
> -- 
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

sshd was enabled by default back in F23, unless my install was completely 
broken. I wouldn't remember that well, unfortunately, as I've been running KDE 
since the end of the F24 release cycle.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 4:58:15 PM MST Chris Murphy wrote:
> On Tue, Aug 27, 2019 at 5:02 PM Adam Williamson
>  wrote:
> 
> >
> >
> > However, Fedora Workstation is an edition. Which means it has a
> > *policy-defined* target audience. That target audience is defined here:
> > https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> > 
> >
> >
> >
> > Case 1: "Engineering/CS student"
> > Case 2: "Independent Developer"
> > Case 3: "Small Company Developer"
> > Case 4: "Developer in a Large Organization"
> >
> >
> >
> > Are those people we believe do not understand the concepts associated
> > with firewalls?
> 
> 
> This is exactly what I was alluding to upthread with "developers are a
> large target audience, in particular for Workstation"
> 
> They're clearly safer with FedoraWorkstation zone (default) enabled
> than with the firewall disabled. I can't estimate how much safer.
> 
> I definitely do not want to pester developers, or make their day to
> day life difficult. If there's no satisfactory GUI right now to manage
> it, it's difficult to even experiment with different policies. The
> original firewalld proposal considered the graphical tool the main way
> of interacting with the firewall, and it was the cli tool that came
> later, yet as far as I recall, Workstation never shipped with this GUI
> tool.
> 
> 
> -- 
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

The default zone essentially disables the firewall, without disabling it. It 
doesn't provide any real security.

I don't want to pester devs either, which is something fixing this would have 
little effect on. https://xkcd.com/1172/

There IS a satisfactory GUI to manage the firewall. If I recall correctly, 
it's literally called "firewall-gui".

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
> > That actually isn't clear at all. And I am the end user and sysadmin.
> > I'm at home, I have my own AP, but none of the equipment is under my
> > direct control, it's centrally managed by a company I don't even pay.
> > So, is it trustworthy? Maybe. Maybe not. I have no practical way of
> > knowing without digging into Fedora Security spin and learning a bunch
> > of things I don't presently know - which for sure sounds really
> > fascinating, and I like that this spin exists, but there are only so
> > many hours in the day!
>
> Workstation ships with sshd enabled by default, unless something has changed.

It isn't enabled by default, and it hasn't changed since Workstation
edition has existed. What is true is once you enabled it, it doesn't
get disabled when you do a major version upgrade.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 4:49:03 PM MST Japheth Cleaver wrote:
> On 8/27/2019 4:01 PM, Adam Williamson wrote:
> 
> > On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:
> > 
> >> mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:
> >> 
> >>> On Tue, Aug 27, 2019 at 4:22 AM, John Harris 
> >>> wrote:
> >>> 
>  No, that is not how this works, at all. First, let's go ahead and
>  address the
>  idea that "if the firewall blocks it, the app breaks, so it's the
>  firewall's
>  fault": It's not. If the firewall has not been opened, that just
>  means it
>  can't be accessed by remote systems until you EXPLICITLY open that
>  port, with
>  the correct protocol, on your firewall. That's FINE. That's how
>  it's designed
>  to work. There's nothing wrong with that.
> 
> 
> 
>  This means that the system administrator (or owner, if this is
>  some
>  individual's personal system) must allow the port to be accessed
>  remotely,
>  before the app can be reached remotely, increasing the security of
>  the system.
> >>> 
> >>> You've already lost me here. Sorry, but we do not and will not
> >>> install a firewall GUI that exposes complex technical details like
> >>> port numbers. Expecting users to edit firewall rules to use their
> >>> apps is ridiculous and I'm not really interested in debating it.
> >> 
> >> Yeah, when you ask users questions they're not qualified to answer,
> >> you're just creating bad design.
> >> I always imagine my mom (who BTW has been a Fedora user for years) how
> >> she'd deal with that and I can't really imagine her opening/closing
> >> firewall ports. She'd be puzzled even by "Do you trust this network?"
> >> and would probably just click "Yes" to make it go away. No additional
> >> security, just annoying UX.
> > 
> > However, Fedora Workstation is an edition. Which means it has a
> > *policy-defined* target audience. That target audience is defined here:
> > https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> > 
> >
> >
> >
> > Case 1: "Engineering/CS student"
> > Case 2: "Independent Developer"
> > Case 3: "Small Company Developer"
> > Case 4: "Developer in a Large Organization"
> >
> >
> >
> > Are those people we believe do not understand the concepts associated
> > with firewalls?
> 
> 
> The term "Workstation" itself has a long pedigree and is laden with a 
> variety of connotations. The failure here may be that that term has been 
> conflated with "Desktop". Your mother surfing Facebook may benefit from 
> a "Linux Desktop" (maybe.), but she's probably not the target for a 
> "Linux Workstation" unless https://xkcd.com/327/ is likely to happen.
> 
> "Fedora as a Distro" could do a better job of articulating this 
> distinction. Perhaps a user vs. poweruser split is viable at 
> install/config time, or perhaps Desktop and Workstation would warrant 
> separate Editions.
> 
> "Fedora as a Project", OTOH, seems to be reaching a point where so many 
> downstream users have varying needs (and I'm including Editions, Atomic, 
> Container folks, EPEL as a side project, and RHEL/CentOS/SL here) that a 
> fundamental project re-architecture is getting to be warranted.
> 
> -jc
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

"Workstation" literally means a station to work at. Any computer you can do 
work on is a workstation. My workstation is an X200 Tablet running Fedora KDE 
Spin, for example.

If there is to be a Desktop edition, I vote KDE is the default DE of it.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 5:05:57 PM MST Chris Murphy wrote:
> On Tue, Aug 27, 2019 at 5:24 PM John Harris  wrote:
> 
> >
> >
> > On Tuesday, August 27, 2019 8:23:01 AM MST Chris Murphy wrote:
> 
> 
> 
> > > Windows is enable by default with two "zones" or "policies" (I can't
> > > even tell from their own UI what to call this), one for private
> > > networks, and another for guest/public networks.
> >
> >
> >
> > I don't have a mac, so I can't confirm this, but Apple suggests that
> > there's
 nothing bound to listen by default.
> 
> 
> There are no services enabled by default either. No ssh, no file
> sharing, no VNC, no printer sharing, etc.  macOS does have Bonjour
> (mDNS) enabled by default, and while it's not self announcing, it is
> listening for other device/services that are.
> 
> That's similar to Workstation.
> 
> 
> > If that's the case, and I imagine it's
> > difficult to run real software on Mac which might bind stuff (because of
> > those
 "app" things they've got, I presume), that might be a legitimate
> > thing for Macs. We're not Apple, and we're not rolling out MacOS. I
> > personally believe that's a horrible idea for Mac systems as well, even
> > if they don't bind anything by default, which we do.
> 
> 
> Difficult to run real software ... I don't understand what that means
> or how it manifests. I run all kinds of real software on macOS and it
> works fine.
> 
> 
> > This sounds like a misunderstanding as to what firewalls, and the various
> > types of firewalls, are. By default, Fedora uses firewalld, which is not
> > an application firewall, which is what you've described. "I dunno if
> > this network is trustworthy! Do you know if it's trustworthy?!" is a
> > legitimate decision for the end user or sysadmin to make. It is not "a
> > buck passing interface", the Fedora install has no possible way to know.
> > The end user or sysadmin would.
> 
> 
> That actually isn't clear at all. And I am the end user and sysadmin.
> I'm at home, I have my own AP, but none of the equipment is under my
> direct control, it's centrally managed by a company I don't even pay.
> So, is it trustworthy? Maybe. Maybe not. I have no practical way of
> knowing without digging into Fedora Security spin and learning a bunch
> of things I don't presently know - which for sure sounds really
> fascinating, and I like that this spin exists, but there are only so
> many hours in the day!

Workstation ships with sshd enabled by default, unless something has changed. 
Regardless, on Workstation, user programs can certainly easily bind ports, 
which, with the GNOME spin's firewall configuration, are open to the world at 
this point.

What does the Fedora Security lab have to do with anything? Are you interested 
in pentesting?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
On Tue, Aug 27, 2019 at 5:30 PM John Harris  wrote:
>
> On Tuesday, August 27, 2019 8:23:01 AM MST Chris Murphy wrote:
> > The firewall on macOS is disabled by default. Therefore I can't agree
> > with any assessment that Fedora Workstation is, on this point alone,
> > in some sort of vulnerable state outside that of macOS.
>
> Talked to a coworker, who is a heavy MacOS user. She explained that, while the
> firewall is disabled by default, inbound ports are still closed until you
> explicitly open them. That sounds a lot more sane than not running a firewall
> at all.

I don't ever explicitly open them. I check a box called "Remote Login"
and that launches sshd, and I can certainly connect to that box. I
suppose I have implicitly opened the port by checking the box to
enable sshd.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
On Tue, Aug 27, 2019 at 5:24 PM John Harris  wrote:
>
> On Tuesday, August 27, 2019 8:23:01 AM MST Chris Murphy wrote:

> > Windows is enable by default with two "zones" or "policies" (I can't
> > even tell from their own UI what to call this), one for private
> > networks, and another for guest/public networks.
>
> I don't have a mac, so I can't confirm this, but Apple suggests that there's
> nothing bound to listen by default.

There are no services enabled by default either. No ssh, no file
sharing, no VNC, no printer sharing, etc.  macOS does have Bonjour
(mDNS) enabled by default, and while it's not self announcing, it is
listening for other device/services that are.

That's similar to Workstation.

> If that's the case, and I imagine it's
> difficult to run real software on Mac which might bind stuff (because of those
> "app" things they've got, I presume), that might be a legitimate thing for
> Macs. We're not Apple, and we're not rolling out MacOS. I personally believe
> that's a horrible idea for Mac systems as well, even if they don't bind
> anything by default, which we do.

Difficult to run real software ... I don't understand what that means
or how it manifests. I run all kinds of real software on macOS and it
works fine.

> This sounds like a misunderstanding as to what firewalls, and the various
> types of firewalls, are. By default, Fedora uses firewalld, which is not an
> application firewall, which is what you've described. "I dunno if this network
> is trustworthy! Do you know if it's trustworthy?!" is a legitimate decision
> for the end user or sysadmin to make. It is not "a buck passing interface",
> the Fedora install has no possible way to know. The end user or sysadmin
> would.

That actually isn't clear at all. And I am the end user and sysadmin.
I'm at home, I have my own AP, but none of the equipment is under my
direct control, it's centrally managed by a company I don't even pay.
So, is it trustworthy? Maybe. Maybe not. I have no practical way of
knowing without digging into Fedora Security spin and learning a bunch
of things I don't presently know - which for sure sounds really
fascinating, and I like that this spin exists, but there are only so
many hours in the day!

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
On Tue, Aug 27, 2019 at 5:02 PM Adam Williamson
 wrote:
>
> However, Fedora Workstation is an edition. Which means it has a
> *policy-defined* target audience. That target audience is defined here:
> https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
>
> Case 1: "Engineering/CS student"
> Case 2: "Independent Developer"
> Case 3: "Small Company Developer"
> Case 4: "Developer in a Large Organization"
>
> Are those people we believe do not understand the concepts associated
> with firewalls?

This is exactly what I was alluding to upthread with "developers are a
large target audience, in particular for Workstation"

They're clearly safer with FedoraWorkstation zone (default) enabled
than with the firewall disabled. I can't estimate how much safer.

I definitely do not want to pester developers, or make their day to
day life difficult. If there's no satisfactory GUI right now to manage
it, it's difficult to even experiment with different policies. The
original firewalld proposal considered the graphical tool the main way
of interacting with the firewall, and it was the cli tool that came
later, yet as far as I recall, Workstation never shipped with this GUI
tool.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Japheth Cleaver

On 8/27/2019 4:01 PM, Adam Williamson wrote:

On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:

mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:

On Tue, Aug 27, 2019 at 4:22 AM, John Harris 
wrote:

No, that is not how this works, at all. First, let's go ahead and
address the
idea that "if the firewall blocks it, the app breaks, so it's the
firewall's
fault": It's not. If the firewall has not been opened, that just
means it
can't be accessed by remote systems until you EXPLICITLY open that
port, with
the correct protocol, on your firewall. That's FINE. That's how
it's designed
to work. There's nothing wrong with that.

This means that the system administrator (or owner, if this is
some
individual's personal system) must allow the port to be accessed
remotely,
before the app can be reached remotely, increasing the security of
the system.

You've already lost me here. Sorry, but we do not and will not
install a firewall GUI that exposes complex technical details like
port numbers. Expecting users to edit firewall rules to use their
apps is ridiculous and I'm not really interested in debating it.

Yeah, when you ask users questions they're not qualified to answer,
you're just creating bad design.
I always imagine my mom (who BTW has been a Fedora user for years) how
she'd deal with that and I can't really imagine her opening/closing
firewall ports. She'd be puzzled even by "Do you trust this network?"
and would probably just click "Yes" to make it go away. No additional
security, just annoying UX.

However, Fedora Workstation is an edition. Which means it has a
*policy-defined* target audience. That target audience is defined here:
https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience

Case 1: "Engineering/CS student"
Case 2: "Independent Developer"
Case 3: "Small Company Developer"
Case 4: "Developer in a Large Organization"

Are those people we believe do not understand the concepts associated
with firewalls?


The term "Workstation" itself has a long pedigree and is laden with a 
variety of connotations. The failure here may be that that term has been 
conflated with "Desktop". Your mother surfing Facebook may benefit from 
a "Linux Desktop" (maybe.), but she's probably not the target for a 
"Linux Workstation" unless https://xkcd.com/327/ is likely to happen.


"Fedora as a Distro" could do a better job of articulating this 
distinction. Perhaps a user vs. poweruser split is viable at 
install/config time, or perhaps Desktop and Workstation would warrant 
separate Editions.


"Fedora as a Project", OTOH, seems to be reaching a point where so many 
downstream users have varying needs (and I'm including Editions, Atomic, 
Container folks, EPEL as a side project, and RHEL/CentOS/SL here) that a 
fundamental project re-architecture is getting to be warranted.


-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Luya Tshimbalanga
MacOS has firewall disabled by default on every iteration.

Luya

On 2019-08-27 4:23 p.m., John Harris wrote:
> On Tuesday, August 27, 2019 8:23:01 AM MST Chris Murphy wrote: >> On Tue, Aug 
> 27, 2019 at 6:22 AM Neal Gompa 
wrote: >> >>> >>> >>> The other major non-Linux operating systems do.
Both Microsoft Windows >>> and Apple macOS ship with active firewalls by
default. >> >> >> The firewall on macOS is disabled by default.
Therefore I can't agree >> with any assessment that Fedora Workstation
is, on this point alone, >> in some sort of vulnerable state outside
that of macOS. >> >> Windows is enable by default with two "zones" or
"policies" (I can't >> even tell from their own UI what to call this),
one for private >> networks, and another for guest/public networks. > >
I don't have a mac, so I can't confirm this, but Apple suggests that
there's > nothing bound to listen by default. If that's the case, and I
imagine it's > difficult to run real software on Mac which might bind
stuff (because of those > "app" things they've got, I presume), that
might be a legitimate thing for > Macs. We're not Apple, and we're not
rolling out MacOS. I personally believe > that's a horrible idea for Mac
systems as well, even if they don't bind > anything by default, which we
do. > > By default, Windows 10 enterprise has the following firewall
zones: > Public > Private > Home > Work > Domain > >>> Those are the >>>
>>> real competitors, and they have a good UX for firewall handling so
>>> that users can Do The Right Thing(TM). >> >> >> For Windows and
macOS, when firewall is enabled, an application that >> tries to open a
port against the firewall's policy, causes a dialog to >> appear. The
user needs to read that, and make a decision. A valid >> subjective case
can be made that this is janky, as if the UI itself is >> saying: "I
dunno if this network is trustworthy! Do you know if it's >>
trustworthy?!" Without any further way of informing the user how to >>
determine this. They are both a buck passing interface. And that's >>
fine for some users, but definitely not fine for others. > > This sounds
like a misunderstanding as to what firewalls, and the various > types of
firewalls, are. By default, Fedora uses firewalld, which is not an >
application firewall, which is what you've described. "I dunno if this
network > is trustworthy! Do you know if it's trustworthy?!" is a
legitimate decision > for the end user or sysadmin to make. It is not "a
buck passing interface", > the Fedora install has no possible way to
know. The end user or sysadmin > would. >

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 8:23:01 AM MST Chris Murphy wrote:
> The firewall on macOS is disabled by default. Therefore I can't agree
> with any assessment that Fedora Workstation is, on this point alone,
> in some sort of vulnerable state outside that of macOS.

Talked to a coworker, who is a heavy MacOS user. She explained that, while the 
firewall is disabled by default, inbound ports are still closed until you 
explicitly open them. That sounds a lot more sane than not running a firewall 
at all.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 8:23:01 AM MST Chris Murphy wrote:
> On Tue, Aug 27, 2019 at 6:22 AM Neal Gompa  wrote:
> 
> >
> >
> > The other major non-Linux operating systems do. Both Microsoft Windows
> > and Apple macOS ship with active firewalls by default.
> 
> 
> The firewall on macOS is disabled by default. Therefore I can't agree
> with any assessment that Fedora Workstation is, on this point alone,
> in some sort of vulnerable state outside that of macOS.
> 
> Windows is enable by default with two "zones" or "policies" (I can't
> even tell from their own UI what to call this), one for private
> networks, and another for guest/public networks.

I don't have a mac, so I can't confirm this, but Apple suggests that there's 
nothing bound to listen by default. If that's the case, and I imagine it's 
difficult to run real software on Mac which might bind stuff (because of those 
"app" things they've got, I presume), that might be a legitimate thing for 
Macs. We're not Apple, and we're not rolling out MacOS. I personally believe 
that's a horrible idea for Mac systems as well, even if they don't bind 
anything by default, which we do.

By default, Windows 10 enterprise has the following firewall zones:
Public
Private
Home
Work
Domain

> >Those are the
> >
> > real competitors, and they have a good UX for firewall handling so
> > that users can Do The Right Thing(TM).
> 
> 
> For Windows and macOS, when firewall is enabled, an application that
> tries to open a port against the firewall's policy, causes a dialog to
> appear. The user needs to read that, and make a decision. A valid
> subjective case can be made that this is janky, as if the UI itself is
> saying: "I dunno if this network is trustworthy! Do you know if it's
> trustworthy?!" Without any further way of informing the user how to
> determine this. They are both a buck passing interface. And that's
> fine for some users, but definitely not fine for others.

This sounds like a misunderstanding as to what firewalls, and the various 
types of firewalls, are. By default, Fedora uses firewalld, which is not an 
application firewall, which is what you've described. "I dunno if this network 
is trustworthy! Do you know if it's trustworthy?!" is a legitimate decision 
for the end user or sysadmin to make. It is not "a buck passing interface", 
the Fedora install has no possible way to know. The end user or sysadmin 
would.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 8:04:46 AM MST Louis Lagendijk wrote:
> On Tue, 2019-08-27 at 10:14 -0400, Robert Marcano wrote:
> 
> > On 8/27/19 10:03 AM, John Harris wrote:
> > 
> > > 
> > 
> > Any new Wifi connection could be identified by their SSID, so it
> > could 
> > still be secure by default and ask for that specific connection to
> > be 
> > opened because you trust them. As I proposed on another email, bring 
> > back the NetworkManager zones UI to GNOME Settings, simplified with 
> > being an option to confine that connection to the public zone.
> > 
> 
> Yeah, the WIFI case can be as simple as that: let the use choose the
> default zone. Public means closed firewall,  otherwise the workstation
> zone can be as it is now. This protects the user from big mistakes as
> unintended sharing of information over samba, media players et. 
> 
> > The problem of identifying wired connections still remains and needs 
> > more thinking.
> 
> For this case NetworkManager could verify the gateway address/ MAC to
> see if this is a known network, and if not offer the user to allocate
> that connection to a public/private zone? I seem to remember that
> Windows does something similar (sorry not a big Windows user)...
> /louis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I'd argue that the workstation zone shouldn't exist at all, at least not as it 
is now, but even that would be a significant improvement.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 9:59:23 AM MST David Kaufmann wrote:
> I'm not trying to recommend it, this is already done, e.g. for mdns,
> samba-client, or ssh. (To be fair that happens on os install, not
> necessarily on package install)
> I'm trying to list the problems with those options.

There is a significant difference between opening up ports, on the fly, as 
users install packages, and setting defaults.

> Very true. Unfortunately it is usually done to shield services which
> should not be there in the first place.
> Also stuff like rate-limiting or ip-header-checks are usually done by
> firewalls, hence my emphasis on making sure users don't start to disable
> the whole firewall because it is "easier".

Well, some of the IP header checks are done in the kernel, before they get to 
the firewall module(s) firewalld uses under the hood (I assume netfilter and 
kin), but yes, I agree with the sentiment.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 10:09:12 AM MST Stephen John Smoogen wrote:
> On Tue, 27 Aug 2019 at 13:01, Vitaly Zaitsev via devel
>  wrote:
> 
> >
> >
> > On 27.08.2019 18:14, Björn Persson wrote:
> > 
> > > If it could come from anywhere, then we must assume that it's
> > > malicious.
> > > You executed untrusted code. It's already past your firewall. Game
> > > over,
> > > you're infected. You're closing the stable door after the horse has
> > > bolted.
> >
> >
> >
> > Any application can run backdoor or proxy on your machine with disabled
> > firewall. Everyone from the Internet can connect it.
> >
> >
> >
> > If the firewall is enabled and all ports are closed, hacker cannot
> > access your system. They will need to bypass firewall first and this is
> > much more difficult.
> >
> >
> 
> 
> You are both talking past each other and not seeming to get anywhere.
> 
> Bjorn is talking about where the backapp is not opening up a localport
> but tunnelling out via a vpn to a command and control device. The only
> way to stop that is where your firewall also drops outbound
> connections. Since most firewalls do not do that, the attack vector
> they are discussing will bypass a firewall.
> 
> Vitaly is talking about the other attack where the backdoor app opens
> a local listening port which can then be access from the outside. This
> used to be the standard security hole because setting up a CC and
> doing reverse networking was hard for most hackers.
> 
> The problem is that most toolkits come with the VPN solution these
> days so a hacking group don't have to be rock-stars in
> programming/networking to set it up. N number of satoshi on some
> darkweb will get you a javascript tool which can be injected on a
> webpage and do all the work for the hacker. So Bjorn is trying to
> point out that the problem you need to worry about is not solved by
> the shipped firewall. Instead some level of application firewall would
> be needed to even 'try' to stop this.
> 
> 
> 
> > --
> > Sincerely,
> > 
> >   Vitaly Zaitsev (vit...@easycoding.org)
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
 List
> > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> > Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o
> > rg
> 
> 
> 
> -- 
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

The difference between the two is just in how it applies to this topic. The 
firewall, in this context, mostly applies to remote access to our locally 
bound ports.

There is also a significant difference between these two issues

With one, the end user is going out, and accidentally running something, or 
running vulnerable code. Their system is then affected in ways unknown, and we 
do our best effort.

In the other, with a proper firewall config, you'd have to wait for the user 
to go out from there, if they do. With the GNOME spin's default, that's not 
the case, you're already a sitting duck, and the users aren't warned of this 
anywhere.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
I'm not sure why this isn't clear, but the examples that I provided are far 
from the only aspects, and I notice you're only addressing the ones that 
require the user to manually run something.

Consider this. Our default ssh config, under your firewall config, would allow 
any system on any network your system is connected to to break in. If you're 
running local, it's open to any system on a network you're on. If you're 
running postgres, same deal, and so on.

Regardless, I suppose I'll still address your points:

On Tuesday, August 27, 2019 9:14:10 AM MST Björn Persson wrote:
> John Harris wrote:
> >On Tuesday, August 27, 2019 5:36:20 AM MST Björn Persson wrote:
> >> Please elaborate. Where does the script come from, what exactly happens
> >> by accident, and how would a packet filter stop it?
> >
> >It could come from anywhere, that's not the point. A *firewall* would stop
> >it from doing anything too harmful: Opening up the system to the world by
> >binding a port, or listening on a UDP port.
> 
> If it could come from anywhere, then we must assume that it's malicious.
> You executed untrusted code. It's already past your firewall. Game over,
> you're infected. You're closing the stable door after the horse has
> bolted.

The idea that once one part of the system is affected, every security aspect 
should be disregarded is absolutely absurd. That would be like the example I 
sent to this list before, getting robbed, and leaving your doors unlocked as a 
solution.

Different parts of the system deal with security in different ways.

> >It'd still be bound, or would still be listening on a port, but it wouldn't
> >be accessible unless somebody went and manually opened a port on the
> >firewall.
> And what if the malicious script doesn't just listen, but actively
> phones home?

If that's the case, then it's SELinux's issue.

> Let's just say I'm talking about granting permission with Polkit like
> you mention below, whichever way you envision that.

If the user chooses to allow it, that's one thing. We can still supply a 
secure default. The user is always free to run their system however they want.

> >Additionally, I'm referring to incidents like that common in node.js, where
> >a package gets modified to something malicious, and then runs a backdoor
> >which is accessible over a given port.
> 
> Again, it's already past your firewall. You're already infected. What
> if the malicious Javascript doesn't just run a backdoor, but actively
> phones home?

If that were the case, it'd be the job of SELinux, if anything. It's usually 
not, which may surprise you. Regardless, the fact that you envision a 
different attack vector, which we already deal with to the best of our 
ability, doesn't mean that we should not address another attack vector, which 
is actually the topic at hand.

> >> How would a "vulnerability" "bind a port"? If the program is supposed
> >> to communicate, then it will be allowed, and any vulnerabilities it has
> >> are then exposed to the network. If it's not supposed to communicate,
> >> then it won't randomly sprout a network service because of a bug.
> >
> >For example, RCEs, specific or otherwise. This has happened in `firefox`
> >before.
> 
> OK so you meant the case below:
> >> If you mean that an arbitrary code execution vulnerability has been
> >> exploited, so that the program is now executing the attacker's code,
> >> then it's already too late. The attack code won't listen for incoming
> >> connections. It will make an outgoing connection to its master. And in
> >> case you're considering requiring permission even for outgoing
> >> connections – which would be unbearable to the user – the attack code
> >> would just make an API call (through Dbus or whatever) to grant itself
> >> permission to communicate.
> >
> >Just because a potential attacker may have already compromised part of a
> >system doesn't mean that you just open up the firewall to anything they've
> >got listening.
> 
> And for the fourth time: It's not listening, it's actively phoning home.

And for the nth time: That's generally not the case, and if it were, it'd be 
an issue for a different part of the security subsystems installed on a given 
Fedora system, most likely SELinux. Let's address what we can actually address 
with reference to the firewall, rather than attempting to deflect 
responsibility. If you really want to get into it, our default firewall could 
be tuned to only allow certain outgoing traffic as well, but I would be 
against such a move.

> >Additionally, such a thing trying to open a port would likely
> >require Polkit to grant you permission to do so first, which would, by
> >default, require the user to authenticate and have the appropriate
> >permissions.
> 
> Do you expect users to type their passphrase every single time they
> want to play some peer-to-peer game, or make an Internet phone call, or
> download something with Bittorrent, et cetera?

I fail to see what that has to 

Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Adam Williamson
On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:
> mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:
> > On Tue, Aug 27, 2019 at 4:22 AM, John Harris 
> > wrote:
> > > No, that is not how this works, at all. First, let's go ahead and
> > > address the 
> > > idea that "if the firewall blocks it, the app breaks, so it's the
> > > firewall's 
> > > fault": It's not. If the firewall has not been opened, that just
> > > means it 
> > > can't be accessed by remote systems until you EXPLICITLY open that
> > > port, with 
> > > the correct protocol, on your firewall. That's FINE. That's how
> > > it's designed 
> > > to work. There's nothing wrong with that.
> > > 
> > > This means that the system administrator (or owner, if this is
> > > some 
> > > individual's personal system) must allow the port to be accessed
> > > remotely, 
> > > before the app can be reached remotely, increasing the security of
> > > the system.
> > 
> > You've already lost me here. Sorry, but we do not and will not
> > install a firewall GUI that exposes complex technical details like
> > port numbers. Expecting users to edit firewall rules to use their
> > apps is ridiculous and I'm not really interested in debating it.
> 
> Yeah, when you ask users questions they're not qualified to answer,
> you're just creating bad design.
> I always imagine my mom (who BTW has been a Fedora user for years) how
> she'd deal with that and I can't really imagine her opening/closing
> firewall ports. She'd be puzzled even by "Do you trust this network?"
> and would probably just click "Yes" to make it go away. No additional
> security, just annoying UX.

However, Fedora Workstation is an edition. Which means it has a
*policy-defined* target audience. That target audience is defined here:
https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience

Case 1: "Engineering/CS student"
Case 2: "Independent Developer"
Case 3: "Small Company Developer"
Case 4: "Developer in a Large Organization"

Are those people we believe do not understand the concepts associated
with firewalls?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
On Tue, Aug 27, 2019 at 4:54 PM John Harris  wrote:
>
> On Tuesday, August 27, 2019 9:14:10 AM MST Björn Persson wrote:
> > John Harris wrote:
> > >On Tuesday, August 27, 2019 5:36:20 AM MST Björn Persson wrote:
> > >> Please elaborate. Where does the script come from, what exactly happens
> > >> by accident, and how would a packet filter stop it?
> > >
> > >It could come from anywhere, that's not the point. A *firewall* would stop
> > >it from doing anything too harmful: Opening up the system to the world by
> > >binding a port, or listening on a UDP port.
> >
> > If it could come from anywhere, then we must assume that it's malicious.
> > You executed untrusted code. It's already past your firewall. Game over,
> > you're infected. You're closing the stable door after the horse has
> > bolted.
> >
> > >It'd still be bound, or would still be listening on a port, but it wouldn't
> > >be accessible unless somebody went and manually opened a port on the
> > >firewall.
> > And what if the malicious script doesn't just listen, but actively
> > phones home?
> >
> > >> A badly written script accidentally starts some network service that it
> > >> doesn't need? The one time that actually happens, the user will likely
> > >> click "allow" without thinking, as they will have been accustomed to
> > >> doing so all the time.
> > >>
> > >>
> > >> If the script actually needs to listen on the network, then the user
> > >> will have to allow it, and the script is no less badly written than it
> > >> was before.
> > >
> > >There is no "allow" button. I don't know what you're talking about.
> >
> > Let's just say I'm talking about granting permission with Polkit like
> > you mention below, whichever way you envision that.
> >
> > >Additionally, I'm referring to incidents like that common in node.js, where
> > >a package gets modified to something malicious, and then runs a backdoor
> > >which is accessible over a given port.
> >
> > Again, it's already past your firewall. You're already infected. What
> > if the malicious Javascript doesn't just run a backdoor, but actively
> > phones home?
> >
> > >> How would a "vulnerability" "bind a port"? If the program is supposed
> > >> to communicate, then it will be allowed, and any vulnerabilities it has
> > >> are then exposed to the network. If it's not supposed to communicate,
> > >> then it won't randomly sprout a network service because of a bug.
> > >
> > >For example, RCEs, specific or otherwise. This has happened in `firefox`
> > >before.
> >
> > OK so you meant the case below:
> > >> If you mean that an arbitrary code execution vulnerability has been
> > >> exploited, so that the program is now executing the attacker's code,
> > >> then it's already too late. The attack code won't listen for incoming
> > >> connections. It will make an outgoing connection to its master. And in
> > >> case you're considering requiring permission even for outgoing
> > >> connections – which would be unbearable to the user – the attack code
> > >> would just make an API call (through Dbus or whatever) to grant itself
> > >> permission to communicate.
> > >
> > >Just because a potential attacker may have already compromised part of a
> > >system doesn't mean that you just open up the firewall to anything they've
> > >got listening.
> >
> > And for the fourth time: It's not listening, it's actively phoning home.
> >
> > >Additionally, such a thing trying to open a port would likely
> > >require Polkit to grant you permission to do so first, which would, by
> > >default, require the user to authenticate and have the appropriate
> > >permissions.
> >
> > Do you expect users to type their passphrase every single time they
> > want to play some peer-to-peer game, or make an Internet phone call, or
> > download something with Bittorrent, et cetera?
> >
> > Or would the permissions be stored permanently somewhere? In that case,
> > how would you prevent a malicious program from impersonating one of the
> > permissioned programs?
> >
> > Björn Persson
>
> This isn't "secure" or "not secure". If your home got robbed while you were
> out, would your solution be to leave your doors unlocked from then on?
>
> That's what this is suggesting.

No, it's a non sequitur, and also it's not a good metaphor anyway.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 9:14:10 AM MST Björn Persson wrote:
> John Harris wrote:
> >On Tuesday, August 27, 2019 5:36:20 AM MST Björn Persson wrote:
> >> Please elaborate. Where does the script come from, what exactly happens
> >> by accident, and how would a packet filter stop it?
> >
> >It could come from anywhere, that's not the point. A *firewall* would stop
> >it from doing anything too harmful: Opening up the system to the world by
> >binding a port, or listening on a UDP port.
> 
> If it could come from anywhere, then we must assume that it's malicious.
> You executed untrusted code. It's already past your firewall. Game over,
> you're infected. You're closing the stable door after the horse has
> bolted.
> 
> >It'd still be bound, or would still be listening on a port, but it wouldn't
> >be accessible unless somebody went and manually opened a port on the
> >firewall.
> And what if the malicious script doesn't just listen, but actively
> phones home?
> 
> >> A badly written script accidentally starts some network service that it
> >> doesn't need? The one time that actually happens, the user will likely
> >> click "allow" without thinking, as they will have been accustomed to
> >> doing so all the time.
> >> 
> >> 
> >> If the script actually needs to listen on the network, then the user
> >> will have to allow it, and the script is no less badly written than it
> >> was before.
> >
> >There is no "allow" button. I don't know what you're talking about.
> 
> Let's just say I'm talking about granting permission with Polkit like
> you mention below, whichever way you envision that.
> 
> >Additionally, I'm referring to incidents like that common in node.js, where
> >a package gets modified to something malicious, and then runs a backdoor
> >which is accessible over a given port.
> 
> Again, it's already past your firewall. You're already infected. What
> if the malicious Javascript doesn't just run a backdoor, but actively
> phones home?
> 
> >> How would a "vulnerability" "bind a port"? If the program is supposed
> >> to communicate, then it will be allowed, and any vulnerabilities it has
> >> are then exposed to the network. If it's not supposed to communicate,
> >> then it won't randomly sprout a network service because of a bug.
> >
> >For example, RCEs, specific or otherwise. This has happened in `firefox`
> >before.
> 
> OK so you meant the case below:
> >> If you mean that an arbitrary code execution vulnerability has been
> >> exploited, so that the program is now executing the attacker's code,
> >> then it's already too late. The attack code won't listen for incoming
> >> connections. It will make an outgoing connection to its master. And in
> >> case you're considering requiring permission even for outgoing
> >> connections – which would be unbearable to the user – the attack code
> >> would just make an API call (through Dbus or whatever) to grant itself
> >> permission to communicate.
> >
> >Just because a potential attacker may have already compromised part of a
> >system doesn't mean that you just open up the firewall to anything they've
> >got listening.
> 
> And for the fourth time: It's not listening, it's actively phoning home.
> 
> >Additionally, such a thing trying to open a port would likely
> >require Polkit to grant you permission to do so first, which would, by
> >default, require the user to authenticate and have the appropriate
> >permissions.
> 
> Do you expect users to type their passphrase every single time they
> want to play some peer-to-peer game, or make an Internet phone call, or
> download something with Bittorrent, et cetera?
> 
> Or would the permissions be stored permanently somewhere? In that case,
> how would you prevent a malicious program from impersonating one of the
> permissioned programs?
> 
> Björn Persson

This isn't "secure" or "not secure". If your home got robbed while you were 
out, would your solution be to leave your doors unlocked from then on?

That's what this is suggesting.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Stephen John Smoogen
On Tue, 27 Aug 2019 at 13:01, Vitaly Zaitsev via devel
 wrote:
>
> On 27.08.2019 18:14, Björn Persson wrote:
> > If it could come from anywhere, then we must assume that it's malicious.
> > You executed untrusted code. It's already past your firewall. Game over,
> > you're infected. You're closing the stable door after the horse has
> > bolted.
>
> Any application can run backdoor or proxy on your machine with disabled
> firewall. Everyone from the Internet can connect it.
>
> If the firewall is enabled and all ports are closed, hacker cannot
> access your system. They will need to bypass firewall first and this is
> much more difficult.
>

You are both talking past each other and not seeming to get anywhere.

Bjorn is talking about where the backapp is not opening up a localport
but tunnelling out via a vpn to a command and control device. The only
way to stop that is where your firewall also drops outbound
connections. Since most firewalls do not do that, the attack vector
they are discussing will bypass a firewall.

Vitaly is talking about the other attack where the backdoor app opens
a local listening port which can then be access from the outside. This
used to be the standard security hole because setting up a CC and
doing reverse networking was hard for most hackers.

The problem is that most toolkits come with the VPN solution these
days so a hacking group don't have to be rock-stars in
programming/networking to set it up. N number of satoshi on some
darkweb will get you a javascript tool which can be injected on a
webpage and do all the work for the hacker. So Bjorn is trying to
point out that the problem you need to worry about is not solved by
the shipped firewall. Instead some level of application firewall would
be needed to even 'try' to stop this.


> --
> Sincerely,
>   Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Vitaly Zaitsev via devel
On 27.08.2019 18:14, Björn Persson wrote:
> If it could come from anywhere, then we must assume that it's malicious.
> You executed untrusted code. It's already past your firewall. Game over,
> you're infected. You're closing the stable door after the horse has
> bolted.

Any application can run backdoor or proxy on your machine with disabled
firewall. Everyone from the Internet can connect it.

If the firewall is enabled and all ports are closed, hacker cannot
access your system. They will need to bypass firewall first and this is
much more difficult.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread David Kaufmann
On Tue, Aug 27, 2019 at 06:58:06AM -0700, John Harris wrote:
> On Tuesday, August 27, 2019 4:37:24 AM MST David Kaufmann wrote:
>> Both option have their disadvantages - in the case of "maintainer opens
>> ports" the ports are open as soon as the package gets installed, and
>> software not run/installed via package manager will give the impression
>> of "just not working".
> 
> Why in the world would somebody from the security team recommend opening a 
> port on the firewall as the software is installed, before it's even 
> configured?

I'm not trying to recommend it, this is already done, e.g. for mdns,
samba-client, or ssh. (To be fair that happens on os install, not
necessarily on package install)
I'm trying to list the problems with those options.

>> Also a firewall is not that much protection as it looks like - imagine
>> any port (above 1024) which was opened on the firewall (either by
>> maintainer or user), but where no program is listening on. The
>> additional barrier to run e.g. a c server on that machine would just
>> be an additional portscan in before deploying the malware.
> 
> Just running a firewall reduces the attack vector needed to deploy potential 
> malware to begin with.

Very true. Unfortunately it is usually done to shield services which
should not be there in the first place.
Also stuff like rate-limiting or ip-header-checks are usually done by
firewalls, hence my emphasis on making sure users don't start to disable
the whole firewall because it is "easier".

~ David


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Björn Persson
John Harris wrote:
>On Tuesday, August 27, 2019 5:36:20 AM MST Björn Persson wrote:
>> Please elaborate. Where does the script come from, what exactly happens
>> by accident, and how would a packet filter stop it?  
>
>It could come from anywhere, that's not the point. A *firewall* would stop it 
>from doing anything too harmful: Opening up the system to the world by binding 
>a port, or listening on a UDP port.

If it could come from anywhere, then we must assume that it's malicious.
You executed untrusted code. It's already past your firewall. Game over,
you're infected. You're closing the stable door after the horse has
bolted.

>It'd still be bound, or would still be listening on a port, but it wouldn't be 
>accessible unless somebody went and manually opened a port on the firewall.

And what if the malicious script doesn't just listen, but actively
phones home?

>> A badly written script accidentally starts some network service that it
>> doesn't need? The one time that actually happens, the user will likely
>> click "allow" without thinking, as they will have been accustomed to
>> doing so all the time.
>>
>> 
>> If the script actually needs to listen on the network, then the user
>> will have to allow it, and the script is no less badly written than it
>> was before.  
>
>There is no "allow" button. I don't know what you're talking about.

Let's just say I'm talking about granting permission with Polkit like
you mention below, whichever way you envision that.

>Additionally, I'm referring to incidents like that common in node.js, where a 
>package gets modified to something malicious, and then runs a backdoor which 
>is accessible over a given port.

Again, it's already past your firewall. You're already infected. What
if the malicious Javascript doesn't just run a backdoor, but actively
phones home?

>> How would a "vulnerability" "bind a port"? If the program is supposed
>> to communicate, then it will be allowed, and any vulnerabilities it has
>> are then exposed to the network. If it's not supposed to communicate,
>> then it won't randomly sprout a network service because of a bug.  
>
>For example, RCEs, specific or otherwise. This has happened in `firefox` 
>before.

OK so you meant the case below:

>> If you mean that an arbitrary code execution vulnerability has been
>> exploited, so that the program is now executing the attacker's code,
>> then it's already too late. The attack code won't listen for incoming
>> connections. It will make an outgoing connection to its master. And in
>> case you're considering requiring permission even for outgoing
>> connections – which would be unbearable to the user – the attack code
>> would just make an API call (through Dbus or whatever) to grant itself
>> permission to communicate.  
>
>Just because a potential attacker may have already compromised part of a 
>system doesn't mean that you just open up the firewall to anything they've got 
>listening.

And for the fourth time: It's not listening, it's actively phoning home.

>Additionally, such a thing trying to open a port would likely 
>require Polkit to grant you permission to do so first, which would, by 
>default, require the user to authenticate and have the appropriate 
>permissions.

Do you expect users to type their passphrase every single time they
want to play some peer-to-peer game, or make an Internet phone call, or
download something with Bittorrent, et cetera?

Or would the permissions be stored permanently somewhere? In that case,
how would you prevent a malicious program from impersonating one of the
permissioned programs?

Björn Persson


pgpHKfRZ49qvh.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Artem Tim
For this who can't change their default zone in firewall after installing 
Fedora Workstation completely block all ports may result in worse things, like 
completely turn off firewall, because they can't run their online video games 
for example and some one always advised them to do this.

We remember well this with SELinux and we still can find such advised to 
disable it in internet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Chris Murphy
On Tue, Aug 27, 2019 at 6:22 AM Neal Gompa  wrote:
>
> The other major non-Linux operating systems do. Both Microsoft Windows
> and Apple macOS ship with active firewalls by default.

The firewall on macOS is disabled by default. Therefore I can't agree
with any assessment that Fedora Workstation is, on this point alone,
in some sort of vulnerable state outside that of macOS.

Windows is enable by default with two "zones" or "policies" (I can't
even tell from their own UI what to call this), one for private
networks, and another for guest/public networks.



>Those are the
> real competitors, and they have a good UX for firewall handling so
> that users can Do The Right Thing(TM).

For Windows and macOS, when firewall is enabled, an application that
tries to open a port against the firewall's policy, causes a dialog to
appear. The user needs to read that, and make a decision. A valid
subjective case can be made that this is janky, as if the UI itself is
saying: "I dunno if this network is trustworthy! Do you know if it's
trustworthy?!" Without any further way of informing the user how to
determine this. They are both a buck passing interface. And that's
fine for some users, but definitely not fine for others.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Jiri Eischmann
Iñaki Ucar píše v Út 27. 08. 2019 v 16:17 +0200:
> On Tue, 27 Aug 2019 at 14:20,  wrote:
> > The main competitor of Fedora Workstation is Ubuntu. Ubuntu ships
> > without a firewall enabled and nobody considers this a critical
> > vulnerability. Now: why is that...?
> 
> 1. Ubuntu Server ships without a firewall enabled. Do you think
> that's
> a good policy? Should we turn off the firewall in Fedora Server
> because Ubuntu Server does so?
> 
> 2. Are you sure that nobody considers that critical?
> 
> "There is a lot of existing information about firewalls - along with
> **a long-term raging debate on the need of a firewall on Ubuntu**. We
> recommend you enable it because you have ports open if you are
> reading
> this page."
> 
> Source: https://wiki.ubuntu.com/BasicSecurity#Firewall
> 
> So it's not critical, it's not enabled by default, and still they
> recommend you to enable it (!).

Who is them? 'haqking-deactivatedaccount' who was the last one editing
the wiki page? I could go and create such a page on Fedora wiki without
any authority as well.

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Louis Lagendijk
On Tue, 2019-08-27 at 10:14 -0400, Robert Marcano wrote:
> On 8/27/19 10:03 AM, John Harris wrote:
> > 
> Any new Wifi connection could be identified by their SSID, so it
> could 
> still be secure by default and ask for that specific connection to
> be 
> opened because you trust them. As I proposed on another email, bring 
> back the NetworkManager zones UI to GNOME Settings, simplified with 
> being an option to confine that connection to the public zone.
> 
Yeah, the WIFI case can be as simple as that: let the use choose the
default zone. Public means closed firewall,  otherwise the workstation
zone can be as it is now. This protects the user from big mistakes as
unintended sharing of information over samba, media players et. 
> The problem of identifying wired connections still remains and needs 
> more thinking.
For this case NetworkManager could verify the gateway address/ MAC to
see if this is a known network, and if not offer the user to allocate
that connection to a public/private zone? I seem to remember that
Windows does something similar (sorry not a big Windows user)...
/louis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Iñaki Ucar
On Tue, 27 Aug 2019 at 15:17, Iñaki Ucar  wrote:
>
> Windows shows a pop-up.

To be fair, I've just checked and Windows 10 doesn't show a pop-up;
better than that: when you (enter the password and) hit "connect", it
asks there whether it's a private network and you want to share
resources, yes or no, that's it. If you click "no" or just ignore that
and close the networking applet, the default is "public", and the
firewall is closed.

At any point, if you go back to the networking applet in the task bar,
you see "disconnect" and a "properties" button. In properties (in a
new window), the first thing you see is whether this connection is
considered public or private, and you can change it also there.

I'd say that this is a pretty good user experience. You don't see
"firewall" anywhere, nor any other complicated configuration option,
and it's still easy for the user to Do The Right Thing (TM) from the
security point of view.

Iñaki
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 7:14:20 AM MST Robert Marcano wrote:
> On 8/27/19 10:03 AM, John Harris wrote:
> 
> > On Tuesday, August 27, 2019 5:35:08 AM MST Robert Marcano wrote:
> > 
> >> On 8/27/19 8:18 AM, mcatanz...@gnome.org wrote:
> >>
> >>
> >>
> >>> On Tue, Aug 27, 2019 at 2:37 PM, Iñaki Ucar 
> >>> wrote:
> >>
> >>
> >>
>  There's no need to write "a new style of firewall". It would be as
>  easy as asking the user once whether a new connection is trusted or
>  not. That's it.
> >>>
> >>>
> >>>
> >>>
> >>> But, well, how do you do that? What do you show to the user?
> >>
> >>
> >>
> >>
> >> Maybe, now that NetworkManager implements now its own DHCP client, if
> >> the IP received is not an private address (RFC 1918 for IPv4, some other
> >> consideration should be done for IPv6), Notify the user the connection
> >> is in a secure mode with an option to disable the secure, temporarily or
> >> permanently
> >>
> >>
> >>
> >>
> > 
> > That wouldn't work. If you hop on public wifi, your IP will most likely be
> > in
 a private rang, which would be wide open under this proposal.
> 
> 
> Any new Wifi connection could be identified by their SSID, so it could 
> still be secure by default and ask for that specific connection to be 
> opened because you trust them. As I proposed on another email, bring 
> back the NetworkManager zones UI to GNOME Settings, simplified with 
> being an option to confine that connection to the public zone.
> 
> The problem of identifying wired connections still remains and needs 
> more thinking.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Why in the world would it need to be "simplified"? Just set the default zone 
names to something useful for users that don't know what zones are.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Iñaki Ucar
On Tue, 27 Aug 2019 at 14:20,  wrote:
>
> The main competitor of Fedora Workstation is Ubuntu. Ubuntu ships without a 
> firewall enabled and nobody considers this a critical vulnerability. Now: why 
> is that...?

1. Ubuntu Server ships without a firewall enabled. Do you think that's
a good policy? Should we turn off the firewall in Fedora Server
because Ubuntu Server does so?

2. Are you sure that nobody considers that critical?

"There is a lot of existing information about firewalls - along with
**a long-term raging debate on the need of a firewall on Ubuntu**. We
recommend you enable it because you have ports open if you are reading
this page."

Source: https://wiki.ubuntu.com/BasicSecurity#Firewall

So it's not critical, it's not enabled by default, and still they
recommend you to enable it (!).

Iñaki
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Robert Marcano

On 8/27/19 10:03 AM, John Harris wrote:

On Tuesday, August 27, 2019 5:35:08 AM MST Robert Marcano wrote:

On 8/27/19 8:18 AM, mcatanz...@gnome.org wrote:


On Tue, Aug 27, 2019 at 2:37 PM, Iñaki Ucar 
wrote:



There's no need to write "a new style of firewall". It would be as
easy as asking the user once whether a new connection is trusted or
not. That's it.



But, well, how do you do that? What do you show to the user?



Maybe, now that NetworkManager implements now its own DHCP client, if
the IP received is not an private address (RFC 1918 for IPv4, some other
consideration should be done for IPv6), Notify the user the connection
is in a secure mode with an option to disable the secure, temporarily or
permanently




That wouldn't work. If you hop on public wifi, your IP will most likely be in
a private rang, which would be wide open under this proposal.


Any new Wifi connection could be identified by their SSID, so it could 
still be secure by default and ask for that specific connection to be 
opened because you trust them. As I proposed on another email, bring 
back the NetworkManager zones UI to GNOME Settings, simplified with 
being an option to confine that connection to the public zone.


The problem of identifying wired connections still remains and needs 
more thinking.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 7:06:31 AM MST Ryan Walklin wrote:
> > > On Tue, Aug 27, 2019 at 4:22 AM, John Harris 
> 
> 
> 
> > 
> > That port numbers are now "technical details" is fairly concerning, and I
> > 
> > can't imagine why you think users shouldn't be able to configure their 
> > firewall. You realize we have a GTK firewall configuration program?
> > 
> > Right now, the average user isn't even aware that they, essentially, don't
> >  have a running firewall. Most users are assuming we're shipping Fedora
> > with secure defaults.
> > 
> > -- 
> 
> Out of interest, how is one supposed to use firewall-config under Wayland?
> It looks like it requires being run as root. The grandmas would be
> struggling at this point... ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Polkit. You would likely just see a prompt for your password.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread Ryan Walklin

> > On Tue, Aug 27, 2019 at 4:22 AM, John Harris 

> 
> That port numbers are now "technical details" is fairly concerning, and I 
> can't imagine why you think users shouldn't be able to configure their 
> firewall. You realize we have a GTK firewall configuration program?
> 
> Right now, the average user isn't even aware that they, essentially, don't 
> have a running firewall. Most users are assuming we're shipping Fedora with 
> secure defaults.
> 
> -- 
Out of interest, how is one supposed to use firewall-config under Wayland? It 
looks like it requires being run as root. The grandmas would be struggling at 
this point...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Workstation and disabled by default firewall

2019-08-27 Thread John Harris
On Tuesday, August 27, 2019 5:35:08 AM MST Robert Marcano wrote:
> On 8/27/19 8:18 AM, mcatanz...@gnome.org wrote:
> 
> > On Tue, Aug 27, 2019 at 2:37 PM, Iñaki Ucar 
> > wrote:
> 
> >> There's no need to write "a new style of firewall". It would be as 
> >> easy as asking the user once whether a new connection is trusted or 
> >> not. That's it.
> > 
> > 
> > But, well, how do you do that? What do you show to the user?
> 
> 
> Maybe, now that NetworkManager implements now its own DHCP client, if 
> the IP received is not an private address (RFC 1918 for IPv4, some other 
> consideration should be done for IPv6), Notify the user the connection 
> is in a secure mode with an option to disable the secure, temporarily or 
> permanently
> 
> 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> > Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o
> > rg 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

That wouldn't work. If you hop on public wifi, your IP will most likely be in 
a private rang, which would be wide open under this proposal.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


  1   2   >