Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Securing curl with syscalls
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Emil Engler via curl-users <curl-users_at_cool.haxx.se>
Date: Fri, 2 Oct 2020 13:32:30 +0200
Let's be honest, probably nobody can consistently write secure C code.
Maybe djb can but sooner or later anyone of us does a simple mistakes.
Such mistakes can sometimes lead to disastrous problems that could
affect security. Maybe a syscall to overwrite another file gets called
on accident, etc...
To enhance the curl security a possible way would be to ironically use a
syscall some Unix systems offer. Namely seccomp(2) on Linux and
pledge(2) on OpenBSD. These syscalls makes it possible to restrict a
program to only certain syscalls and if they still get called the OS
will eliminate that program with a SIGKILL.
Here's an example showing pledge(2) on OpenBSD
```
#include <stdio.h>
#include <unistd.h>
int main(void)
{
pledge("stdio", "stdio");
printf("ALLOWED");
pledge("", "");
printf("If you see that message your OS is highly broken as the
process should be already dead\n");
return 0;
}
```
I don't explain these syscalls and mechanisms a lot here, instead I will
link some manpages. But I think that curl could greatly benefit from
using such techniques.
seccomp for Linux: https://man7.org/linux/man-pages/man2/seccomp.2.html
pledge for OpenBSD: http://man.openbsd.org/pledge
The only problem that could happen is that these syscalls are not portable.
My idea would be to write our own wrapper which will have a struct (or
alternatively a bitmask) that has fields that are booleans with names
like "access", "inet", "stdio". Then we would need a function which is
being compiled differently from OS to OS. It interprets the struct and
then executes the required syscall.
I'm open for feedback and your opinion :-)
Cheers,
Emil
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-02
Date: Fri, 2 Oct 2020 13:32:30 +0200
Let's be honest, probably nobody can consistently write secure C code.
Maybe djb can but sooner or later anyone of us does a simple mistakes.
Such mistakes can sometimes lead to disastrous problems that could
affect security. Maybe a syscall to overwrite another file gets called
on accident, etc...
To enhance the curl security a possible way would be to ironically use a
syscall some Unix systems offer. Namely seccomp(2) on Linux and
pledge(2) on OpenBSD. These syscalls makes it possible to restrict a
program to only certain syscalls and if they still get called the OS
will eliminate that program with a SIGKILL.
Here's an example showing pledge(2) on OpenBSD
```
#include <stdio.h>
#include <unistd.h>
int main(void)
{
pledge("stdio", "stdio");
printf("ALLOWED");
pledge("", "");
printf("If you see that message your OS is highly broken as the
process should be already dead\n");
return 0;
}
```
I don't explain these syscalls and mechanisms a lot here, instead I will
link some manpages. But I think that curl could greatly benefit from
using such techniques.
seccomp for Linux: https://man7.org/linux/man-pages/man2/seccomp.2.html
pledge for OpenBSD: http://man.openbsd.org/pledge
The only problem that could happen is that these syscalls are not portable.
My idea would be to write our own wrapper which will have a struct (or
alternatively a bitmask) that has fields that are booleans with names
like "access", "inet", "stdio". Then we would need a function which is
being compiled differently from OS to OS. It interprets the struct and
then executes the required syscall.
I'm open for feedback and your opinion :-)
Cheers,
Emil
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-02