Any way to disable module signature checking for an individual module?

[xrobau (Rob Thomas)]

@slonkak

If this is the real problem then I believe you’ve added a decent solution with module signing.

Yay! Thanks I’m glad that someone else thinks that this actually solves the problem that it was meant to solve!

@slonkak

Making malicious edits to modules is the effect, not the cause.

And that’s not what we’re trying to stop. We’re just trying to make sure that people know that stuff has been changed. The CAUSE is security vulnerabilities.

We have a [email protected] email address that goes to lots of important people, and we take security very seriously - so seriously that I’m happy to say we haven’t had to release a CVE this year. I really hate writing them, so we do our best not to have to

@slonkak

But in the latter cases the signing *[RedHat

@slonkak

My point was simply that it’s the only way to actually prevent malicious modifications (and even then the good hackers can still finesse the binaries)

]* is just for initial installs.

Actually, it’s not! This is something that a lot of people don’t know but RPM (specifically, dpkg doesn’t do this, and I think it’s a terribly important missing feature) DOES do integrity checks. Try this:

rpm -qVa

That does an integrity check and alert of every file that has been changed on your system, that isn’t tagged as a config file in the spec.

Sorry, my nerd is creeping in here.

@slonkak

My point was simply that it’s the only way to actually prevent malicious modifications (and even then the good hackers can still finesse the binaries)

Exactly. And PREVENTING people changing our stuff kinda goes against the GPL, which is why we go out of our way to make it easy to do so! I <3 the GPL! In fact, I’m one of those people who DON’T think the AGPL is crazy, and you may notice that we’ve been using it for a lot of our new modules.

@slonkak

When I make an edit, I immediately get calls/emails, “hey, voip is saying files have been tampered with, you should check it out”.

If it’s actually happening that much, it might be worth you signing the indemnification and getting your own GPG key signed, so it stops complaining. The other thing is, you’re going to have to redo the changes every time you update, too, or, you need to stop updating… Which then means you may miss a security fix.

Are your changes something that other people are going to want?

@slonkak

In addition, 2 big red alert boxes are constantly in the System Overview window in the dashboard.

There’s an X in the top right hand corner of that box. Once you click on that, you’ll never see it again. I realise that the contrast could be slightly better on the X, and we’ve fixed that in 13, but the CSS in 12 makes it hard to see.

@slonkak

Having a root-owned file somewhere that contains override hashes seems like a good idea. Web-user can’t touch it, so no chance of attack that way. Obviously it needs to be kept out of directories that web-user needs to work with to keep module updates working, but you guys already know that…

I think I have already written this down somewhere, but I can’t seem to find it, so here’s the idea that @tm1000 and I were thinking about.

• A new directory /etc/freepbx.d that contains a subtree of module names. (Thus /etc/freepbx.d/dialplaninjection)
• Each module folder has a module.sig and a key file that must be owned by the root user
• Before GPG checks for and validates the module.sig in the module folder, it checks for the existence and validates the ownership of the files in freepbx.d. If it finds it, it works from that, otherwise it works from the standard one.

That’s still going to require people who want to change code to pull the devtools repo and use the packaging tools, but it also removes the requirement for us to get involved.

@slonkak

As far as self-signing is concerned, you shouldn’t do that.

I think we need to provide a way to let users do that. We can’t stop them from being stupid, we just need to give them as many alternatives as possible so they don’t think using a shotgun to remove a blackhead is their only option

@slonkak

Making someone reach out to you to get a legit key is the only way to have any sort of verification that signed code was done legitimately (then it’s on you guys to weed out hackers requesting keys )

We’re not even doing that. That’s why we put the ‘revoked key’ stuff in there. If someone malicious DOES start publishing nasty modules, we revoke their key, and all their modules are blocked. Obviously, they can simply remove the module.sig and it’ll then start working again as an unsigned module, but this is all about alerting, and making noise about bad things, not blocking.

@slonkak

I’m sorry for my long diatribes, especially since I seem to be 1 of 2 people who care about editing modules on my server. I’m most likely just wasting the time of everyone here…

Hell no! This is great! Are you coming to Linux.conf.au in Feb? We can sit down and have a beer and you can tell me why my code sucks. (Those are the best kind of discussions!). As you know, security should never exist in a vacuum, which is why I love to talk about it. @tm1000 is a bit sick of it by now, but that’s because he’s normal, and I’m an anal-retentive security nazi who can’t stop talking about it

I truly appreciate your input!