Re: curl-users Digest, Vol 182, Issue 2

From: Timothe Litt <litt_at_acm.org>
Date: Sun, 4 Oct 2020 15:50:19 -0400

On 04-Oct-20 10:58, Daniel Stenberg wrote:
> On Sat, 3 Oct 2020, Timothe Litt via curl-users wrote:
>
>> You would NOT want to activate this in libcurl.  Nor should it go
>> entirely in curl.
>
> Thanks for this extensive feedback, Timothe. Much appreciated!
>
Glad to help - it's the sort of thing that looks attractive until you
expend a lot of effort and get into the details.

Re: the mysterious "ioctl"  reference - a  few sentences got dropped. 
ioctl() is so overloaded that a simple Boolean enable or disable is
useless.  Not only does ioctl() encompass both read and write functions,
but the scope of the functions varies greatly.  E.g. from terminal speed
to CD/MT eject to SCSI control to socket state to sounds, write format,
and ...  So it's not the syscall that you want to control, it's the
(function code, value, target) tuple.  get/setsockopt() suffer similar,
but slightly less severe, issues.  seccomp() does pass some of the
function call arguments, but not enough to decode all cases - e.g. when
the "real" function is in a memory buffer.  And the division between the
RTL and kernel varies by implementation (and version), making the
requisite BPF code even less portable/stable.  "Here there be dragons."

Also, in addition to SeLinux/AppArmor, people interested in limiting
stray actions might want to look at "capabilities(7)", which provides a
more functional way to limit some privileged actions.   (Including some
ioctl()s)  It suffers from another form of the granularity problem -
intended to make "root" more granular, it illustrates that attempting to
group functions tends to end up with poor groupings.  E.g. CAP_SYS_PACCT
(too small) and CAP_SYS_ADMIN (much too big).  But you could wrap curl
with something that establishes a bounding set.

The best choice remains protecting resources and limiting privileges. 
The Unix/POSIX architecture makes guessing what a given syscall will do
akin to the halting problem.  There is always the promise of a correct
and complete answer, but you rarely if ever get there.  (And to be fair,
the VMS $QIO merges read, write AND ioctl into one call. Though VMS does
have a more granular privilege scheme.)

Limit privileges, set appropriate permissions (see ACL, chown, chmod,
chcon)  on resources, and make use of higher-level tools such as
SeLinux/AppArmor to enforce them.  They have worked-out the details and
have the necessary hooks to define and enforce policy.

cURL is a good tool for pushing/pulling bits over the network.  It's not
the right place for a security policy.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.



-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-04