Concerns about 'provenpackager' and why I didn't mass ACL open

[Toshio Kuratomi]

Michael DeHaan wrote:
> Jesse Keating mentioned I should probably start a thread about why I
> didn't include a few packages of mine in the mass-ACL opening with the
> idea of starting a discussion about why some packages should or
> shouldn't be included.   I generally think in most cases people will do
> the right thing with such access, but I choose to err on the side of
> paranoid security when it comes to systems management software.
> 
> I'll explain -- For starters, I agree that it's important for people to
> be able to fix packaging problems when needed (when the project owner is
> not around especially), though my concern with the provenpackager system
> is I am not sure of the levels of controls in place for what allows
> someone to become a provenpackager -- or what would happen if a
> provenpackager's machine+passwords get comprimised.    With the number
> of people being able to access a package being reasonably low, the risk
> is low, but as we increase the number of people with commit access to
> /anything/ so the risk also increases.
> 
> As I understand it, in general, provenpackager status requires packaging
> a certain number of packages (N).    In my opinion, this is insufficient
> and potentially dangerous and package access should be given under an
> "as needed" basis.   This is for the same reason commit access to
> repositories needs to be vetted (do any of us allow /everyone/ to
> commit?) -- though in this case it's more important -- while git allows
> backing off on a version, deleting history, and other things, this
> system seems to allow for potentially releasing bits -- which is much
> more powerful.   It seems to allow deployed code to be changed without
> the descretion of the people running the project.     The risk is
> unlikely but possible.
> 
> There are two events when it is dangerous -- (A) provenpackager decides
> to correct what he thinks is an rpmlint error and thus unintentially
> breaks the security of the packaged application, (B) credentials of
> provenpackager are compromised allowing $evil to replace the contents of
> a said package.    In either case, the change could either be making a
> new release of an application (which contains an exploit and/or
> unwitting bug), or  updating the specfile in a way that breaks file
> permissions in a way that may not be immediately obvious (whether
> intentional or not).
> Now for some things, like desktop libraries, that could be used to
> install a botnet type application -- through you still have to
> comprimise N machines.    What if you had a tool that allowed you to
> comprimise an entire organization?    That's something I want to make
> sure never happens.    Our security track record does not only stem from
> things like SELinux, Unix permissions, and the like -- it also stems
> from a culture of vigilance.
> 
> Now the two packages I've left off from the mass ACL opening now are
> cobbler, koan, func, and certmaster.
> 
> The reason being for this is that these, if comprised, are tools that
> /do/ allow reprogramming of an entire datacenter in very easy steps.   
> Cobbler could reinstall an entire set of managed machines in 1
> command.   Func should be more obvious.   We pay very close attention to
> these programs and while we are very accepting of any contributions and
> ideas, we /do/ watch the commits very carefully.  I know there are many
> programs with similar capability that /have/ been opened up, but perhaps
> because we didn't talk about consequences.
> 
> While it's true that any comprimised package would be a problem,
> something as simple as making an unintended change to package
> permissions (without first discussing it on the project lists), could
> expose not the one system with packages installed but the entire set of
> /managed/ systems.
> 
> I am not really comfortable with opening that up.
> 
> So, anyway, that's my logic ... if anyone can persuade me that releasing
> new code is /not/ possible through the provenpackager system, I think I
> could be persuaded to flip things, but right now, I can't see an
> advantage in doing so.
> 
> (If a change is needed, people can still bring up the change on the
> project lists and it can be made)
> 
I cannot allay your concerns and I can see your point.  I'd like to
mention, though, that func depends on the following packages with open acls:

pyOpenSSL, python, python-simplejson

So in terms of protecting against $EVIL, restricting provenpackager
isn't very effective.

It is, effective for restricting people in provenpackager from making
unaudited changes to your code, though.  So if you are a conscientious
maintainer who is on top of their bug reports, restricting
provenpackager could be good for everyone.  On the other hand, if you're
a maintainer that has too many packages and other responsibilities and
doesn't get around to fixing things (or at least showing presence on a
bug) quickly, having provenpackager set is a definite detriment.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20081107/e1299955/attachment.bin