cURL / Mailing Lists / curl-library / Single Mail


Re: Ideas to Improve cURL Security

From: Daniel Stenberg <>
Date: Mon, 29 Sep 2014 09:05:31 +0200 (CEST)

On Mon, 29 Sep 2014, wrote:

Thanks for your interest in helping us improve!

> 1. Can you please make curl take advantage of seccomp? Its a kernel syscall
> filter that greatly restricts what a misbehaving program can do if its
> remotely exploited.

Can you clarify what that would require from us?

> 2. If your time permits, maybe create and maintain an apparmor profile for
> curl in Debian. Profiles for SELinux are welcome as well but I'm mentioning
> Apparmor because its predominantly used in Debian (our base).

Sorry, but I don't think that's a task for the curl project. We produce a
product that works on all operating systems and all distributions. For
distro-specific adaptions you're better off discussing with those

I mean, I wouldn't block anyone from providing such a thing and submitting it
to the project but I will personally not put it on my shortlist, and if we
would add it to the project I fear it'd grow outdated rather soon... It is
much better to provide Debian things to Debian itself!

> 3. This security tip is not related to curl itself, but in a post-Snowden
> age it would make sense if you provide a GPG fingerprint for the security
> bug email account so researchers could contact you about bugs confidentially
> without a government sniffing this sensitive information before a fix is
> available.

Yeah, I agree that this would be useful. I think I've held this off so far
because it is a real maintanence burden and complexity to add and handle that
I haven't found a will to tackle.

We only ever "hold on" to security vulnerability information for as long as we
can release a fixed version, which we do at least every 8th week - and we can
do it faster if we need to. This way, even if an evil snooper would figure out
a security problem by litesting in to the communication of one of the
curl-security list members it would only be secret for a rather short period
of time.

> 4. Compile-time hardening is probably only relevant to Debian package
> maintainers, but I'll mention it here if thats ok. The checksec script
> reports that only partial RELRO is supported and PIE hardening isn't enabled
> at all. I am discussing this with the maintainer. If needed, can you please
> consider making the necessary changes to cur to support all hardening flags?

AFAIK you can already quite easily provide your own set of compile-time
options for both compilers and linkers etc so I don't think we need to change
anything to support this.

List admin:
Received on 2014-09-29