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

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

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)


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