On Wed, Apr 16, 2014 at 12:32:02PM -0400, Simo Sorce wrote:
> > > I think what you are describing could be probably realized with SELinux
> > > today, just with a special setroubleshoot frontend that catches the AVC
> > > when the service tries to listen and ask the user if he wants to allow
> > > it.
> > >
> > > However this would still not be completely sufficient as you completely
> > > lack any context about what network you are operating on.
> > >
> > > The firewall's purpose is to block access to local services on bad
> > > networks too, it is not a binary open/close equation when you have
> > > machines (laptops) that roam across a variety of networks.
> > >
> > > Simo.
> > >
> > Nothing worse then asking Users Security related questions about opening
> > firewall ports.
> > Users will just answer yes, whether or not they are being hacked.
> >
> > firefox wants to listen on port 9900 in order to see this page, OK?
>
>
> Which is not what I proposed Dan.
>
> I in fact said we should *NOT* ask per application.
>
> What we should ask is one single question, upon connecting to an unknown
> network: "Is this network trusted ?"
>
> If yes you open up to the local network. If no you keep ports not
> accessible on that network.
But firewalld currently lacks flexibility to express this fully.
Firewalld only classifies ”whole” interfaces, which breaks badly in
many situations. Consider following scenario: VM with single
network interface. This single interface has RFC1918 IPv4 address AND
globally accesible IPv6 address. How it should be described
in firewalld?
– for any IPv4 incoming connection, this interface is in ”trusted” (”home”?
I never know what home/work/dmz/etc really mean)
– for IPv6 incoming connection from 2001:6a0:138:1::/64 subnet, the zone
is still ”trusted”
– for any other incoming connection the zone is ”public” (I hope this
means ”general Internet”).
Above is trivial in iptables, but impossible with firewalld's zones.
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzichubg@xxxxxxxxx -- Baron Vladimir Harkonnen
Attachment:
pgpNL08ONNZH4.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
