insanitybit / dlfile

For dl the file

dlfile

dlfile is a very simple, straightforward CLI to download a file, except it...

1. Only downloads over HTTPS
2. Requires TLS 1.2 or higher
3. Executes in a seccomp sandbox (linux only - no sandboxing provided on other platforms, PRs welcome)
4. Uses trust-dns, supporting DNS over TLS

Install

cargo install dlfile

Example

dlfile --min-tls=v1.3 \
       --from="https://sh.rustup.rs" \ 
       --to="./rustup.sh

Usage

dlfile 0.2.0

USAGE:
    dlfile [FLAGS] [OPTIONS] --from <from> --to <to>

FLAGS:
    -h, --help          Prints help information
        --no-sandbox    [UNSAFE] Indicates that you want to run without the default sandbox
    -V, --version       Prints version information

OPTIONS:
    -f, --from <from>            The fully qualified URL with an https scheme to download from [env: FROM=]
        --max-size <max-size>    Maximum number of bytes to write to disk before aborting [env: MAX_SIZE=]  [default:
                                 1GB]
        --min-tls <min-tls>      Minimum tls version, one of `v1.2` or `v1.3` [env: MIN_TLS=]  [default: v1.2]
    -t, --to <to>                The file system path, including a file name, for where to write the file to [env: TO=]

dlfile's Issues

Add CHANGELOG.md

Adding a changelog.md and an action to auto-populate it would be great.

Move to ureq from reqwest

ureq is a much smaller and simpler project than reqwest, and it relies on much less unsafe

Moving to ureq may also unblock: #1

Embed SBOM into binary

To make it easier to determine if you're running a suitable version of dlfile we could embed the build information via cargo-auditable.

https://github.com/rust-secure-code/cargo-auditable

This is likely best implemented once there's Github Actions on this project to automate builds.

Detect root

There are two reasons one might run dlfile as root.

1. By mistake. Happens all the time with curl and other cli tools.
2. On purpose so that dlfile can write out to a privileged file.

I think in an ideal world (2) wouldn't happen. Instead dlfile would pipe the data to /dev/stdout and then another tool would handle the writing of the file. That said, it's probably worth supporting it.

Further, given root, we can perform more sandboxing. I don't want dlfile to be a setuid or something like that, but if we do run as root we can access namespaces, chroot, etc. This would significantly improve the sandbox.

Support hash verification

Lots of guides will pin a download to a hash that's provided out of band. It seems reasonable to perform the hashing as we download, which would save having to do a second pass.

A CLI argument like:
--hash="sha256:13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de"
Or
--hahes="./file_with_hashes"
would be straightforward to implement.

Add basic CI

We want to ensure that dependencies stay up to date and that we patch anything from cargo-audit.

Improve seccomp sandboxing

Right now a lot of system calls are allowed and there's very little we can do to restrict their arguments (because they are strings).

That said, if we split out the HTTP and DNS stages we can perform DNS upfront, drop privileges, and then perform the HTTP work.

Further, if we use hyper instead of reqwest we may be able to pre-allocate the socket, which would mean I can remove all of the open system calls.

Control over DNS resolution

Right now we use trust-dns for dns resolution but we have virtually no control over it since reqwest abstracts that away from us. If we perform the resolution upfront we can:

1. Separate out the UDP networking from the TCP networking, which will unblock further sandboxing
2. Force specific resolvers, or DNS over TLS