Am 04.03.2014 13:40, schrieb Miloslav Trmač:
Even in such a case it would not make sense for the /role/ to decide
whether to poke holes for itself: either the
system roles are assumed to be competently administered or not, and in both cases all
roles on the system should be
treated the same.
And I don't think the case you describe is frequent in the firsts place. It
requires:
* A multi-user UNIX system (in itself becoming rare, everyone has a powerful personal
computer, and remoting the
GUI loses features; you would have a git server or a file server or a VPN server, but
not so much a general
shell server)
* A multi-user UNIX system that /also/ provides other roles at the same time (tightly
coupling things that
probably shouldn't be coupled, using separate VMs would result in more
flexibility)
* A system that is reachable from an environment that is more hostile than the users
(e.g. with a public IP
address); again note that the firewall setups we are talking about don't affect
outgoing connections, only
incoming connections matter.
So, a multi-user server with a public IP address: Yes, there is a specific and frequent
kind of them - web hosting
servers; but those are also not something that we really can support as a default setup,
and longer-term I'd expect
them to go the OpenShift way, giving each user a separate container with a separate
network namespace. Other than
web hosting, are public multi-user servers with ability of users to run arbitrary code
really that frequent?
Mirek
first:
ship whatever OS with shields down and no packet filter blocking anything incoming
is a flawed design and unacceptable (no matter if it is a server or a workstation)
second:
you never know in which way a port get opened and if it is because packaging
bugs as i showed whith avahi pulled for no reason - nonody can gurantee that
similar things are not happening in a future point of time
third:
even if you install a service or webapplication and enable it that does not mean
at the same time it should be reachable from the web - in most cases the
opposite is true because after the first start you typically configure and
test whatever you have installed on localhost, otherwise the admin should
not do an IT job
fourth:
"to run arbitrary code really that frequent" define that - any scripting
language
with commands like exec(), system() and so on is in danger to run code if it is
not perfectly secured what a default installation is unable to do
so there is still a difference if any badly written script executes code and is
able to open a unprivileged port and having that one immediately reachable from
the WAN or blocked by a packet filter giving the admin a timewindow to realize
something is going wrong before more damage happens
and so finally: now, in the past and in any future you have to block any incoming
connection in whatever operating system by default or nobody with security knowledge
will install that "product" because he is aware about the wrong security
attitude
of it's creators and that it is not worth the time for a second look