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

Michael DeHaan mdehaan at redhat.com
Fri Nov 7 19:44:13 UTC 2008


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





More information about the devel mailing list