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 [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. > 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. 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 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
