On Fri, May 22, 2015 at 10:26:48AM -0400, Frank Ch. Eigler wrote:
> I'd personally prefer to assume the best intentions of our
> specifically I'd assume that if there's a question as to the safety of
> starting something by default, either they'd bring it up voluntarily or
> someone would do so on their behalf if a problem was discovered.
This is not about trusting the code or intentions of the packagers.
This is about what threat model are we expected to protect against by
not activating e.g. all services by default. Specifying that would
help clear up -why- the change, and that will in turn inform -how- to
Clarification: this change did not touch this part of the policy: that
definition got copied over from the guidelines . The "why" is that
functionality became available (systemd presets) which was not there
before and allows the distribution to manage default enablement of
services in a nicer way.
Nevertheless, you raise an interesting question in general.
The way I understand the motivation for the restriction is to avoid
any chance of attack or unexpected access over the network.
When you look the list of exceptions, they are pretty narrow for
services which listen on a port. "does not require manual
configuration to be functional" cuts out many daemons which could
"serve" stuff. "does not listen on a public socket" cuts out even
more. I guess that rather trying to refine the rules, it'd be better
to look at specific packages and verify that the default installation
does not allow any unexpected privilege escalation, exposure of data,
or resource usage.