Capability sandboxing

[asomers]

I'm looking for a new FTPS server for a security-sensitive application. Ideally, I'd like a server that forks after a successful login, opens a capability to the user's home directory, and enters capability mode. That way the OS would enforce that the server isn't reading any files outside of the allowed directory. Is this something that could potentially be done with libunftp? I see that there's an architecture for different storage backends. So probably I could write a capability-mode local file system backend. What about the forking part? Any unforeseen obstacles there? I don't need the Prometheus exporter, btw.

If this sounds feasible to you, I volunteer to implement the capability-mode backend.

[robklg]

Sounds cool! I don't see a particular reason why it wouldn't work. Perhaps one thing to also consider is how you will authenticate securely. You could use unftp-auth-jsonfile crate for this, or make your own. @hannesdejager do you see any reasons why it wouldn't work?

[hannesdejager]

This is indeed something I thought about before and is on the wishlist. This is something that vsftpd for instance does. It would be awesome if we can do this. With this and unFTP being written in Rust I believe this would give a real nice advantage for security mindedness.

But to be honest I don't have a clear idea in my mind yet of how this can be implemented. Would you fork per user logging in? If that is the case then this is perhaps not the best to implement as a storage back-end but as part of the main code. You fork when a user logs in and jails based on the per-user settings.

It would be lovely if you could come up with some ideas or a POC that we can then discuss.

[asomers]

Yes, forking after login would be the most secure way to do it. And yes, I think extensions to the main code would be required. Here are two ideas I have for how it might work:

0. Extend the StorageBackend trait like this:

trait StorageBackend {
    /// Restrict the backend's capabilities so that it may only access files underneath `path`.
    /// Once restricted, it may never be unrestricted.
    fn enter<P: AsRef<Path>>(&mut self, path: P);
}

1. per-user forking. Must use Tokio's single-threaded runtime.

use unftp_sbe_capsicumfs::ServerExt;

#[tokio::main]
pub async fn main() {
    let backend = unftp_sbe_capsicumfs::new("/").unwrap();
    let server = libunftp::Server::with_fs(backend)
        .greeting("Welcome to my FTP server")
        .passive_ports(50000..65535);
    
    capsicum::enter();
    server.listen("127.0.0.1:2121").await;
    // During the command handler for `User`, the server forks and calls
    // StorageBackend::enter(), then proceeds as normal.
}

2. Capsicum-enabled backend, but no per-user forking. Less verifiably secure, but perhaps more flexible. May use a multithreaded runtime.

use unftp_sbe_capsicumfs::ServerExt;

#[tokio::main]
pub async fn main() {
    // Initialize the server with a shortlist of allowed paths.
    let backend = unftp_sbe_capsicumfs::new(
        ["/usr/home/tom", "/usr/home/dick", "/usr/home/jane"][..]
    ).unwrap();
    let server = libunftp::Server::with_fs(backend)
        .greeting("Welcome to my FTP server")
        .passive_ports(50000..65535);
    capsicum::enter();
    server.listen("127.0.0.1:2121").await;
    // Server doesn't need to fork or anything, but after successful
    // authentication maybe it should clone the backend and call
    // StorageBackend::enter() on the clone, using that backend instance
    // for the rest of the connection.
}

[hannesdejager]

So forking per user is probably always useful but restricting to a directory is only useful for filesystem based storage back-ends so I wouldn't want to extend the StorageBackend trait like that. For cloud storage that wouldn't make sense to implement I think.

Could it be another trait?

[asomers]

Yeah, that method wouldn't be useful for all backends. So it should have a default implementation that does nothing. Would that suffice? Wouldn't require any changes to existing backends.

[asomers]

Status update:

• Converting the existing unftp-sbe-fs to be Capsicum-compliant was straightforward
• Dealing with the vagaries of the FTP protocol were harder, since both active and passive mode require the servers to open new ports all the time. But it was doable.
• I larger problem is that a kqueue (which Tokio uses under the hood) cannot be preserved across a fork. So the server can't fork post-authentication unless it also opens a new kqueue, which means creating a new Tokio Runtime. I'm going to try to cope by creating a separate binary for a "post-authentication ftp server" that takes an already-connected control socket either in place of stdout or as its 4th file descriptor. The pre-auth FTP server will fork and exec the post-auth FTP server much like how inetd invokes its executables. But this may require some significant refactoring of libunftp.