Re: [Guidelines change] Changes to the packaging guidelines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux