Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Oct 2020 09:47:41 -0230
From:      Jonathan Anderson <jonathan@freebsd.org>
To:        Gleb Popov <arrowd@freebsd.org>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>
Subject:   Re: Mapping Linux capabilities(7) to our Capsicum rights(4)
Message-ID:  <CAMGEAwAa3SJHkKtCm54tb_L1paRjqwaWFz1%2BWT=B7ND=yx-EYw@mail.gmail.com>
In-Reply-To: <CALH631mtv0yFUVwKEwgHPg7_TP9WLdAuQMv=-e1YY3OvR86xsQ@mail.gmail.com>
References:  <CALH631mtv0yFUVwKEwgHPg7_TP9WLdAuQMv=-e1YY3OvR86xsQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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?


Jon

[1]
https://en.wikipedia.org/wiki/Capability-based_security#POSIX_capabilities

On Sun, 25 Oct 2020 at 06:10, Gleb Popov <arrowd@freebsd.org> wrote:

> Hello hackers!
>
> I'm porting a software that employs Linux capabilities to constrain the
> running process. The code looks like
>
> if (!haveCapability(CAP_SYS_CHROOT)
>     || !haveCapability(CAP_MKNOD)
>     || !haveCapability(CAP_FOWNER))
> {
> errorOut();
> }
>
> dropCapability(CAP_SYS_CHROOT);
> dropCapability(CAP_MKNOD);
> dropCapability(CAP_FOWNER);
>
> The CAP_MKNOD looks much like our CAP_MKNODAT. The CAP_FOWNER looks more
> complex, but it seems it is implemented at higher granularity in Capsicum.
> Finally, I haven't found anything for CAP_SYS_CHROOT.
>
> I'll continue digging this up, but any hints would be appreciated.
> Thanks in advance.
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>


-- 
jonathan@FreeBSD.org
http://freebsd.org/~jonathan/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMGEAwAa3SJHkKtCm54tb_L1paRjqwaWFz1%2BWT=B7ND=yx-EYw>