From owner-freebsd-hackers@freebsd.org Mon Oct 26 22:22:02 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6AB59450C27 for ; Mon, 26 Oct 2020 22:22:02 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKq7t1PTjz3ZjS; Mon, 26 Oct 2020 22:22:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 09QMM0nB045148 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Oct 2020 15:22:00 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 09QMM0P8045147; Mon, 26 Oct 2020 15:22:00 -0700 (PDT) (envelope-from jmg) Date: Mon, 26 Oct 2020 15:22:00 -0700 From: John-Mark Gurney To: Gleb Popov Cc: Jonathan Anderson , freebsd-hackers Subject: Re: Mapping Linux capabilities(7) to our Capsicum rights(4) Message-ID: <20201026222200.GC31099@funkthat.com> Mail-Followup-To: Gleb Popov , Jonathan Anderson , freebsd-hackers References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 26 Oct 2020 15:22:00 -0700 (PDT) X-Rspamd-Queue-Id: 4CKq7t1PTjz3ZjS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 22:22:02 -0000 Gleb Popov wrote this message on Mon, Oct 26, 2020 at 21:04 +0400: > On Mon, Oct 26, 2020 at 4:17 PM Jonathan Anderson > wrote: > > > Hi Gleb, > > > > There won't be a clear mapping between the two, as Linux "capabilities" > > (actually privileges, but unfortunately Symbian and POSIX.1e both called > > their privileges "capabilities" [1]) describe things that a process can do, > > whereas Capsicum capabilities (which are object capabilities) describe > > things that a file descriptor can do. If you want to constrain the > > behaviour of a process, Capsicum provides cap_enter(2), giving up access to > > global namespaces, but that approach may not fit with the Linux-tailored > > software you're porting. > > > > What's the fundamental security goal of the software in question? Dropping > > privileges is one mechanism to try to accomplish your goal, but there may > > well be a very different way of accomplishing it. In many situations (e.g., > > sandboxing), Linux "capabilities" and seccomp-bpf are a bit of an awkward > > fit... maybe we can help you find a better way? > > > > It would be great, but I must admit that at the moment I barely understand > all the complexities of the software. > > >From what I can tell, it spawns child processes and applies following > hardening for them: > > - chroot into a sort of "jail". Capsicum can effectively make a jail w/o the need to chroot (and the root perms to do it), by restricting what file descriptors that a process has access to. > - prohibits using some system calls (using that seccomp thing) If you really do need to restrict syscalls, then you might want to look at the MAC framework: https://www.freebsd.org/doc/en/books/arch-handbook/mac.html > - drops capabilities with cap_* functions > > For now, I'm simply #ifdef'ing this code, but the upstream is really > concerned about security and insists that all these security measures be > reimplemented when making a port. I have about zero experience in this > field, so any guidance would be most appreciated. I'd say you need to read up on both MAC and capsicum to understand which one will meet your needs... Capsicum has the advantage that you can do it entirely from userland, and don't have to write any kernel modules. There may be a MAC framework that allows you to do it, but I haven't looked at MAC in over 15 years, so I'm not familar w/ it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."