On Sun, 2015-05-24 at 14:46 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, May 23, 2015 at 07:24:07AM -0400, Frank Ch. Eigler wrote:
> zbyszek wrote:
> > [...]
> > Clarification: this change did not touch this part of the policy:
> > that
> > definition got copied over from the guidelines . [...]
> (The previous wording said a package that "...does not listen on a
> network socket..." can be enabled by default, which was a broader
> restriction and thus more secure.)
Hm, you're right. I can't say for certain why sgallagh made that
but I think it was intended as a clarification, not a change.
Yes, I thought my new phrasing was more clearly expressing the original
intent of the statement as I understood it. It appears that I may have
inadvertently raised new questions. I think we should perhaps discuss
this at the weekly FESCo meeting.
This is what I get for trying to improve clarity!
> > Nevertheless, you raise an interesting question in general.
> > way
> > I understand the motivation for the restriction is to avoid any
> > chance of attack or unexpected access over the network. [...]
> OK, so the question is - are we (still) trying to preclude -local-
> escalation-of-privileges type problems? If not, then many more
> services can be enabled by default - as long as they bind only to
> unix-domain sockets and/or localhost. (I guess we're not supposed
> count on the default firewalls?)
Yes, that's the way I understand it too. The distinction between
and remote is that remote attacks are in general more likely and thus
This is a good assumption - I'm sure that on most installations of
there's just one or a few trusted users, and they outnumber
with a large list of potentially rogue accounts. So it makes sense
to treat remotely-accessible services more carefully. Nevertheless,
even though those rules don't spell this out, it would be considered
serious bug if a package allowed unexpected privilege escalation by
the mere fact of being installed, be it through a local network
socket, a unix socket, setuid binary, or any other mechanism. I think
this is an implicit shared understanding. Coming back to network
services: even though packagers don't expect a service to allow
unexpected privilege escalation, the base of attackers is bigger in
case of remote services, so those rules disallow running by default
an additional safety precaution.
These are very reasonable arguments. As noted above, I think it's
reasonable for FESCo to make (or reiterate) a stance on this, which we
will then use to update the guidelines.