Date: Mon, 26 Oct 2020 15:22:00 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Gleb Popov <arrowd@freebsd.org> Cc: Jonathan Anderson <jonathan@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Mapping Linux capabilities(7) to our Capsicum rights(4) Message-ID: <20201026222200.GC31099@funkthat.com> In-Reply-To: <CALH631k7zyEGL8M9mfrXG-r4sZoxcJHMFVmij-y1a_TtMsC2_Q@mail.gmail.com> References: <CALH631mtv0yFUVwKEwgHPg7_TP9WLdAuQMv=-e1YY3OvR86xsQ@mail.gmail.com> <CAMGEAwAa3SJHkKtCm54tb_L1paRjqwaWFz1%2BWT=B7ND=yx-EYw@mail.gmail.com> <CALH631k7zyEGL8M9mfrXG-r4sZoxcJHMFVmij-y1a_TtMsC2_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jonathan@freebsd.org> > 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201026222200.GC31099>