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 [1]. [...] > > (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 rewording, but I think it was intended as a clarification, not a change. > > 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. [...] > > 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 to > count on the default firewalls?) Yes, that's the way I understand it too. The distinction between local and remote is that remote attacks are in general more likely and thus dangerous. This is a good assumption - I'm sure that on most installations of Fedora there's just one or a few trusted users, and they outnumber installations 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 a 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 as an additional safety precaution. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
