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)
--Michael
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
