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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
